Im­pe­ri­alVi­o­let

Today, TLS con­nec­tions pre­dom­i­nantly use one of two fam­i­lies of ci­pher suites: RC4 based or AES-CBC based. How­ever, in re­cent years both of these fam­i­lies of ci­pher suites have suf­fered major prob­lems. TLS's CBC con­struc­tion was the sub­ject of the BEAST at­tack (fixed with 1/n-1 record split­ting or TLS 1.1) and Luck­y13 (fixed with com­plex im­ple­men­ta­tion tricks). RC4 was found to have key-stream bi­ases that can­not ef­fec­tively be fixed.

Al­though AES-CBC is cur­rently be­lieved to be se­cure when cor­rectly im­ple­mented, a cor­rect im­ple­men­ta­tion is so com­plex that there re­mains strong mo­ti­va­tion to re­place it.

Clearly we need some­thing bet­ter. An ob­vi­ous al­ter­na­tive is AES-GCM (AES-GCM is AES in counter mode with a poly­no­mial au­then­ti­ca­tor over GF(2¹²⁸)), which is al­ready spec­i­fied for TLS and has some im­ple­men­ta­tions. Sup­port for it is in the lat­est ver­sions of OpenSSL and it has been the top pref­er­ence ci­pher of Google servers for some time now. Chrome sup­port should be com­ing in Chrome 31, which is ex­pected in No­vem­ber. (Al­though we're still fight­ing to get TLS 1.2 sup­port de­ployed in Chrome 30 due to buggy servers.)

AES-GCM isn't per­fect, how­ever. Firstly, im­ple­ment­ing AES and GHASH (the au­then­ti­ca­tor part of GCM) in soft­ware in a way which is fast, se­cure and has good key agility is very dif­fi­cult. Both prim­i­tives are suited to hard­ware im­ple­men­ta­tions and good soft­ware im­ple­men­ta­tions are wor­thy of con­fer­ence pa­pers. The fact that a naive im­ple­men­ta­tion (which is also what's rec­om­mended in the stan­dard for GHASH!) leaks tim­ing in­for­ma­tion is a prob­lem.

AES-GCM also isn't very quick on lower-pow­ered de­vices such as phones, and phones are now a very im­por­tant class of de­vice. A stan­dard phone (which is al­ways de­fined by what­ever I hap­pen to have in my pocket; a Galaxy Nexus at the mo­ment) can do AES-128-GCM at only 25MB/s and AES-256-GCM at 20MB/s (both mea­sured with an 8KB block size).

Lastly, if we left things as they are, AES-GCM would be the only good ci­pher suite in TLS. While there are spec­i­fi­ca­tions for AES-CCM and for fix­ing the AES-CBC con­struc­tion, they are all AES based and, in the past, hav­ing some di­ver­sity in ci­pher suites has proven use­ful. So we would be look­ing for an al­ter­na­tive even if AES-GCM were per­fect.

In light of this, Google servers and Chrome will soon be sup­port­ing ci­pher suites based around ChaCha20 and Poly1305. These are prim­i­tives de­vel­oped by Dan Bern­stein and are fast, se­cure, have high qual­ity, pub­lic do­main im­ple­men­ta­tions, are nat­u­rally con­stant time and have nearly per­fect key agility.

On the same phone as the AES-GCM speeds were mea­sured, the ChaCha20+Poly1305 ci­pher suite runs at 92MB/s (which should be com­pared against the AES-256-GCM speed as ChaCha20 is a 256-bit ci­pher).

In ad­di­tion to sup­port in Chrome and on Google's servers, my­self and my col­league, Elie Bursztein, are work­ing on patches for NSS and OpenSSL to sup­port this ci­pher suite. (And I should thank Dan Bern­stein, An­drew M, Ted Krovetz and Peter Schwabe for their ex­cel­lent, pub­lic do­main im­ple­men­ta­tions of these al­go­rithms. Also Ben Lau­rie and Wan-Teh Chang for code re­views, sug­ges­tions etc.)

But while AES-GCM's hard­ware ori­en­ta­tion is trou­ble­some for soft­ware im­ple­men­ta­tions, it's ob­vi­ously good news for hard­ware im­ple­men­ta­tions and some sys­tems do have hard­ware AES-GCM sup­port. Most no­tably, Intel chips have had such sup­port (which they call AES-NI) since West­mere. Where such sup­port ex­ists, it would be a shame not to use it be­cause it's con­stant time and very fast (see slide 17). So, once ChaCha20+Poly1305 is run­ning, I hope to have clients change their ci­pher suite pref­er­ences de­pend­ing on the hard­ware that they're run­ning on, so that, in cases where both client and server sup­port AES-GCM in hard­ware, it'll be used.

To wrap all this up, we need to solve a long stand­ing, browser TLS prob­lem: in order to deal with buggy HTTPS servers on the In­ter­net (of which there are many, sadly), browsers will retry failed HTTPS con­nec­tions with lower TLS ver­sion num­bers in order to try and find a ver­sion that doesn't trig­ger the prob­lem. As a last at­tempt, they'll try an SSLv3 con­nec­tion with no ex­ten­sions.

Sev­eral use­ful fea­tures get jet­ti­soned when this oc­curs but the im­por­tant one for se­cu­rity, up until now, has been that el­lip­tic curve sup­port is dis­abled in SSLv3. For servers that sup­port ECDHE but not DHE that means that a net­work at­tacker can trig­ger ver­sion down­grades and re­move for­ward se­cu­rity from a con­nec­tion. Now that AES-GCM and ChaCha20+Poly1305 are im­por­tant we have to worry about them too as these ci­pher suites are only de­fined for TLS 1.2.

Some­thing needs to be done to fix this so, with Chrome 31, Chrome will no longer down­grade to SSLv3 for Google servers. In this ex­per­i­ment, Google servers are being used as an ex­am­ple of non-buggy servers. The ex­per­i­ment hopes to show that net­works are suf­fi­ciently trans­par­ent that they'll let at least TLS 1.0 through. We know from Chrome's sta­tis­tics that con­nec­tions to Google servers do end up get­ting down­graded to SSLv3 some­times, but all sorts of ran­dom net­work events can trig­ger a down­grade. The fear is that there's some com­mon net­work el­e­ment that blocks TLS con­nec­tions by deep-packet in­spec­tion, which we'll mea­sure by break­ing them and see­ing how many bug re­ports we get.

If that works then, in Chrome 32, no fall­backs will be per­mit­ted for Google servers at all. This stage of the ex­per­i­ment tests that the net­work is trans­par­ent to TLS 1.2 by, again, break­ing any­thing that isn't and see­ing if it causes bug re­ports.

If both those ex­per­i­ments work then, great! We can de­fine a way for servers to se­curely in­di­cate that they don't need ver­sion fall­back. It would be nice to have used the rene­go­ti­a­tion ex­ten­sion for this, but I think that there are likely al­ready too many bro­ken servers that sup­port that, so an­other SCSV is prob­a­bly needed.

If we get all of the above work­ing then we're not in too bad a state with re­spect to TLS ci­pher suites. At least, once most of the world has up­graded in any case.