On Thu 01 May 2014 13:26:48 Stephen Henson via RT wrote: > On Thu May 01 12:29:58 2014, meiss...@suse.de wrote: > > SUSE has received a bugreport from a user, that the "padding" > > extension > > change breaks IronPort SMTP appliances. > > > > There might a RT on this already, not sure. > > > > https://bugzilla.novell.com/show_bug.cgi?id=875639 > > http://postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-> > > > appliances-interop-issue-td66873.html > > > > Quoting from our openSUSE bugreport: > > > > Last upgrade to openssl-1.0.1g-11.36.1.x86_64 broke SSL connections to > > some > > services, e.g. Cisco Ironport SMTP appliances. > > > > 1.0.1g not only fixes the Heartbleed bug but also adds another change > > by > > adding: > > #define TLSEXT_TYPE_padding 21 > > > > This in turn breaks SSL connections to e.g. Ironports, probably > > others: > > SSL23_GET_SERVER_HELLO:tlsv1 alert decode error > > > > Workaround: Force protocol to SSLv3 or recompile without the define > > above. > > Ironically it was added as a workaround for another bug. The padding > extension was believed to have no side effects... obviously that isn't true > :-( > > If you use a smaller cipherstring it should also work without having to > force SSLv3. > > The padding extension is only used if the ClientHello would be between 256 > and 511 bytes in length so if you reduce the number of ciphersuites it wont > be used.
maybe a "quick" system would be useful. the default behavior is to do the right thing, but through a series of env vars, quirks can be injected at the right place ? then there is no wishy/washy behavior where we try to appease every broken system out there simultaneously. -mike
signature.asc
Description: This is a digitally signed message part.
