Re: [TLS] TLS padding breaks ironport
Brian Smith <brian@briansmith.org> Thu, 17 April 2014 20:47 UTC
Return-Path: <brian@briansmith.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CC01A019E for <tls@ietfa.amsl.com>; Thu, 17 Apr 2014 13:47:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.856
X-Spam-Level:
X-Spam-Status: No, score=-0.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoD2tSTHXHxx for <tls@ietfa.amsl.com>; Thu, 17 Apr 2014 13:47:06 -0700 (PDT)
Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2731A0045 for <tls@ietf.org>; Thu, 17 Apr 2014 13:47:06 -0700 (PDT)
Received: by mail-qa0-f47.google.com with SMTP id m5so862972qaj.6 for <tls@ietf.org>; Thu, 17 Apr 2014 13:47:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KjlzmlMa+Uwxl30uxZ6n1l2u+wOlVpbYYeioy25ByzE=; b=lofV5wJAf7QX79Ck0qNGuCuEwI6NanU725ttkrsVNuyiBDPMqTvEvzh2EmlWtl/9GL 34JhWt8nBuzQZuBXbQo/s4LfNe/OyM+d2Qg5Ywh6lGEnk66x/PjGxa81KDwjF/Il13xW pLN+T4Xwlfgeiwx9KzoRK4ajGr/M98FJWVSnk3LoEt4ZSv51nxCL1U2/oOFuXTzJ7Upk BWt30gU28NUGnX0JiEhUp5VKaiUUeIxVxV4jb+9L9hGLd46Zehhg/tgNjVoVbFODsf7C jd6FG/fvOBGcRIMHU6UO2yonuiys41caUVFLadtwhE2Pru/9IhLRB24vOVENMJ/V5jbu v4Sg==
X-Gm-Message-State: ALoCoQlm+MUzNTzmQRbdu5SCocze8cSoeuieV1teoEk3f0iE2Nv8uVyRU+C1b5Xs0LawYFDl3UO2
MIME-Version: 1.0
X-Received: by 10.224.30.70 with SMTP id t6mr15962081qac.30.1397767622755; Thu, 17 Apr 2014 13:47:02 -0700 (PDT)
Received: by 10.224.39.18 with HTTP; Thu, 17 Apr 2014 13:47:02 -0700 (PDT)
In-Reply-To: <20140417203056.GA14753@roeckx.be>
References: <20140417203056.GA14753@roeckx.be>
Date: Thu, 17 Apr 2014 13:47:02 -0700
Message-ID: <CAFewVt5QpM-Bg=3jab=5X2YJNYrehpjVx+hJfQFihLUwXsaaWg@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Kurt Roeckx <kurt@roeckx.be>
Content-Type: multipart/alternative; boundary="047d7bdca66aa219ee04f7432279"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AdEYqlGH4RXbqDvMsqgJ0O2V-2I
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] TLS padding breaks ironport
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Apr 2014 20:47:11 -0000
On Thu, Apr 17, 2014 at 1:30 PM, Kurt Roeckx <kurt@roeckx.be> wrote: > I've just been pointed to: > > 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
- [TLS] TLS padding breaks ironport Kurt Roeckx
- Re: [TLS] TLS padding breaks ironport Adam Langley
- Re: [TLS] TLS padding breaks ironport Brian Smith
- Re: [TLS] TLS padding breaks ironport Martin Thomson
- Re: [TLS] TLS padding breaks ironport Kurt Roeckx