On Monday 26 January 2015 10:03:30 Brian Smith wrote: > Hubert Kario <hka...@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 _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev