On Thu, May 01, 2014 at 01:26:48PM +0200, Stephen Henson via RT wrote:
> > Workaround: Force protocol to SSLv3 or recompile without the define
> > above.
If there were an SSL_OP_ flag to allow applications to disable
padding, that would be useful for SMTP applications. There is
precious little presence of (buggy) F5 load-balancers in front of
SMTP servers.
> 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 :-(
What I don't know is what fraction of Ironport devices have the problem.
I know of 2 that do (from the original report), and 3 that don't (MX
hosts for ironport.com, assumed to be actual ironport devices).
> If you use a smaller cipherstring it should also work without
> having to force SSLv3.
Even with EXPORT and LOW ciphers disabled, the Postfix client HELLO
is 287 bytes before padding. With DANE it will typically include
SNI. I don't think consistently staying out of the danger zone is
realistic (below padding starts at 0x124-5 = 0x11f and has a length
of 4 + 0xdd = 0xe1, so the unpadded HELLO is 256 + 31 = 287 bytes).
write to 7FC460C12F00 [7FC46100A400] (517 bytes => 517 (0x205))
0000 16 03 01 02 00 01 00 01|fc 03 03 00 5a e2 2b 4c ........ ....Z.+L
[...]
0120 0f 00 01 01 00 15 00 dd| ........
0128 - <SPACES/NULLS>
SSL_connect:SSLv2/v3 write client hello A
> 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.
This would have to be done across the board, don't have a client-side
list of all the problem destinations. I don't like disabling
ciphersuites, this reduces interoperability in an opportunistic
TLS protocol causing potential fallback to cleartext. Sure on a
per-site basis, one could attempt a much shorter cipherlist.
With OpenSSL 1.0.1g, I can squeeze the HELLO down to 227 bytes with:
ALL:+RC4:!LOW:!EXPORT:!MD5:!SRP:!PSK:!SEED:!IDEA:!DSS:!kECDHe:!kECDHr
but that leaves little room for SNI, and new ciphers coming soon
in 1.0.2 and master. The 1.0.1g cipherlist length is 48 in this
case, which consumes 96 bytes in the handshake. The anonymous
ciphers are 13 of these, accounting for 26 bytes. Much of the space
is taken-up with various TLSv1.2 extensions (elliptic curves oids,
supported digests, ...). Even more extensions are likely in the
future.
We should not have to hand-tune TLS for each destination. Right
now Postfix users hand-tune for Exchange 2003 destinations (which
need RC4-SHA in the first 64 cipher-suites in the HELLO) and now
possibly for Ironport.
The most radically short (29 cipher suites), and yet reasonably
interoperable list I can come up with for SMTP is:
aRSA:-aRSA:aECDSA:-aECDSA:kRSA:-kRSA:kEDH:-kEDH:kEECDH:-kEECDH:aNULL:-aNULL:AES128:CAMELLIA128:3DES:RC4:!EXPORT:!LOW:!MD5:!SRP:!PSK:!aDSS:!kECDHe:!kECDHr
I don't think I or Postfix users should have to go to such lengths
to get interoperable behaviour.
Expanded that list is:
$ openssl ciphers -v
'aRSA:-aRSA:aECDSA:-aECDSA:kRSA:-kRSA:kEDH:-kEDH:kEECDH:-kEECDH:aNULL:-aNULL:AES128:CAMELLIA128:3DES:RC4:!EXPORT:!LOW:!MD5:!SRP:!PSK:!aDSS:!kECDHe:!kECDHr'
| while read c; do set -- $c; printf "%-29s %7s %-7s %s %s %s\n" "$@"; done
AECDH-AES128-SHA SSLv3 Kx=ECDH Au=None Enc=AES(128) Mac=SHA1
ADH-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=None Enc=AESGCM(128) Mac=AEAD
ADH-AES128-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(128) Mac=SHA256
ADH-AES128-SHA SSLv3 Kx=DH Au=None Enc=AES(128) Mac=SHA1
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256
ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
ADH-CAMELLIA128-SHA SSLv3 Kx=DH Au=None Enc=Camellia(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1
CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1
AECDH-DES-CBC3-SHA SSLv3 Kx=ECDH Au=None Enc=3DES(168) Mac=SHA1
ADH-DES-CBC3-SHA SSLv3 Kx=DH Au=None Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
AECDH-RC4-SHA SSLv3 Kx=ECDH Au=None Enc=RC4(128) Mac=SHA1
ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1
ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1
RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
