[openssl-dev] [openssl.org #3616] [Patch] Implement option to disable sending TLS extensions

[Hubert Kario]

On Monday 26 January 2015 10:03:30 Brian Smith wrote:
> Hubert Kario <hkario at redhat.com> wrote:
> > Actually it does not introduce it as OpenSSL does send the notification as
> > TLS_EMPTY_RENEGOTIATION_INFO_SCSV, not the extension.
> > 
> > On Sunday 30 November 2014 20:36:20 Richard Moore wrote:
> >> That would introduce security issues such as the TLS renegotiation flaw.
> >> Surely a better solution is to make servers that pretend to support TLS
> >> but
> >> actually only support SSL3 die a horrible death?
> 
> I agree with Richard that this seems . In particular, the session hash
> / extended master secret [1] specification requires an extension to
> work securely.

which is not used by openssl by default...

> Not having the SNI extension is likely to cause
> security issues (using a different and perhaps though-of-as-unused
> certificate).

SNI needs to be set manually on a connection, many openssl consumers still 
don't do it... and if you don't verify server certificate no amount of 
extensions will help you

> Many servers use the values in the signature_algorithms
> extension to determine whether to use a SHA-2 or SHA-1 certificate,

Interesting, haven't seen such ones. Can you give examples?

Still, how can you test if the server does the sane thing if the client 
doesn't provide signature_algorithms if you have such a server?

> so
> not sending signature_algorithms is likely to cause problems for any
> client that disables support for SHA-1 certificates.

exactly what every piece of documentation surrounding this option says

> Resolving these TLS (extension) intolerance issues requires collective
> action, and it would be great if OpenSSL could do its part by not
> adding features like this that exist purely to avoid participating in
> the collective action, especially when the added feature disables
> other important security features.

It's implemented not so that you can interoperate with them, I implemented it 
so that you can detect *if* this is the reason why you can't interoperate with 
them. Unfortunately it's rather hard to test interoperability without actually 
being interoperable...

There are broken clients and there are broken servers and there are broken 
middle boxes out there. The library already has stuff like 
SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION which is *really* dangerous. 
SSL_OP_NO_TLSEXT is less of an issue than export grade ciphers. 
SSL_OP_NO_TLSEXT is the default mode of operation for 0.9.8, and I think we 
can agree that while 0.9.8 is old it's still secure.

-- 
Regards,
Hubert Kario