33C3 intromusiikki Herald: Seuraava esitelmä käsittelee TLS 1.3 käyttöönottoa ja sen esittävät Filippo Valsorda sekä Nick Sullivan, jotka he molemmat työskentelevät Cloudflarelle. Joten toivottakaamme lämpimästi tervetulleeksi Nick ja Filippo! aplodeja Filippo: Hei kaikki. Puheenaiheenamme tänään on TLS 1.3. TLS 1.3 on tietenkin uusin versio TLS:stä, joka tulee sanoista "Transport Layer Security". Se on ehkä tutuin vihreästä lukon kuvasta selaimessa, tai vanhasta nimestään: SSL, jota yritämme edeelleen tappaa. TLS on läpinäkyvä turvallisuusprotokolla, joka voi turvallisesti tunneloida mielivaltaista sovellusliikennettä. Sitä käyttävät tietenkin web-selaimet, sitä käyttävät sähköpostipalvelimet turvaamaan keskinäistä SMTP liikennettään. Sitä käyttävät Tor-solmut keskinäiseen kommunikointiinsa. Mutta se kehittyi yli 20 vuoden ajan, mutta pohjimmiltaan se koskee asiakasta ja palvelinta jotka haluavat kommunikoida turvallisesti verkon yli. Kommunikoidakseen turvallisesti verkon yli niiden täytyy luoda avainmateriaalia, sopia keskenään avainmateriaalista molemmin puolin salatakseen tulevan liikenteen. Se, miten avainmateriaalista sovitaan, hoidetaan vaiheessa, jota kutsumme "kättelyksi". Kättelyssä on mukana julkisen avaimen kryptografiaa ja dataa, jota lapioidaan asiakkaalta palvelimelle, palvelimelta asiakkaalle. Tältä kättely näyttää TLS 1.2:ssa. Asiakas aloittaa tanssit lähettämällä "Client Hello"-viestin, jossa kertoo, mitä tuettuja parametreja se voi käyttää. Palvelin vastaanottaa sen ja lähettää oman viestinsä, joka on "Server Hello", joka sanoo "Selvä! Käytetään tätä salausalgoritmien yhdistelmää, jota sanot tukevasi, ja tässä on minun avainosuuteni käytettäväksi tässä avaintenvaihtoalgoritmissa. Lisäksi, tässä on sertifikaatti, jonka on allekirjoittanut auktoriteetti, joka todistaa, että todellakin olen Cloudflare.com. Ja tässä on allekirjoitus sertifikaatista todistamaan, että tämä avainosuus on todellakin se, jota haluan sinun käyttävän avainten luomiseen." Asiakas vastaan ottaa sen ja generoi oman avainosuutensa, eli oman puolensa Diffie-Hellman avaintenvaihdosta, ja lähettää avainosuuden sekä viestin kertoakseen: "Se oli siinä. Kättely on nyt paketissa". Tätä kutsutaan "Finished" viestiksi. Palvelin vastaanottaa sen, luo oman "Finished" viestinsä ja vastaa sillä. Eli nyt voimme vihdoin lähettää sovellusdataa. Kerrataanpa vielä prosessi: Asiakas -> Palvelin, Palvelin -> Asiakas; Asiakas -> Palvelin, Palvelin -> Asiakas. Meidän täytyi tehdä 2 edestakaista matkaa asiakkaan ja palvelimen välillä ennen mitään muuta. Emme ole lähettäneet tavuakaan sovelluskerroksella ennen tätä. Tämä tietenkin matkapuhelinverkoissa tai tietyissä maailmankolkissa voi kerryttää satojen millisekuntien viiveen. Ja tämä täytyy tehdä joka kerta, kun uutta yhteyttä avataan. Joka kerta asiakkaan ja palvelimen täytyy kulkea kahdesti välinsä luodakseen avaimet ennen kuin yhteyttä voi oikeasti käyttää. TLS 1.1 ja 1.0 eivät eronneet suuresti 1.2:sta. Voisikin kysyä: miksi sitten pitää kokonainen esitys TLS 1.3:sta, joka on luultavasti vain taas yksi iteraatio samasta konseptista? No, TLS 1.3 on oikeasti iso uudelleensuunnittelu. Erityisesti kättely on uudelleen järjestetty. Ja tämän näkyvin tulos on se, että yksi kokonainen edestakainen matka on karsittu pois. Eli, tältä näyttää TLS 1.3-kättely. Kuinka 1.3 poistaa edestakaisen matkan? Miten se pystyy siihen? Se kykenee siihen ennustamalla, mitä avaintenvaihtoalgoritmia palvelin tulee käyttämään, ja lähettämällä ennakkoon avainosuuden tuota algoritmia varten palvelimelle. Eli ensimmäisessä viestissä meillä oli "Client Hello", tuetut parametrit ja avainosuus algoritmille, josta asiakas uskoo palvelimen pitävän. Palvelin vastaanottaa viestin ja jos kaikki menee hyvin, se ajattelee: "Ah! Okei! Tykkään tästä avainosuudesta. Tässä on oma avainosuuteni samaa algoritmia varten, ja tässä muut parametrit, joita meidän tulisi käyttää." Se välittömästi sekoittaa avainosuudet saadakseen jaetun yhteisen avaimen, koska nyt sillä on molemmat avainosuudet - asiakkaan ja palvelimen - ja lähettää taas sertifikaatin ja allekirjoituksen sertifikaatista, ja sitten välittömästi lähettää "Finished"-viestin, koska se ei tarvitse mitään muuta asiakkaalta. Asiakas vastaanottaa tuon, ottaa avainosuuden, luo jaetun yhteisen avaimen ja lähettää oman "Finished" viestinsä, ja on valmis lähettämään sitä sovellus- dataa, jota olikaan lähettämässä. Esimerkiksi HTTP-pyyntösi. Nyt prosessi meni näin: Asiakas -> Palvelin, Palvelin -> Asiakas. Ja olemme valmiita lähettämään sovelluskerroksen dataa. Eli, jos olit avaamassa HTTPS-yhteyttä, selaimesi ei tarvitse odottaa nelinkertaista viivettä, nelinkertaista pingiä. Sen täytyy odottaa vain kaksinkertainen, ja tämä tietysti säästää satoja millisekunteja viivettä kun avataan uusia yhteyksiä. Tämä oli onnellinen tapaus. Näin käy kun ennustus osuu oikeaan ja palvelin tykkää asiakkaan avainosuudesta. Jos palvelin ei tue avainosuutta, jonka asiakas lähetti, se lähettää kohteliaan pyynnön käyttää jotain toista algoritmiä, jota asiakas sanoi tukevansa. Tätä viestiä kutsutaan nimellä "Hello Retry Request". Siinä on eväste, joten se voi olla tilaton mutta periaatteessa se on varakeino, jolla palataan käytännössä TLS 1.2 kaltaiseen kättelyyn. Eikä se ole kovin vaikea toteuttaa, koska asiakas jatkaa uudella "Client Hello":lla, joka näyttää periaattessa täysin samalta kuin täysin tuorekin. Nyt... Tässä kohtaa olen valehdellut. TLS 1.2 ei aina ole 2 edestakaista matkaa. Suurin osa yhteyksistä, joita näemme esimerkiksi Cloudflaren reunalta ovat istunnon jatkamisia. Eli asiakas on ollut yhteydessä k.o. sivustolle aiemmin. Ja voimme käyttää tätä, voimme hyödyntää tätä ja tehdä kättelystä nopeamman. Tämä tarkoittaa, että asiakas muistaa jotain avainmateriaalista, jotta pystyy avaamaan seuraavan yhteyden vain yhdellä edestakaisella matkalla myös TLS 1.2:ssa. Eli tältä se näyttää. Tässä on normaali TLS 1.2 täysi kahden edestakaisen matkan yhteys. Ja tässä palvelin lähettää lipun uutta istuntoa varten. Istuntolippu ei ole sen kummempi kuin salattu kapseloitu blob sisältäen avainmateriaalia jonka asiakas säilyttää. Lippu on salattu ja allekirjoitettu avaimella, jonka vain palvelin tietää. Eli se on täysin läpinäkymätön asiakkaalle. Mutta asiakas säilyttää sen sekä yhteyden avainmateriaalin, jotta seuraavan kerran kun se avaa yhteyttä samalle sivustolle se lähettää "Client Hello":n ja istuntolipun. Jos palvelin tunnistaa lipun, se purkaa salauksen ja löytää sisältä avainmateriaalin. Ja nyt, vain yhden edes- takaisen matkan jälkeen, palvelimella on yhteistä avainmateriaalia asiakkaan kanssa koska asiakas säilytti sen viime kerrasta ja palvelin juuri purki sen salatusta istuntolipusta. Ok? Eli nyt palvelimella on jo käytet- tävissä yhteisiä jaettuja avaimia ja se lähettää "Finished" viestin ja asiakas vastaa "Finished" viestillä ja pyynnöllä. Eli tämä on TLS 1.2. Tätä tapahtuu jo joka päivä useimpien modernien TLS-yhteyksien kanssa. TLS 1.3-istunnon jatkaminen ei ole kovin erilainen. Siinäkin on istuntolipun käsite Istuntolipun sisällön nimi on muutettu "PSK":ksi, mutta se tulee vain sanoista "Pre-shared Key", koska sitähän se on: pelkkää avainmateriaalia, josta oli sovittu aiemmin. Ja se toimii samalla tavalla: palvelin vastaanottaa istuntolipun, purkaa salauksen ja hyppää "Finished" viestiin. Ongelma istunnon jatkamisessa on se, että jos hyökkääjällä on hallussaan istuntolippu - eli avain, jota palvelin käyttää salamaan istuntolipun, jonka sisällä avainmateriaali on - hyökkääjä voi passiivisesti, tai jopa tulevaisuudessa kaapatun yhteyden tapauksessa, purkaa istuntolipun "Client Hello":sta, löytää sieltä PSK:n ja käyttää sitä purkamaan koko yhteyden salauksen. Tämä ei ole hyvä.