On Jul 23, 2014, at 8:04 AM, Bob Beck <b...@obtuse.com> wrote: > An interesting thought Hanno - do we know what other implementations > (Polar, GnuTLS, etc.) do by default?
PolarSSL does not generate the extension, but tolerates it on the server side. GnuTLS generates it if you enable the %COMPAT or %DUMBFW priority strings. > I'm inclined to agree that it never should have been done. Having said > that, before we nuke it we kind of > need to know if this is has become de-facto standard behaviour thanks > to OpenSSL doing this in the > first place. > > -Bob > > > On Wed, Jul 23, 2014 at 2:20 AM, Hanno Böck <ha...@hboeck.de> wrote: >> Hi, >> >> Quick background: Some router firmwares from F5 have a bug that they >> fail if the SSL handshake is between 256 and 511 bytes. >> >> Following up that openssl and other major ssl implementations >> introduced a TLS padding extension that does nothing else than padding >> the handshake if it is between these sizes. >> >> IMHO this is the wrong way of doing things, because it hides bugs >> instead of fixing them. And a bunch of alike workarounds in the past >> are one of the reasons TLS is such a mess these days. >> Also, there have already been devices found that break with this >> workaround because they fail if the ssl handshake is above 512 bytes >> [3]. >> >> openssl unconditionally enables the padding extension. I propose a >> simple step: Just remove it from libressl. >> >> >> >> [1] https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html >> [2] http://www.ietf.org/mail-archive/web/tls/current/msg10423.html >> [3] http://www.ietf.org/mail-archive/web/tls/current/msg12143.html >> >> cu, >> -- >> Hanno Böck >> http://hboeck.de/ >> >> mail/jabber: ha...@hboeck.de >> GPG: BBB51E42 >
