[openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

Rich Salz via RT
On Thu May 01 12:29:58 2014, [hidden email] wrote:

> Hi,
>
> 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.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

Hanno Böck-4
On Thu, 1 May 2014 13:26:48 +0200
"Stephen Henson via RT" <[hidden email]> wrote:

> 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 :-(

Maybe this should teach us a lesson: Adding more and more Workarounds
for broken stuff isn't the way to go forward. The way to go forward is
to fix broken stuff.

(we have another pretty simliar example - browsers implemented
out-of-protocol downgrades to "fix" broken implementations just to
notice that they introduced downgrade attacks and accidental downgrades
- now there's a proposal for a downgrade protection extension that only
tries to fix a problem we wouldn't have in the first place if people
didn't introduce stupid workarounds for broken stuff)

--
Hanno Böck
http://hboeck.de/

mail/jabber: [hidden email]
GPG: BBB51E42

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

Rob Stradling
In reply to this post by Rich Salz via RT
On 01/05/14 12:26, Stephen Henson via RT wrote:
> On Thu May 01 12:29:58 2014, [hidden email] wrote:
>> Hi,
>>
>> SUSE has received a bugreport from a user, that the "padding"
>> extension
>> change breaks IronPort SMTP appliances.
<snip>
> 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.

Steve, have you considered trimming the DEFAULT cipher list?

It's currently...
#define SSL_DEFAULT_CIPHER_LIST "ALL:!aNULL:!eNULL:!SSLv2"

I wonder how many of these ciphers are actually ever negotiated in
real-world use.

> 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.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Jan
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

Jan
In reply to this post by Hanno Böck-4
+1

On 1. Mai 2014 13:35:19 MESZ, "Hanno Böck" <[hidden email]> wrote:
On Thu, 1 May 2014 13:26:48 +0200
"Stephen Henson via RT" <[hidden email]> wrote:

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 :-(

Maybe this should teach us a lesson: Adding more and more Workarounds
for broken stuff isn't the way to go forward. The way to go forward is
to fix broken stuff.

(we have another pretty simliar example - browsers implemented
out-of-protocol downgrades to "fix" broken implementations just to
notice that they introduced downgrade attacks and accidental downgrades
- now there's a proposal for a downgrade protection extension that only
tries to fix a problem we wouldn't have in the first place if people
didn't introduce stupid workarounds for broken stuff)

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

Kurt Roeckx
In reply to this post by Hanno Böck-4
On Thu, May 01, 2014 at 01:35:19PM +0200, Hanno Böck wrote:
>
> Maybe this should teach us a lesson: Adding more and more Workarounds
> for broken stuff isn't the way to go forward. The way to go forward is
> to fix broken stuff.

The problem isn't always to fix the broken stuff but ussually to get
people to upgrade to the fixed version.  People are scared of
changes.


Kurt

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

Hanno Böck-4
On Thu, 1 May 2014 14:29:44 +0200
Kurt Roeckx <[hidden email]> wrote:

> On Thu, May 01, 2014 at 01:35:19PM +0200, Hanno Böck wrote:
> >
> > Maybe this should teach us a lesson: Adding more and more
> > Workarounds for broken stuff isn't the way to go forward. The way
> > to go forward is to fix broken stuff.
>
> The problem isn't always to fix the broken stuff but ussually to get
> people to upgrade to the fixed version.  People are scared of
> changes.

I'm well aware of that, but I think there is another option.
If browsers (or other kind of tls using software) would display a
warning "your stuff is broken, it will no longer work with our next
version if you don't install updates on your whatever hw, tell your
admin NOW", I'm pretty sure those people would update their stuff.

Certainly better than inventing yet another "workaround for broken
stuff"-tls-extensions (because we all should know by now: too many tls
extensions make the protocol too complex and can hurt).

--
Hanno Böck
http://hboeck.de/

mail/jabber: [hidden email]
GPG: BBB51E42

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

Kurt Roeckx
On Thu, May 01, 2014 at 02:45:19PM +0200, Hanno Böck wrote:

> On Thu, 1 May 2014 14:29:44 +0200
> Kurt Roeckx <[hidden email]> wrote:
>
> > On Thu, May 01, 2014 at 01:35:19PM +0200, Hanno Böck wrote:
> > >
> > > Maybe this should teach us a lesson: Adding more and more
> > > Workarounds for broken stuff isn't the way to go forward. The way
> > > to go forward is to fix broken stuff.
> >
> > The problem isn't always to fix the broken stuff but ussually to get
> > people to upgrade to the fixed version.  People are scared of
> > changes.
>
> I'm well aware of that, but I think there is another option.
> If browsers (or other kind of tls using software) would display a
> warning "your stuff is broken, it will no longer work with our next
> version if you don't install updates on your whatever hw, tell your
> admin NOW", I'm pretty sure those people would update their stuff.
>
> Certainly better than inventing yet another "workaround for broken
> stuff"-tls-extensions (because we all should know by now: too many tls
> extensions make the protocol too complex and can hurt).

I'm just backporting the Safari detection to not to ECDSA since we
plan to enable ECDHE in Debian stable and it seems their are still
a significate enough amount of users using the broken version.


Kurt

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

Viktor Dukhovni
In reply to this post by Rich Salz via RT
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                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

Salz, Rich
In reply to this post by Rob Stradling
>Steve, have you considered trimming the DEFAULT cipher list?
>It's currently...
>#define SSL_DEFAULT_CIPHER_LIST "ALL:!aNULL:!eNULL:!SSLv2"
> I wonder how many of these ciphers are actually ever negotiated in real-world use.

I'm forwarding a bit of internal discussion; hope it's useful.  This is from one of our chief info-sec people:
My weak opinion is that cipher brokenness is most important (so put 3DES and RC4 last, and the AEAD modes ahead of the MAC-then-encrypt modes), followed by  hash strength, followed by PFS presence, followed by SHA and AES bit length.  I think that would give us:

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-GCM-SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256
AES256-GCM-SHA384
AES128-GCM-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-ECDSA-AES256-SHA256
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES128-SHA256
AES256-SHA256
AES128-SHA256
AES128-SHA
RC4-SHA
DES-CBC3-SHA

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [hidden email]; Twitter: RichSalz

:��I"Ϯ��r�m���� (���Z+�7�zZ)���1���x ��h���W^��^��%����&jם.+-1�ځ��j:+v�������h�
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

John Foley-3
How prevalent is RC4 today?  While web browsers still advertise RC4
cipher suites, how often do you see RC4 cipher suites advertised by the
client and no AES or 3DES suites advertised?  Does Akamai have any data
on this?  Maybe RC4 should now be disabled by default.


On 05/02/2014 09:49 AM, Salz, Rich wrote:

>> Steve, have you considered trimming the DEFAULT cipher list?
>> It's currently...
>> #define SSL_DEFAULT_CIPHER_LIST "ALL:!aNULL:!eNULL:!SSLv2"
>> I wonder how many of these ciphers are actually ever negotiated in real-world use.
> I'm forwarding a bit of internal discussion; hope it's useful.  This is from one of our chief info-sec people:
> My weak opinion is that cipher brokenness is most important (so put 3DES and RC4 last, and the AEAD modes ahead of the MAC-then-encrypt modes), followed by  hash strength, followed by PFS presence, followed by SHA and AES bit length.  I think that would give us:
>
> ECDHE-ECDSA-AES256-GCM-SHA384
> ECDHE-ECDSA-AES256-GCM-SHA256
> ECDHE-ECDSA-AES128-GCM-SHA256
> ECDHE-RSA-AES256-GCM-SHA384
> ECDHE-RSA-AES128-GCM-SHA256
> AES256-GCM-SHA384
> AES128-GCM-SHA256
> ECDHE-ECDSA-AES256-SHA384
> ECDHE-ECDSA-AES256-SHA256
> ECDHE-ECDSA-AES128-SHA256
> ECDHE-RSA-AES256-SHA384
> ECDHE-RSA-AES128-SHA256
> AES256-SHA256
> AES128-SHA256
> AES128-SHA
> RC4-SHA
> DES-CBC3-SHA
>
> --  
> Principal Security Engineer
> Akamai Technologies, Cambridge, MA
> IM: [hidden email]; Twitter: RichSalz
>
> :��I"Ϯ��r�m���� (���Z+�7�zZ)���1���x ��h���W^��^��%��

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

Salz, Rich
The IETF TLS-WG is likely (my opinion) to soon put out an RFC that, basically deprecates RC4.

We have customers with many embedded devices (old web TV's, almost every game console, etc), not just browsers.  But for OpenSSL and in particular new code, dropping RC4 is the thing to do.

        /r$

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [hidden email]; Twitter: RichSalz
:��I"Ϯ��r�m���� (���Z+�7�zZ)���1���x ��h���W^��^��%����&jם.+-1�ځ��j:+v�������h�
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

Kurt Roeckx
In reply to this post by Salz, Rich
On Fri, May 02, 2014 at 09:49:47AM -0400, Salz, Rich wrote:
> >Steve, have you considered trimming the DEFAULT cipher list?
> >It's currently...
> >#define SSL_DEFAULT_CIPHER_LIST "ALL:!aNULL:!eNULL:!SSLv2"
> > I wonder how many of these ciphers are actually ever negotiated in real-world use.
>
> I'm forwarding a bit of internal discussion; hope it's useful.  This is from one of our chief info-sec people:
> My weak opinion is that cipher brokenness is most important (so put 3DES and RC4 last, and the AEAD modes ahead of the MAC-then-encrypt modes), followed by  hash strength, followed by PFS presence, followed by SHA and AES bit length.  I think that would give us:

As I understand things, RC4 needs to be before 3DES because some
exchange servers have broken 3DES and don't support anything else.

> ECDHE-ECDSA-AES256-GCM-SHA384
> ECDHE-ECDSA-AES256-GCM-SHA256

I don't this one exists and you meant the next one.

> ECDHE-ECDSA-AES128-GCM-SHA256
> ECDHE-RSA-AES256-GCM-SHA384
> ECDHE-RSA-AES128-GCM-SHA256
> AES256-GCM-SHA384
> AES128-GCM-SHA256
> ECDHE-ECDSA-AES256-SHA384
> ECDHE-ECDSA-AES256-SHA256
> ECDHE-ECDSA-AES128-SHA256
> ECDHE-RSA-AES256-SHA384
> ECDHE-RSA-AES128-SHA256
> AES256-SHA256
> AES128-SHA256
> AES128-SHA
> RC4-SHA
> DES-CBC3-SHA

I'm not really a fan of the ECDSA ciphers and would really put RSA
in front of ECDSA, or remove them.  You could optionally also
remove all the AES256 versions.

Since it's SMTP, you could also add anonymous ciphers.

Anyway, a list of ciphers isn't that useful, the CIPHER_LIST
to get the needed ones is probably more useful.


Kurt

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

Kurt Roeckx
In reply to this post by John Foley-3
On Fri, May 02, 2014 at 09:58:37AM -0400, John Foley wrote:
> How prevalent is RC4 today?

Here is a recent link for web servers:
https://lists.fedoraproject.org/pipermail/security/2014-April/001810.html


Kurt

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

Hubert Kario
In reply to this post by John Foley-3
----- Original Message -----
> From: "John Foley" <[hidden email]>
> To: [hidden email]
> Sent: Friday, May 2, 2014 3:58:37 PM
> Subject: Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
>
> How prevalent is RC4 today?  While web browsers still advertise RC4
> cipher suites, how often do you see RC4 cipher suites advertised by the
> client and no AES or 3DES suites advertised?  Does Akamai have any data
> on this?  Maybe RC4 should now be disabled by default.

After scanning Alexa top 1 million sites (as a semi-representative sample) the stats
look like this:

RC4 Supported             268298    87.8859%
RC4 Only                  5418      1.7748%
RC4 Preferred             59552     19.5073%
RC4 preferred in TLS1.1+  31737     10.396%

> On 05/02/2014 09:49 AM, Salz, Rich wrote:
> >> Steve, have you considered trimming the DEFAULT cipher list?
> >> It's currently...
> >> #define SSL_DEFAULT_CIPHER_LIST "ALL:!aNULL:!eNULL:!SSLv2"
> >> I wonder how many of these ciphers are actually ever negotiated in
> >> real-world use.
> > I'm forwarding a bit of internal discussion; hope it's useful.  This is
> > from one of our chief info-sec people:
> > My weak opinion is that cipher brokenness is most important (so put 3DES
> > and RC4 last, and the AEAD modes ahead of the MAC-then-encrypt modes),

RC4 is broken, 3DES is just weak (as weak as 2048 bit RSA), you shouldn't put
RC4 before 3DES

> > followed by  hash strength, followed by PFS presence, followed by SHA and

It could be argued that even MD5 is secure when used as PRF or HMAC.
SHA-1 when used as a PRF or HMAC has a higher security margin than AES-128.

See http://openssl.6102.n7.nabble.com/Insecure-DEFAULT-cipher-set-td48995.html
for in depth discussion.

> > AES bit length.  I think that would give us:
> >
> > ECDHE-ECDSA-AES256-GCM-SHA384
> > ECDHE-ECDSA-AES256-GCM-SHA256
> > ECDHE-ECDSA-AES128-GCM-SHA256
> > ECDHE-RSA-AES256-GCM-SHA384
> > ECDHE-RSA-AES128-GCM-SHA256
> > AES256-GCM-SHA384
> > AES128-GCM-SHA256
> > ECDHE-ECDSA-AES256-SHA384
> > ECDHE-ECDSA-AES256-SHA256
> > ECDHE-ECDSA-AES128-SHA256
> > ECDHE-RSA-AES256-SHA384
> > ECDHE-RSA-AES128-SHA256
> > AES256-SHA256
> > AES128-SHA256
> > AES128-SHA
> > RC4-SHA
> > DES-CBC3-SHA
> >
> > --
> > Principal Security Engineer
> > Akamai Technologies, Cambridge, MA
> > IM: [hidden email]; Twitter: RichSalz
> >
> > :��I"Ϯ��r�m����(���Z+�7�zZ)���1���x��h���W^��^��%��
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> Development Mailing List                       [hidden email]
> Automated List Manager                           [hidden email]
>

--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: [hidden email]
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

Salz, Rich
> After scanning Alexa top 1 million sites (as a semi-representative sample) the stats look like this:

How many of those sites are served by CDN's, for example?

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [hidden email]; Twitter: RichSalz

:��I"Ϯ��r�m���� (���Z+�7�zZ)���1���x ��h���W^��^��%����&jם.+-1�ځ��j:+v�������h�
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

Hubert Kario
----- Original Message -----
> From: "Rich Salz" <[hidden email]>
> To: [hidden email]
> Sent: Friday, May 2, 2014 4:28:44 PM
> Subject: RE: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
>
> > After scanning Alexa top 1 million sites (as a semi-representative sample)
> > the stats look like this:
>
> How many of those sites are served by CDN's, for example?

I don't know, if you have a semi-robust way to detect that I'm willing to implement it.

Though, the scan was more of a ballpark estimate than a truly representative result.

--
Regards,
Hubert Kario
BaseOS QE Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

Salz, Rich
> > How many of those sites are served by CDN's, for example?

> I don't know, if you have a semi-robust way to detect that I'm willing to implement it.

Short of giving out customer lists :) I don't.  I suppose you could do a DNS lookup and see if you got a CNAME to something else.

> Though, the scan was more of a ballpark estimate than a truly representative result.

Oh it's definitely interesting.  My point is that the stats might be weighted by the fact that 1/3 of them are being served by a single entity, for example.

        /r$

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [hidden email]; Twitter: RichSalz
:��I"Ϯ��r�m���� (���Z+�7�zZ)���1���x ��h���W^��^��%����&jם.+-1�ځ��j:+v�������h�
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

Viktor Dukhovni
In reply to this post by Rob Stradling
On Thu, May 01, 2014 at 12:35:52PM +0100, Rob Stradling wrote:

> Steve, have you considered trimming the DEFAULT cipher list?

This would be a *major* incompatibility.  The master branch has
security levels, which are a step in the right direction.

It is perhaps safe to drop EXPORT, LOW and MD5, and not much else.

> It's currently...
> #define SSL_DEFAULT_CIPHER_LIST "ALL:!aNULL:!eNULL:!SSLv2"
>
> I wonder how many of these ciphers are actually ever negotiated in
> real-world use.

There are a lot of "real-world" uses that we don't know about.
The world is not just HTTPS.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

Viktor Dukhovni
In reply to this post by Kurt Roeckx
On Fri, May 02, 2014 at 04:12:33PM +0200, Kurt Roeckx wrote:

> As I understand things, RC4 needs to be before 3DES because some
> exchange servers have broken 3DES and don't support anything else.

No, that's a misreading of my posts.  It suffices for RC4-SHA to
be in the 64 ciphersuites in the client SSL HELLO.  The servers in
question will choose RC4-SHA if offered in the first 64 regardless
of client preference.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

Piotr Sikora
In reply to this post by Hubert Kario
Hey,

>> How many of those sites are served by CDN's, for example?
>
> I don't know, if you have a semi-robust way to detect that I'm willing to implement it.
>
> Though, the scan was more of a ballpark estimate than a truly representative result.

Whois the IP? That should work for majority of the CDN.

For Amazon, you can distinguish S3 from CloudFront by looking for at
the HTTP headers:
- X-Amz-Cf-Id,
- Via: ... .cloudfront.net (CloudFront),
- X-Cache: ... from cloudfront.

Best regards,
Piotr Sikora
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
12