Subject: [TLS] TLS padding breaks ironport

From: Kurt Roeckx <[email-masked]>
Date: Thu, 17 Apr 2014 22:30:56 +0200

I've just been pointed to:
http://postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html

Kurt

---

From: Adam Langley <[email-masked]>
Date: Thu, 17 Apr 2014 13:41:32 -0700

> http://postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html

Thanks for the heads up. SMTP is one of those corners that Chrome 33
didn't manage to shake down for the padding extension.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Brian Smith <[email-masked]>
Date: Thu, 17 Apr 2014 13:47:02 -0700

> http://postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html

See also https://bugzilla.mozilla.org/show_bug.cgi?id=989062, which is also
about a compatibility issue with the padding extension, and which affects
HTTPS, not just email. In particular, some websites break in Firefox 29+
due to this, and those websites result in non-secure TLS version
intolerance fallback in some Chrome versions.

Wan-Teh Chang found that the server mentioned in the Mozilla bug report is
sensitive to the ordering of the extensions in the client hello, and that
changing the client hello extension order in NSS got the site working. But,
we have yet to figure out what the optimal ordering is for maximizing
compatibility with all products globally.

It seems like the Mozilla bug report and the OpenSSL bug report may be
referring to the same issue in the same server TLS stack. In that case, it
may be a good idea for OpenSSL to also consider fixing the issue by
changing the ordering of extensions in its ClientHello.

And/or, we may try one or both the three following workarounds:

(1) If the ClientHello size *without* the session ticket extension included
is less than 256 bytes, then don't send the padding extension, even if the
ClientHello is in the "danger zone" of 256-512 bytes. The assumption here
is that any product using session tickets that would cause the Client Hello
size to enter the danger zone would not have the incompatibility that the
padding extension works around.

(2) If the ClientHello would contain a session ticket *at all*, then don't
send the padding extension. The (unverified) assumption here would be that
the F5 products that had the compatibility issue with ClientHellos in the
danger zone do not support session tickets.

(3) Don't use the padding extension at all, and instead include a fake
session ticket in the session ticket extension, when the ClientHello size
is in the danger zone and there's no session ticket to send. The assumption
here, which is almost certainly invalid, is that server implementations all
silently discard malformed session tickets sent by the client.

Cheers,
Brian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Apr 2014 14:15:46 -0700

On 17 April 2014 13:47, Brian Smith <[email-masked]> wrote:
> session ticket in the session ticket extension, when the ClientHello size is
> in the danger zone and there's no session ticket to send. The assumption

Yes, that seems unlikely to work in the extreme, based on the
description of the SSL2/TLS length bug we have.  The only trigger
there is the length of the ClientHello.  I think that it might be OK
to turn off padding if there is a session ticket.  This might be
conditional, as you describe, but I'm guessing that the only cases
where we enter the 256-511 range is as a result of the session ticket,
so there is probably no difference between (1) and (2) in practice.