Forum: NGINX OT: OpenSSL 1.0.1f

8d313c5d85c52a953e498c4f66d59c8a?d=identicon&s=25 Jeffrey Walton (Guest)
on 2014-01-06 21:40
(Received via mailing list)
OpenSSL 1.0.1f was released today. It might be a good time to rebuild
all the versions of nginx using static versions of OpenSSL.

There are three CVE remediations included in the release:
CVE-2013-4353, CVE-2013-6449, CVE-2013-6450.
http://www.openssl.org/news/openssl-1.0.1-notes.html.

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/openssl-dev@openssl.or....
A8c0a2324abb3b0af1aeb22eed240397?d=identicon&s=25 Rob Stradling (Guest)
on 2014-01-06 22:03
(Received via mailing list)
On 06/01/14 20:40, Jeffrey Walton wrote:
<snip>
> 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/openssl-dev@openssl.or....

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
63f341734581b167c7b698169bdd2510?d=identicon&s=25 Lukas Tribus (Guest)
on 2014-01-06 23:05
(Received via mailing list)
Hi,


> 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.



Regards,

Lukas

[1]
http://git.openssl.org/gitweb/?p=openssl.git;a=com...
[2]
http://git.openssl.org/gitweb/?p=openssl.git;a=sho...
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732710
A8c0a2324abb3b0af1aeb22eed240397?d=identicon&s=25 Rob Stradling (Guest)
on 2014-01-07 10:59
(Received via mailing list)
On 06/01/14 21:02, Rob Stradling wrote:
> On 06/01/14 20:40, Jeffrey Walton wrote:
> <snip>
>> 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/openssl-dev@openssl.or....
>
> 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
C792a9b36f45140edbdd04bcbc84dcad?d=identicon&s=25 coderman (Guest)
on 2014-01-07 18:36
(Received via mailing list)
On Mon, Jan 6, 2014 at 2:04 PM, Lukas Tribus <luky-37@hotmail.com>
wrote:
> Hi,
>
>
>> 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!).

in any case, end result: use 1.0.1f and be happy


best regards,
C792a9b36f45140edbdd04bcbc84dcad?d=identicon&s=25 coderman (Guest)
on 2014-01-07 18:42
(Received via mailing list)
On Tue, Jan 7, 2014 at 9:35 AM, coderman <coderman@gmail.com> wrote:
>...
> 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;

        return 1;
        }
2974d09ac2541e892966b762aad84943?d=identicon&s=25 itpp2012 (Guest)
on 2014-01-07 20:44
(Received via mailing list)
1.0.1f against 1.5.9 mainline (today);

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

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,246071,246108#msg-246108
2974d09ac2541e892966b762aad84943?d=identicon&s=25 itpp2012 (Guest)
on 2014-01-08 11:08
(Received via mailing list)
itpp2012 Wrote:
-------------------------------------------------------
> 1.0.1f against 1.5.9 mainline (today);
>
> .\ssl\s23_clnt.c(286) : warning C4244: 'initializing' : conversion
> from 'time_t' to 'unsigned long', possible loss of data

Also found by http://rt.openssl.org/Ticket/Display.html?id=3220
and fixed in .\ssl\s23_clnt.c(line 286):

[...]
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;

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,246071,246128#msg-246128
36a263ac445537d7460355229b39cf40?d=identicon&s=25 Aidan Scheller (Guest)
on 2014-01-09 06:17
(Received via mailing list)
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.

Thanks,

Aidan
2974d09ac2541e892966b762aad84943?d=identicon&s=25 itpp2012 (Guest)
on 2014-01-09 09:52
(Received via mailing list)
Aidan Scheller Wrote:
-------------------------------------------------------
> 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:
http://forum.nginx.org/read.php?2,246071,246138#msg-246138
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.