Subject: [TLS] Empty extensions don't go last

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Mar 2016 16:30:29 +1100

(This is probably already known to a bunch of people, but it's
probably a good idea to put out there.)

When deploying EMS, we recently discovered, with the help of our
friends at Google (who discovered this long before that) a quirk in
some implementations.

Short story:  Don't place an empty extension at the end of your
ClientHello.  You will find that a small number of servers choke.

---

From: Wan-Teh Chang <[email-masked]>
Date: Thu, 24 Mar 2016 00:04:24 -0700

> ClientHello.  You will find that a small number of servers choke.

This interop problem surfaces when we added to Chrome the
signed_certificate_timestamp extension for Certificate Transparency
(RFC 6962):

https://bugs.chromium.org/p/chromium/issues/detail?id=353009#c4
https://bugs.chromium.org/p/chromium/issues/detail?id=363583#c13
https://codereview.chromium.org/240633006

The change that David Benjamin made to
ssl3_CalculatePaddingExtensionLength() in his patch probably should
also be considered if the padding extension (RFC 7685) is placed at
the end:

https://codereview.chromium.org/240633006/diff/110001/net/third_party/nss/ssl/ssl3ext.c

Wan-Teh Chang

---

From: Andrei Popov <[email-masked]>
Date: Thu, 24 Mar 2016 17:33:28 +0000

Yes, we found this a while ago as well, and had to move extensions around.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Wan-Teh Chang
Sent: Thursday, March 24, 2016 12:04 AM
To: Martin Thomson <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Empty extensions don't go last

> ClientHello.  You will find that a small number of servers choke.

This interop problem surfaces when we added to Chrome the signed_certificate_timestamp extension for Certificate Transparency (RFC 6962):

https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fbugs.chromium.org%2fp%2fchromium%2fissues%2fdetail%3fid%3d353009%23c4&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c916a8a6aa2eb4b8fd3e908d353b28e2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=YUuVpA6X5QhQZGOS%2bHbs30ooKE%2bW9U0W4cr6tG%2bbKEo%3d
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fbugs.chromium.org%2fp%2fchromium%2fissues%2fdetail%3fid%3d363583%23c13&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c916a8a6aa2eb4b8fd3e908d353b28e2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ddplXkVwDs4SMUaRpcdc0TY%2fipYDB8rYwWeTAsvc0Kc%3d
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcodereview.chromium.org%2f240633006&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c916a8a6aa2eb4b8fd3e908d353b28e2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=5bQKBz4Y8R%2fmVKHLzpbnVBOj428W0T3regpgaBkl0MY%3d

The change that David Benjamin made to
ssl3_CalculatePaddingExtensionLength() in his patch probably should also be considered if the padding extension (RFC 7685) is placed at the end:

https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcodereview.chromium.org%2f240633006%2fdiff%2f110001%2fnet%2fthird_party%2fnss%2fssl%2fssl3ext.c&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c916a8a6aa2eb4b8fd3e908d353b28e2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jH5GKij0h%2boPSy4BaRvePsiN7zx2gycuSYraYDiTS4E%3d

Wan-Teh Chang

_______________________________________________
TLS mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c916a8a6aa2eb4b8fd3e908d353b28e2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=gdOOA8X6H1QMVzL3JLh%2b%2f0YHesyIQKZjjhimdP3%2fYn0%3d