It does not look like 1.0.1f changed the default behavior of
ENGINE_rdrand (coderman’s been following it).
1.0.1f added hostname and email verification routines so programs no
longer have to do it themselves.
There’s also an Apple SecureTransport bug workaround. Apple’s
SecrureTransport does not properly negotiate ECDHE-ECDSA cipher
suites. It affects Mac OS X and could affect iOS. It might be prudent
to add SSL_OP_SAFARI_ECDHE_ECDSA_BUG by default. http://www.mail-archive.com/[email protected]/msg32629.html.
There’s also an Apple SecureTransport bug workaround. Apple’s
SecrureTransport does not properly negotiate ECDHE-ECDSA cipher
suites. It affects Mac OS X and could affect iOS. It might be prudent
to add SSL_OP_SAFARI_ECDHE_ECDSA_BUG by default. http://www.mail-archive.com/[email protected]/msg32629.html.
Nginx doesn’t yet support multiple server certs per site (e.g. 1 RSA
cert and 1 ECC cert), so SSL_OP_SAFARI_ECDHE_ECDSA_BUG isn’t yet useful.
(I was working on a patch for multiple server certs a few months ago; I
hope to find time to complete this very soon).
–
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
It does not look like 1.0.1f changed the default behavior of
ENGINE_rdrand (coderman’s been following it).
Yes it did, rdrand is no longer enabled by default. Here [1] is
the backport in the OpenSSL_1_0_1-stable head [2].
At least Debian [3] and Ubuntu backported this as well.
OpenSSL makes ZERO mention of this fix anywhere in the 1.0.1f release
itself, only the git history itself provides clue. Tor released an
update to intentionally work around this issue with notice to relay
and hidden service operators who may have been affected; Debian and
Ubuntu disabled via backport, and explicitly called this out in their
security errata (thank you all!).
however, debian and ubuntu neglected to mention packages that may have
been affected by generating long lived keys during a vulnerable
configuration (boo!).
There’s also an Apple SecureTransport bug workaround. Apple’s
SecrureTransport does not properly negotiate ECDHE-ECDSA cipher
suites. It affects Mac OS X and could affect iOS. It might be prudent
to add SSL_OP_SAFARI_ECDHE_ECDSA_BUG by default. http://www.mail-archive.com/[email protected]/msg32629.html.
Nginx doesn’t yet support multiple server certs per site (e.g. 1 RSA
cert and 1 ECC cert), so SSL_OP_SAFARI_ECDHE_ECDSA_BUG isn’t yet useful.
Actually I suppose that’s not strictly true. Setting
SSL_OP_SAFARI_ECDHE_ECDSA_BUG would be useful today on any Nginx server
with an ECC cert and both ECDHE-ECDSA cipher(s) and ECDH-ECDSA cipher(s)
enabled. (I don’t suppose there are many such servers!)
(I was working on a patch for multiple server certs a few months ago; I
hope to find time to complete this very soon).
–
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
ecp_nistputil.obj : warning LNK4221: This object file does not define
any
previously undefined public symbols, so it will not be used by any link
operation that consumes this library
ecp_nistp521.obj : warning LNK4221: This object file does not define any
previously undefined public symbols, so it will not be used by any link
operation that consumes this library
ecp_nistp256.obj : warning LNK4221: This object file does not define any
previously undefined public symbols, so it will not be used by any link
operation that consumes this library
ecp_nistp224.obj : warning LNK4221: This object file does not define any
previously undefined public symbols, so it will not be used by any link
operation that consumes this library
fips_ers.obj : warning LNK4221: This object file does not define any
previously undefined public symbols, so it will not be used by any link
operation that consumes this library
.\ssl\s23_clnt.c(286) : warning C4244: ‘initializing’ : conversion from
‘time_t’ to ‘unsigned long’, possible loss of data
…
in any case, end result: use 1.0.1f and be happy
and if concerned that your OS distribution or upstream OpenSSL lacks
this fix,
confirm yourself via openssl-1.0.1f/crypto/engine/eng_rdrand.c in
patched src
if you see !ENGINE_set_flags(e, ENGINE_FLAGS_NO_REGISTER_ALL)
in the near bottom of file static int bind_helper(ENGINE *e){}
definition,
then you are safe from accidental use.
c.f. good ver: openssl-1.0.1f/crypto/engine/eng_rdrand.c
static int bind_helper(ENGINE *e)
{
if (!ENGINE_set_id(e, engine_e_rdrand_id) ||
!ENGINE_set_name(e, engine_e_rdrand_name) ||
!ENGINE_set_flags(e, ENGINE_FLAGS_NO_REGISTER_ALL) ||
!ENGINE_set_init_function(e, rdrand_init) ||
!ENGINE_set_RAND(e, &rdrand_meth) )
return 0;
[…]
int ssl_fill_hello_random(SSL *s, int server, unsigned char *result, int
len)
[…]
if (send_time)
{
// unsigned long Time = time(NULL);
unsigned long Time = (unsigned long)time(NULL);
unsigned char *p = result;
Does using the --with-openssl-opt=“enable-ec_nistp_64_gcc_128”
configure parameter without the *–with-openssl *cause a static version
of
OpenSSL to be created for Nginx? I’m unsure as the configuration
summary
then lists that the system library is being used.
Does using the --with-openssl-opt=“enable-ec_nistp_64_gcc_128”
configure parameter without the *–with-openssl *cause a static
version of
OpenSSL to be created for Nginx? I’m unsure as the configuration
summary
then lists that the system library is being used.
Who is reporting which lib is used? openssl is compiled independently as
part of the nginx build process where you can choose a static or dynamic
build. What options does openssl makefile have after configure?
Posted at Nginx Forum:
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.