Translated by Roope Salminen (ITKST56 course assignment at JYU.FI) (33C3 intromusiikki) Herald: Seuraava esitelmä käsittelee TLS 1.3 käyttöönottoa ja sen pitävät Filippo Valsorda sekä Nick Sullivan, jotka molemmat työskentelevät Cloudflarelle. Joten toivottakaamme lämpimästi tervetulleeksi Nick ja Filippo! (aplodeja) Filippo: Hei kaikki. Puheen- aiheenamme 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ä tunnetuin vihreästä lukosta selaimessa, tai vanhalta nimestään SSL, jota yritämme edelleen 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 varmenne, jonka on allekirjoittanut auktoriteetti, joka todistaa, että todellakin olen Cloudflare.com. Ja tässä on allekirjoitus varmenteesta todistamaan, että tämä avainosuus on todellakin se, jota haluan sinun käyttävän avainten luomiseen." Asiakas vastaanottaa 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ä osissa maailmaa 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 restukturoitu. 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 varmenteen ja allekirjoituksen varmenteesta, 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-pyynnön. 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:n 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ää. Istuntolippu 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 istuntolipun, se purkaa sen 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 nyt 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. Nyt... Ongelma istunnon jatkamisessa on se, että jos hyökkääjällä on hallussaan istuntolipun avain - 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 loppu- yhteyden salauksen. Tämä ei ole hyvä. Tämä tarkoittaa, että joku voi passiivisesti purkaa salauksen hallinnoimalla istuntolipun avainta. Tähän vastataan yleensä sanomalla, että Lippujen avaimet vanhenevat nopeasti. Mutta eikö olisi mukavaa, jos meidän ei tarvitsisi luottaa siihen. Ja on itse asiassa julkaisuja, jotka kertovat meille että toteutukset eivät aina tee tuota oikein. Siispä, TLS 1.3 sen sijaan mahdollistaa Diffie-Hellmanin käytön istunnon jatkamisessa. 1.2:ssa ei ollut keinoja suojautua istunto- lipun avaimen murtamisen seurauksilta. 1.3:ssa voi sen sijaan lähettää avainosuuden osana "Client Hello":ta ja palvelin lähettää avainosuuden "Server Hello":n yhteydessä, ja osapuolet suorittavat Diffie-Hellmanin. Diffie-Hellmania käytettiin jatkosuojauksen toteuttamiseen esimerkiksi sen varalta, että varmenteen yksityinen avain joutuisi vääriin käsiin 1.2:ssa, ja tässä sitä käytetään jatkosuojauksen toteuttamiseen istunnon jatkamisessa. Nyt, saatatte miettiä: "Tämä näyttää periaatteessa normaalilta 1.3 kättelyltä, mikä virka PSK:lla on ylipäätään?" Tästäpä puuttuukin jotakin. Varmennetta ei ole. Koska ei ole tarvetta autentikoida uudelleen varmenteen avulla, koska asiakas ja palvelin juttelivat aiemmin, joten asiakas tietää tarkistaneensa jo palvelimen varmenteen, ja mikäli palvelin pystyy purkamaan istuntolipun salauksen, se tarkoittaa, että palvelin on se joksi itseään väittää. Joten kaksi avainosuutta yhdistetään. Sitten yhdistetään PSK:n kanssa, jotta saadaan avain, jolla salataan loput yhteydestä. On olemassa vielä yksi uusi ominaisuus, jonka TLS 1.3 istunnon jatkaminen tuo mukanaan. Se on se seikka, että se mahdollistaa kättelyn ilman edestakaista matkaa (0-RTT). Muistutuksena, kaikki kättelyt 1.3:ssa koostuvat enim- mäkseen yhdestä edestakaisesta matkasta. TSL 1.2 istunnon jatkamiset voivat olla minimissään yhden edestakaisen matkan. TLS 1.3 istunnon jatkamiset voivat toimia ilman edestakaista matkaa. Kuinka 0-RTT kättely toimii? Ajatellaanpa. Alkuun on PSK. Pre-shared Key. Asiakas voi käyttää sitä salaamaan tämän alkudatan, jonka haluaa lähettää palvelimelle. Joten asiakas avaa yhteyden palvelimeen, johon on jo aiemmin ollut yhteydessä, ja lähettää "Client Hello":n, istuntolipun, avainosuuden Diffie-Hellmaniin ja alkudatan. Alkudata on blob sovellusdataa - se voi olla esimerkiksi HTTP-pyyntö - salattuna PSK:lla. Palvelin vastaanottaa tämän, purkaa istuntolipun, löytää PSK:n, käyttää PSK:ta purkamaan alkudatan ja jatkaa sitten normaalisti: yhdistää avainosuudet, lisää PSK:n, luo uuden avaimen lopulle yhteydelle ja jatkaa yhteyttä. Eli mitä tässä tapahtui? Voimme lähettää sovellusdataa välittömästi yhteyden avaamisen yhteydessä. Tämä tarkoittaa, että poistimme suorituskyvyn yleiskustannukset TLS:ssä. 0-RTT kättelyissä on kuitenkin kaksi vaaran paikkaa, jotka ovat teoriassa mahdoton poistaa. Yksi on se, että se kiva asia joka tuli PSK ECDHE moodin mukana, se jossa käytetään Diffie- Hellmania istunnon jatkamiseen 1.3:ssa, ei auta 0-RTT datan kanssa. Käytämme Diffie-Hellmania kun saavumme dian vihreään laatikkoon. Tietysti alkudata on salattu vain PSK:lla. Mietitäänpä taas hyökkääjää. Hyökkääjä jollain keinolla varasti istuntolippumme salausavaimet. Se voi katsoa "Client Hello":a, purkaa istuntolipun, saada PSK:n, käyttää PSK:ta purkamaan alkudatan salauksen. Se voi tehdä tämän kaapatustakin liiken- teestä, jos saa istuntolipun myöhemmin. Siispä alkudata ei ole jatkosuojattu istuntolipun avainten suhteen. Pelkkä PSK on kuitenkin hyödytön, jos käytämme Diffie-Hellmania palvelimen vastauksessa. Se on hyödyllinen ainoastaan asiakkaan ensimmäisen viestin kohdalla. Kerrataanpa. Tässä on paljon asiaa. TLS 1.2 toi jatkosuojauksen sen varalle, että varmenteen yksityinen avain joutuisi vääriin käsiin, jo kauan sitten käyttämällä ECDHE moodeja. Siis 1.2 yhteydet voivat olla aina jatko- suojattuja varmenteen murtamisen varalta. TLS 1.3 toimii samoin. Ei ole moodia, joka olisi jatkosuojaamaton varmenteen murtamisen varalta. Mutta, jos ajatellaan mitä istuntolipun avaimelle voi käydä: TLS 1.2 ei koskaan tarjoa jatkosuojausta. TLS 1.2:ssa istuntolipun avaimen murtaminen johtaa aina kykyyn passiivisesti murtaa tulevien jatkettujen istuntojen salaus. 1.3:ssa sen sijaan, jos käytämme PSK ECDHE:tä, ainoastaan alkudatan salaus voidaan purkaa käyttämällä pelkästään istuntolipun avainta. Kuten sanoin, vaaran paikkoja on kaksi. Toinen se, että 0-RTT dataa voidaan käyttää toistohyökkäyksessä. Olkoon tilanne tämä: alkudata sisältää dataa, joka on jollain tapaa autentikoitu. Se voi olla HTTP- pyyntö, joka sisältää evästeitä. Tuo HTTP-pyyntö jollain tapaa suorittaa transaktion, okei? Ehkä se on tilisiirto. Ohjeistaa palvelinta tekemään jotain. Hyökkääjä haluaa toistaa tuota tapahtumaa. Se ei tietenkään voi purkaa sen salausta - sehän on suojattu TLS:llä. Eli se ei voi nähdä evästeen sisältöä, eikä se voi muokata sitä, koska se on TLS-suojattu. Mutta se voi kaapata salatun viestin ja lähettää sen uudelleen palvelimelle. Jos palvelimia on yksi, tähän on helppo ratkaisu. Pidä kirjaa nähdyistä viesteistä ja ajattele kutakuinkin näin: "Ei. Tämä näyttää täsmälleen samalta kuin mitä sain aiemmin." Mutta jos esimerkiksi, kuten Cloudflare, pyörität useita data- keskuksia ympäri maailmaa, et voi pitää yhdenmukaisia tiloja jatkuvasti, reaali- ajassa, kaikkien koneiden välillä. Olisi eri koneita, jotka tämän viestin saatuaan ajattelisivat näin: "Toki, minulla on istuntolipun avain, dekryptaan PSK:n, käytän PSK:ta, dekryptaan alkudatan, löydän sieltä jotain ja suoritan sen mitä se käskee minun tehdä." Tämä ei tietenkään ole suotavaa. Yksi TLS.n tarjoama vastatoimi on, että asiakas lähettää samassa paketissa arvon, joka kertoo millisekunteina, kuinka kauan sitten sain haltuuni istuntolipun. Palvelin katsoo sitä arvoa, ja jos se ei täsmää sen omaan näkemykseen tästä tiedosta, se hylkää viestin. Tämä tarkoittaa, että jos hyökkääjä kaappaa viestin ja 10 s myöhemmin yrittää toistohyökkäystä, ajat eivät täsmää ja palvelin hylkää viestin. Tämä ei kuitenkaan ole täysi ratkaisu, sillä tarpeeksi nopea hyökkääjä voi silti tehdä toistohyökkäyksiä. Eli, palvelin voi ainoastaan joko hyväksyä 0-RTT datan tai hylätä sen. Se ei voi vain ottaa jotain osaa siitä tai kurkistaa siihen ja päättää sitten, koska "Server Hello"-viesti kertoo (asiakkaalle) hyväksyttiinkö vai hylättiinkö se. Ja asiakas jatkaa alkudatan lähettämistä kunnes se saa "Server Hello"-viestin. Tässä on kilpailu. Joten palvelimen täytyy sokkona päättää "Otanko 0-RTT dataa vastaan vai hylkäänkö sen kaiken?" Jos se ottaa sen, ja sitten huomaa sen olevan jotain mitä se ei voi prosessoida koska "Herran- jestas, täällä on HTTP POST, joka käskee siirtämään rahaa. En voi tehdä tätä, jos en tiedä ettei tämä ole toistohyökkäys." Palvelimen täytyy saada jonkinlainen vahvistus. Hyvä uutinen on se, että jos palvelin odottaa "Finished" viestiä... Palvelin lähettää "Server Hello":n, "Finished":n ja odottaa asiakkaan vastaavaa. Kun asiakkaan oma saapuu, se tarkoittaa, ettei kyseessä ollut toistohyökkäys, sillä tuo "Finished" viesti viimeistelee koko kättelyn yhdessä tietyn satunnaisarvon kanssa, jonka palvelin lähetti. Kyseessä ei siis voi olla toistohyökkäys. Eli nämä ovat palvelimen vaihtoehdot: se voi hyväksyä alkudatan ja jos se on jotain mikä ei ole idempotenttia, jotain mikä on vaarallista jos se toistetaan, se voi yksinkertaisesti odottaa vahvistusta. Mutta se tarkoittaa, että se on laitettava välimuistiin, ja tässä on riski, mikäli hyökkääjä lähettää HTTP POST:n valtavalla rungolla tarkoituksenaan täyttää muisti. Tajusimme voivamme auttaa tässä, jos kirjoitamme istuntolippuihin, mikä on maksimimäärä alkudataa, jonka asiakas voi lähettää. Jos huomaamme jonkun lähettävän enemmän, kyseessä on hyökkääjä ja katkaisemme yhteyden, tyhjennämme välimuistin vapauttaaksemme muistia. Mutta. Joka tapauksessa. Vastatoimista huolimatta, ellemme pysty pitämään yhtenäistä maailmanlaajuista tilaa palvelimien välillä, meidän täytyy kertoa sovellukselle toistohyökkäyksen mahdol- lisuudesta. Spesifikaatio tietää tämän. TLS 1.3 spesifikaatio YKSISELITTEISESTI toteaa protokollien EI tule käyttää 0-RTT:tä ilman profiilia, joka määrittelee sen käytön. Eli tarkoittaa "tietämättä mitä ne ovat tekemässä". Tämä tarkoittaa, että TLS-pinon APIen täytyy tehdä oletuksena 1-RTT, johon toistohyökkäykset eivät toimi, ja sitten antaa palvelimen kutsua joitakin API:a hylätäkseen tai odottaakseen vahvistusta, ja antaa asiakkaan päättää, mitä tähän vaaralliseen toistohyökkäysalttiiseen dataan tulee. Tämä riippuu protokollasta, mutta entäpä lempiprotokollamme? Entäpä HTTP? HTTP:n pitäisi olla helppo. HTTP-spesifikaatio, käykää vaikka lukemassa, sanoo: "GET-pyynnöt ovat idempotentteja, niiden ei tule muuttaa mitään palveli- mella". Selvä! Sallimme nyt ainoastaan GET-pyynnöt alkudatassa, koska niitä ei voi hyödyntää toistohyökkäyksissä! Jes! Ei. Internetissä on takuuvarmasti palvelin, jossa on jotain sen kaltaista kuin “send-money.php?to=filippo&amount=this” ja se on GET-pyyntö. Ja jos hyökkääjä kaappaa tämän, mikä on alkudataa, ja sitten käyttää tätä toistohyök- käyksessä toista palvelinta vastaan, se suoritetaan kahdesti. Ja se ei käy päinsä. Mitä siis voidaan tehdä? Teemme kompromisseja! Jos tunntet sovelluksesi, voit tehdä hyvin spesifejä kompromisseja. Esimerkiksi Google on ajanut QUIC:iä 0-RTT:llä hyvinkin pitkään. Uskoakseni 3 vuotta? Se tarkoittaa, että he tuntevat sovelluksensa oikein hyvin. Ja he tietävät, ettei heillä ole "send-money.php" päätepisteitä. Mutta jos olet kuin Cloudflare, joka hallinnnoi suurta määrää sovelluksia, et voi tehdä noin laajoja olettamuksia, ja täytyy sen sijaan yrittää löytää kultainen keskitie. Me saattaisimme esimerkiksi päättää sallia GET-pyynnöt ainoastaan juurihakemistoon. Eli "GET /", mikä saattaisi tuoda eniten hyötyä, sillä ehkä suurin osa yhteyksistä alkaa noin, ja se on vähiten todennäköinen aiheuttamaan hankaluuksia. Mietimme edelleen kuinka sovellamme tätä sovelluksiin. Eli jos tiedossasi on sovellus, joka tulisi kärsimään jostain noin yksinkertaisesta, lähetä meille sähköpostia. Mutta itse asiassa, jos sinulla on noin haavoittuvainen sovellus, minulla on huonoja uutisia. Thai Duong et. al. osoittivat, että tämän päivän selaimet, ilman TLS 1.3:a tai muutakaan, toistavat HTTP-pyyntöjä verkkovirheiden sattuessa. Ja ne toistavat ne hiljaisesti. Eli lopputulema ei välttämättä ole huonompi kuin nykytila. Selvä. Näen, että kaikki alkavat olla levottomia ja ajattelevat "Kryptografit ovat taas asialla! He tekevät tarvitsemastamme turvallisuus- protokollasta tarpeettoman monimutkaisen turvatakseen työpaikkansa seuraavaksi 15 vuodeksi!" Eikö? Ei. Ei. Voin itseasiassa taata, että yksi suurista muutoksista, mielestäni suurempi kuin edestakaiset matkat 1.3:ssa, on, että kaikkea punnitaan saadun hyödyn ja sen aiheuttaman monimutkaisuuden kannalta. Ja vaikka 0-RTT pääsi jatkoon valtaosa ei päässyt. Nick: Selvä. Kiitos Filippo. Toimiiko mikrofonini? Kuuletteko minut? Selvä. TLS 1.3:n ollessa iteraatio TLS:stä mekin katsoimme taaksepäin, tai, "me", jotka olemme ihmiset jotka tutkivat TLS:ää, katsoimme taaksepäin ja kertasimme olemassa olevia TLS 1.2:n omi- naisuuksia, jotka vaikuttivat järkeviltä aikanaan ja päätimme, oliko kompleksisuus tai vaara, jonka nämä TLS:n ominaisuudet tai protokollat tai primitiivit toivat mukanaan järkeviä säilyttää. Ja yksi iso, joka sattui prosessin alussa on "staattinen RSA" moodi. Näin TLS on toiminut SSL:n ajoista lähtien. Sen sijaan, että käytettäisiin Diffie- Hellmania yhteisen avaimen luontiin, asiakas luo oman jaetun avaimensa, ja salaa sen palvelimen varmenteen julkisella avaimella, joka on RSA-avain, ja lähettää sen sitten sellaisenaan palvelimelle. Ja palvelin sitten käyttää omaa yksityistä avaintaan purkamaan salauksen ja löytää yhteisen avaimen. Eli asiakas luo kaiken avainmateriaalin tässä tapauksessa. Yksi asia on melko selvä tässä on, että jos varmenteen yksityinen avain murretaan, vaikka vuosiakin myöhemmin, joku jolla on tallenteet tapahtumista voi mennä taaksepäin ja purkaa tämän avain- materiaalin ja siten koko keskustelun. Tämä poistettiin ihan TLS 1.3-prosessin alkuvaiheessa, noin kaksi vuotta sitten. Joten suureksi yllätykseksemme, ja kaikkien, jotka kuuluvat TLS:ää koskevaan sähköpostitus- listaan, ihan vasta äskettäin, standardointiprosessin loppuvaiheessa, kun TLS 1.3 oli melkein valmis, tämä sähköposti ilmestyi. Ja tämä on Andrew Kennedyltä, joka työskentelee BITS:lle, mikä tarkoittaa pääpiirteittäin, että hän työskentelee pankeille. Hän sanoo "RSA-avaintenvaihdon tuen lopettaminen TLS 1.3:ssa aiheuttaa suuria ongelmia finanssilaitoksille, joista melkein kaikki käyttävät TLS:ää sisäisesti ja joilla on suuria, turvallisuuskriittisiä investoin- teja ulkopuoliseen TLS-dekryptaamiseen. "Ulkopuoliseen (3. osapuolen) TLS-dekryp- taamiseen" hmm.. (naurua - aplodeja) Se todella kuulostaa kriittiseltä... kriittiseltä jollekin, eikö? (naurua - aplodeja) Eli... (naurua) (aplodeja) Yksi valonpilkahduksista oli Kenny Patersonin vastaus tähän, joka kuului näin: "Minun näkemykseni pyyntöäsi koskien: ei. Perustelu: Yritämme rakentaa TURVALLISEM- PAA internetiä." Korostus on oma lisäykseni, mutta hän varmasti tarkoitti sitä. (aplodeja) Tämän jälkeen pankkiväki saapui IETF:ään ja näytti tämän dian kuvaillakseen, kuinka vaikeaa heidän järjestelmänsä debuggaaminen on. Tämä on yksinkertaista.. Ilmeisesti pankkiympäristössä. Nuo ovat eri kytkimiä, reitittimiä, väliohjelmistoja, web-sovelluksia ja kaikki keskustelevat TLS:llä. Tämän keskustelun jälkeen päädyimme kompromissiin. Protokollan vaarantamisen sijaan Matthew Green opetti heille, kuinka käyttää Diffie- Hellmania väärin. Lopulta he kykenivät siihen, mitä halusivat ilman, että me - tai kukaan muu akateemisessa yhteisössä tai TLS-yhteisössä - palautti TLS:ään tämän turvattoman osan. Jos haluat lukea tämän, se kertoo kuinka tähän pystytään. Joka tapauksessa - emme laittaneet sitä takaisin. Kiteytettynä, älkää tehkö näin! (aplodeja) Eli tapoimme staattisen RSA:n, ja mitä muuta tapoimme? No, kun katsotaan taaksepäin hyötyihin ja haittoihin, TLS 1.2 käyttää tiettyjä primitiivejä, jotka vain eivät ole kestäneet ajan hammasta. RC4 jonosalain. Poissa! (aplodeja) 3DES (Triple DES) lohkosalain. Poissa! (aplodeja) MD5, SHA1... molemmat poissa. Yo! (jatkuvia aplodeja) On vielä rakennelmia, jotka... peruslohkosalainrakennelmia, jotka ovat poissa: AES-CBC. Poissa. RSA-PKCS1-1.5, tämä on tiedetty ongelmalliseksi jo vuodesta 1998, myöskin poissa! Myös muita ominaisuuksia, kuten kompressio ja uudellenneuvottelu, on poistettu. Jälkimmäisen korvasi hyvin kevyt "avaimen päivitys"-mekanismi. Siis TLS 1.3:ssa mikään näistä ei läpäissyt hyöty vs. kompleksisuus -testiä. Ja monet näistä haavoittuvuksista, joita saatatte tunnistaa, ovat mahdottomia TLS 1.3:ssa. (aplodeja) TLS 1.3:n filosofia monessa kohtaa on yksinkertaistaa ja lujittaa mahdollisimman paljon. Tästä on useita pieniä esimerkkitapauksia. Osa tämän julkaisun kirjoittajista saattaa löytyä yleisöstä. Oli tapa käytää lohkosalaimia itse tallennekerroksella tavalla, joka ei ollut niin kestävä kuin se voisi olla. Se on korvattu paljon yksinkertaisemmalla tavalla. TLS 1.2:ssa oli tällainen erikoinen "Catch 22", jossa salaimen neuvottelua suojaa "Finished"-viesti, joka on viestin autentikointikoodi, mutta tuon koodin algoritmi päätettiin salainneuvottelussa, joten siinä oli tällainen takaisinsyöttö- efekti. Hyökkäykset kuten FREAK, LogJam ja CurveSwap onnistuivat hyödyntämään näitä alentaakseen yhteyksien turvallisuuksia. Tätä tapahtui ihan käytännössä. Syy on, että näitä salausalgoritmien joukkoja kättelyssä ei ole digitaalisesti allekirjoitettu yksityisellä vaimella. Tämä muutettiin TLS 1.3:ssa. Kaikki allekirjoituksen yläpuolella oleva on allekirjoitettu. Tämä on hienoa! Mitä muuta muutimme? Tai, mitä muuta TLS 1.3 muutti verrattuna TLS 1.2:een? Vähemmän, mutta parempia valintoja. Kryptografiassa paremmat valinnat tarkoittavat aina vähemmän valintoja. Nyt on tietyt ehdokkaat käyrille ja äärellisille kunnille, joita voi käyttää. Ei mielivaltaisia palvelimen keksimiä DH-ryhmiä, ei mielivaltaisia käyriä. Ja tämä sopivien parametrien listan karsiminen, johtaa siihen että 1-RTT toimii niin usein. Kuten Filippo sanoi, asiakkaan täytyy arvata mitä avaimenmuodostus- metodeja palvelin tukee, ja lähettää sopiva avainosuus. Jos on olemassa lyhyt lista pelkästään turvallisia vaihtoehtoja, tätä tapahtuu useammin. Eli, kun konfiguroit TLS-palvelintasi, se ei enää näytä monimutkaiselta pikaruokalistalta, vaan enemmänkin häämenulta. Ota yksi jokaisesta kategoriasta ja lopputulos on herkullisempikin. Voit tutkia tätä Wiresharkissakin, sekin on yksinkertaista. Salausalgoritmit, laajennukset, käyrät ja voit jatkaa siitä. Filippo: TLS 1.3 korjasi myös sen, mikä mielestäni oli yksi suurimpia suunnitteluvirheitä TLS 1.2:ssa. Puhuimme siitä, miten jatkosuojaus toimii istuntojen jatkamisessa 1.2:ssa ja 1.3:ssa. Mutta TLS 1.2 on vieläkin ongelmallisempi. TLS 1.2 käärii istuntolippujen sisään vanhan yhteyden varsinaisen pääsalaisuuden. Eli se ottaa varsinaiset alkuperäisen yhteyden liikenteen salaamiseen käytetyt avaimet, salaa ne istuntotlipun avaimella, ja lähettää ne asiakkaalle, jotta se voi lähettää ne takaisin ensi kerralla. Puhuimme riskistä, että hyökkääjä saa istuntolipun avaimet haltuunsa, dekryptaa instuntoliput ja murtaa jatkosuojauksen ja dekryptaa jatketut istunnot. TLS 1.2:ssa asiat ovat vielä huonommin. Jos hyökkääjä dekryptaa istuntoliput, se voi takaperoisesti dekryptata koko alkuperäisen jatkamattoman istunnon. Ja tämä on täysin tarpeetonta. Meillä on tiivistefunktioita, yksisuun- taisia funktioita, joihin laitetaan syöte ja saadaan jotain, josta ei päästä takaisin alkuperäiseen. Näin 1.3 tekee. 1.3. johtaa uusia, tuoreita avaimia seuraavaa istuntoa varten ja käärii ne istuntolipun sisään, jotta niistä saadaan PSK. Eli vaikka dekryptaisit 1.3 istuntolipun, voit yrittää murtaa seuraavaa yhteyttä ja olemme nähneet, että saatat pystyä dekryptaamaan ainoastaan alkudatan, tai koko yhteyden, käytetystä moodista riippuen. Mutta et mitenkään voi dekryptata alkuperäistä jatkamattoman istunnon yhteyttä. Tämä olisi itsessään riitävän huono asia, mutta 1.2 tekee toisen päätöksen, joka ihmetytti minua. Koko "käytetään pää- salaisuutta" saataa johtua siitä, että istuntoliput olivat pelkkä laajennus 1.2:ssa, mitä ne eivät ole 1.3:ssa. Mutta 1.2 lähettää "New Session Ticket"-viestin alkuperäisen kättelyn alussa - salaamattomana! Tarkoitan siis, salattuna istuntolipun avaimilla, mutta ei nykyisen istunnon avaimilla. Eli mikä tahansa palvelin, joka tukee istuntolippuja, tulee kaikkien yhteyksien alussa - vaikka istunnon jatkamista ei ikinä tapahtuisi - lähettämään istuntolipun, joka ei ole muuta kuin sen yhteyden hetkelliset (katoavat) avaimet käärittynä istuntolipun avaimilla. Nyt, jos olet Maailmanlaajuinen pahantekijä, joka haluaa suorittaa joukkovalvontaa ja haluaisit dekryptata jälkikäteen kaikki yhteydet, ja jotenkin saisit käsiisi istuntolippujen avaimet, se mitä löytäisit kaikkien TLS 1.2-yhteyksien alusta, on istuntoavaimet salattuna istuntolipun avaimilla. 1.3 ratkaisee tämän ja 1.3:ssa tällaiset hyökkäykset ovat täysin mahdottomia. Ainoa asia, jonka voisit passivisesti, siis jälkikäteen, dekryptata on alkudata. Et mitenkään voisi dekryptata jatkamattomia yhteyksiä ja mitään mikä tulee 0-RTT:n jälkeen. Nick: Eli se on turvallisempi. Lyhyesti sanottuna. Filippo: Toivon mukaan! Nick: ...toivottavasti. Ja mistä tiedämme sen olevan turvallisempi? Nämä turvallisuusparametrit ja turvallisuus- vaatimukset koskien TLS:ää on formalisoitu ja, toisin kuin aiemmissa TLS-versioissa, formalisointia harjoittavat akateemikot otettiin mukaan aiemmin. Useat julkaisut ovat analysoineet tilakonetta ja TLS 1.3:n eri moodeja, ja nämä ovat auttaneet paljon protokollan kehityksessä. Kuka siis oikeastaan kehittää TLS 1.3:a? No, kyseessä on järjestö nimeltä IETF, joka tulee sanoista Internet Engineering Taskforce. Se on ryhmä vapaaehtoisia, jotka tapaavat kolmesti vuodessa, joilla on postituslistoja ja he väittelevät loputtomasti näistä protokollista. He määrittelevät internetissä käytettävät protokollat. Ja alunperin, ensimmäinen asia mitä tästä näin - tässä on twiittini syyskuulta 2013 - oli toivomuslista koskien TLS 1.3:a. Ja sen jälkeen IETF julkaisi ensimmäisen version... Dokumentit, jotka määrittelevät proto- kollia tunnetaan nimellä RFC, ja ennen kuin jostakin tulee RFC, siitä käy- tetään nimeä "Internet Draft". Eli aloitetaan Internet Draft 0:sta, ja sitä iteroidaan, kunnes lopulta se joko hylätään tai hyväksytään RFC:ksi. Ensim- mäinen oli siis melkein 3 vuotta sitten huhtikuussa 2014, ja nykyinen luonnos (18), jonka ajatellaan olevan melkein valmis, on vaiheessa jota kutsutaan "Last Call":ksi IETF:ssä, julkaistiin vastikään lokakuussa. Tietoturvallisuusympäristössä tällä aikavälillä on nähty todella monia erilaisia hyökkäyksiä TLS:ää vastaan. Esim: Triple Handshake, POODLE, FREAK, LogJam, DROWN (josta oli esitys aiemmin tänään), Lucky Microseconds, SLOTH. Kaikki nämä eri akronyymit - joista ehkä olette tai ette ole kuullut - ovat tapahtuneet kehitystyön aikana. Eli TLS 1.3 on kehittyvä dokumentti, ja toivottavasti siitä tulee lyhyt. Tarkoitan siis, että TLS 1.2 oli 79 sivua. Se on vähän vaikeaselkoinen, mutta lukekaa toki jos kiinnostaa. TLS 1.3 sen sijaan, jos lopusta karsii ylimääräistä tavaraa pois, tulee aika lähelle. Ja se on helppolukuisempi. Se on paljon tarkempi, vaikka sieltä löytyykin kiinnostavia ominaisuuksia kuten 0-RTT istunnon jatka- minen. Kuinka se käytännössä kirjoitetaan? Vastaus on... Github! Ja postituslista! Eli, jos haluat lähettää pull pyynnön tähän TLS-työryhmään, sieltä se löytyy. Tällä tavoin luonnos oikeasti muotoutuu. Ja kannattanee lähettää viesti postituslistaan, jossa kuvailet muutoksiasi, jos haluat. Ehdottaisin, jos joku haluaa osallistua - nyt on aika myöhäistä - onhan se "Last Call"-vaiheessa, mutta postituslista on vielä avoinna. Olen työstänyt tätä useiden muiden kanssa, Filippo mukaan lukien. Olimme osallisina luonnoksessa, työskennelleet yli vuoden tämän parissa. Voitte käydä katsomassa Githubista ongelmat ja näette, kuinka paljon työtä se on vaatinut. Luonnos on muuttunut vuosien ja kuukausien varrella. Esim. luonnos 9:ssä oli tämä monimutkainen puumalli kierrosavaimen laskennalle, tässä näette "htk"... kaikki nämä eri asiat liittyivät TLS-kättelyn eri avaimiin. Tämän inspiraation lähteenä oli QUIC, Googlen protokolla, jonka Filippo mainitsi aiemmin, sekä julkaisu nimeltä "OPTLS". Ja siinä oli useita eri moodeja: semistaattinen Diffie-Hellman ja tämä puumallinen avaintenlaskenta. Ajan mittaan tätä pelkistettiin tästä monimutkaisesta kaaviosta siihen, mitä nyt käytämme TLS 1.3:ssa. Joka on hyvin yksinkertainen avaimenjohtamisalgoritmi. Vaati paljon työtä päästä jostain suuresta johonkin näin pieneen. Mutta se onnistui! Muita TLS 1.3:n kanssa sattuneita, kryptografisesti vähemmän merkittäviä asioita, on nimeäminen! Jos joku on seurannut kehitystä, TLS 1.3 ei välttämättä ole yksimielinen valinta tämän protokollan nimeksi. Kuten Filippo mainitsi, 1.0, 1.1, 1.2 ovat melko pieniä iteraatioita jopa SSLv3:een verrattuna, kun taas TLS 1.3 on aika iso muutos. Siispä nimelle on paljon vaihtoehtoja! Otetaanpa äänestys kättä nostamalla. Kenen mielestä nimen pitäisi olla 1.3? (nauraa) Kiitos Filippo! (Filippo nauraa) Jep, eli aika suuri osa. Entäpä TLS 2? Ketään? Oho. Tämä näyttää itse asiassa enemmältä kuin... Filippo: Muistakaa että SSLv2 on juttu! Ja se on kamala juttu! Nick: Ette halua sekoittaa sitä meihin! No entä sitten TLS 4? Edelleen merkittävä osa ihmisiä... Entäs TLS 2017? Noniin... Selvä. TLS 7 ketään? Okei... Filippo: TLS Millenium 2019 X? Kyllä! Myyty! Nick: TLS Vista? (naurua) - (Nick ja Filippo nauravat) (aplodeja) Nick: Paljon vaihtoehtoja! Mutta ihan vain muistutuksena, muu maailma ei oikeastaan käytä nimeä TLS. Tässä on Google trends, kiinnostus aikajanalla, kun vertaillaan "SSL vs. TLS". SSL on nimi, jota suuri osa maailmasta käyttää. SSL:n korkein versio on versio 3, ja siinä on syy miksi ihmiset ajattelivat, että "TLS 4" on hyvä ajatus. Koska: "Ihmiset ovat hämillään: 3 on enemmän kuin 1.2 jne. jne." Tämä äänestys ei ollut ainoa. Tässä on epävirallisia Twitter-äänestyksiä. "Mmm, pekonia!" oli hyvä. 52 % Ryan Hurstin äänestykessä. (naurua) Versionumerot TLS:ssä ovat inhottava aihe. Esim. olemassa olevat versiot TLS:stä - jos katsotaan verkon yli kulkevaa tietoa, ne eivät täsmää. Eli SSL 3 on 3.0, mikä täsmää. Mutta TLS 1 on 3.1, 3.2... TLS 1.2 on 3.3 ja alun perin uskoakseni TLS 1.3:n luonnokseen 16 asti se oli 3.4 Eli ikäänkuin pikkupäivitys TLS 1.2:een, hyvin hämmentävää. Internetmittausten jälkeen pääteltiin että moni palvelin, jos lähetät "Client Hello":n arvolla "3.4", katkaisee yhteyden. Tämä on oikeasti todella huono juttu, se estää selaimia alentamasta yhteyttä turvallisesti. Mitä palvelimen kuuluisi tehdä, jos se näkee version joka on korkeampi kuin 3.3, on vain vastata "3.3" sanoakseen: "Tämän parempaan en pysty". Mutta kävi ilmi, että moni näistä vain hajoaa. Joten 3.3 on nyt "Client Hello":ssa ja 3.4 neuvotellaan aliprotokollana. Eli tämä on sotkuista. Eikö? Mutta punnitsemme hyötyjä moni- mutkaisuutta vastaan, ja tämä on niitä missä palvelimien toimivuus painaa enemmän kuin lisääntynyt monimutkaisuus, jonka tuo uuden asian lisääminen. Ja tämän estämiseksi tulevaisuudessa David Benjamin ehdotti jotain nimeltä GREASE, missä jokaiseen TLS-neuvottelun osaan tulee, asiakkaana, lisätä jotain satunnaista tavaraa, jotta palvelimet tottuvat näkemään asioita, jotka eivät ole versioita, joihin ne ovat tottuneet. Eli, 0x8a8a. Se on GREASE-d! Filippo: Se on ihan todellinen asia! Se on todellinen hyvin hyödyllinen asia! Nick: Tämä tulee olemaan hyvin hyödyllinen, tulevaisuutta ajatellen, estämään tällaisia asioita tapahtumasta. Mutta on ikävää, että sen täytyi tapahtua. Aikamme on käymässä vähiin, mutta me halusimme todella päästä mukaan ja sotkemaan kätemme. Ja yksi asia mitä IETF rakastaa, kun kehittelee näitä standardeja on koodin ajaminen. Joten aloitimme IETF 95 Hackathonilla, joka pidettiin huhtikuussa ja onnistuimme lopulta saamaan Firefoxin lataamaan Cloudflaren isännöimän palvelimen TLS 1.3:lla. Tämä oli suuri saavutus silloin. Käytimme NSS:ää, joka on Firefoxin turvallisuuskirjasto ja "Mint":iä, joka oli uusi tyhjästä rakennettu versio TLS 1.3:sta Go-kielellä. Ja lopputulema oli, että se toimi! Mutta tämä oli ainoastaan konseptitodistus (PoC). Filippo: Rakentaaksemme jotain tuotanto- valmiimpaa, katsoimme TLS-kirjastoa, jonka muokkaaminen tuntui meistä helpoimmalta. Yllätyksettömästi se ei ollut OpenSSL. Joten päätimme rakentaa 1.3:n Go:n crypto/tls-kirjaston päälle, joka löytyy Go:n standardikirjastosta. Lopputulos on "tls-tris", ja se on suora korvaaja crypto/tls:lle ja se tulee tämän varoituksen saattelemana, joka sanoo: "Kaiken hyvän ja oikeudenmukaisuuden nimessä, älä käytä tätä!". Varoitus koski alunperin kaikkea, mutta nyt se ei enää niinkään koske tietoturvaa, auditoitutimme tämän, mutta se koskee edelleen vakautta. Työstämme tämän saamista ylävirtaan, mikä tulee vakiinnuttamaan API:n. Ja voitte seurata ylävirtaprosessia, Googlen väki oli ystävällinen ja avasi meille oman haaran kehitystyötä varten, ja se ei varmasti tule osumaan seuraavaan Go:n julkaisuun, Go 1.8, mutta odotamme innolla, että saamme tämän ylävirtaan. Joka tapauksessa, vaikka käyttäisit Go:ta, käyttöönotto on vaikeaa. Ensimmäisen kerran kun otimme Tris:n käyttöön, luonnoksen numero oli 13. Ja tukeakseen selaimia tästä eteenpäin, meidän täytyi tukea useita luonnosversioita saman aikaisesti käyttämällä joskus erikoisia yksityiskohtia. Ja joskus meidän täytyi tukea asioita, jotka eivät todellakaan olleet edes luonnoksia, koska selaimet alkoivat... hajaantua eri suuntiin. No, joka tapauksessa meillä oli testimatriisi, joka ajoi kaikki meidän commit:imme kaikkia asiakaskirjastojen versioita vastaan, ja tämä varmisti. että olemme aina yhteensopivia selainten kanssa. Ja nykyään asiakkaat ovat itse asiassa paljon vakaampia, ja todellakin, saatat jopa jo tietämättäsi käyttää sitä. Esim. Chrome Beta, beta kanavalla se on päällä noin 50 % instansseista kokeiluna Googlen puolelta. Ja tältä meidän kuvaajamme näyttivät julkaisun aikaan, kun Firefox Nightly laittoi sen oletuksena päälle ja kun Chrome Canary laittoi sen oletuksena päälle. Nykyään meno on vakaata: noin 700 pyyntöä sekunnissa kulkee TLS 1.3:a käyttäen. Ja omalla puolellamme laitoimme sen päälle miljoonille Cloudflaren isännöimille sivustoille. Ja, kuten sanottua, spesifikaatio on muuttuva dokumentti ja se on kaikille avoin. Sen voi nähdä Githubissa. Tris implementaatio on siellä myös, vaikkakin siinä on tämä pelottava varoitus, ja tässä blogissa tulemme luultavasti julkaisemaan kaiken jatko- tutkimuksen ja tulokset. Kiitos paljon ja jos teillä on kysymyksiä, astukaa esiin, uskon että meillä on muutama minuutti. (aplodeja) Herald: Kiitos, meillä on reilusti aikaa kysymyksille. Ensimmäinen kysymys tulee internetistä. Signal Angel: Ensimmäisessä kysymyksessä ihmiset kysyvät onko viisasta, että päätös 0-RTT:n suhteen menee sovellukselle, eli se jätetään sovelluksen kehittäjille? Filippo: (nauraa) (aplodeja) Filippo: Hyvä kysymys. Kuten sanoimme, tämä tosiaan rikkoo abstraktion. Eli se EI ole oletusarvoisesti rikki. Jos ainoastaan päivität Go:n ja saat käyttöösi TLS 1.3:n, et tule kohtaamaan yhtään 0-RTT:tä, koska tosiaan se vaatisi yhteistyötä sovellukselta. Eli mikäli sovellus ei tiedä mitä tekee sen kanssa, se ei yksinkertaisesti voi käyttää sitä, mutta saa kaikki turvallisuushyödyt sekä 1-RTT- kättelyn hyödyt joka tapauksessa. Herald: Selvä, seuraava kysymys tulee mikrofonista yksi. Kysyjä: Protokollan ensimmäisten testien yhteydessä, oletteko saaneet konkreettisia arvoja sille, miltä nuo suorituskyvyn parannukset näyttävät? (Filippo huokaisee) Nick: Yhdeltä edestakaiselta matkalta! (nauraa) Riippuu siitä paljonko 1-RTT on. Filippo: Nimenomaan. Yksi edestakainen matka on... en pysty sanomaan lukua koska tietysti, jos asut San Franciscossa, jossa on nopea kuituyhteys, se on mitä? Ehkä 3 millisekuntia? 6...? Jos taas asut vaikka jossain maassa, missä EDGE on ainoa käytettävissä oleva yhteys, se on ehkä sekunti. Meillä taitaa olla keskiarvo, joka on noin... 100 ja 200 millisekunnin välillä, mutta emme ole virallisesti mitanneet näitä lukuja. Herald: Ok, seuraava kysymys tulee mikrofonista 3. Kysyjä: Yksi huomautus, jonka haluan sanoa on, että yksi parannus joka saavutettiin TLS 1.3:ssa on että asiakas- varmenteisiin lisättiin salaus. Joten asiakasvarmenteet lähetetään salattuina, mikä on tärkeää, jos ajattelee asiakasta, joka liikkuu sekä joukkovalvovaa elintä, joka voisi jäljittää asiakkaita tällä. Ja toinen huomio/kysymys, joka saattaisi... Herald: Kysymykset päättyvät kysymys- merkkiin. Joten yritäthän pitää lyhyenä? Kysyjä: Kyllä... Tämä saattaa olla tyhmä kysymys... Vakio Diffie-Hellman-ryhmät... eivätkö ne olleet ongelma LogJam- hyökkäyksessä, joten... auttaako tämä LogJam-hyökkäyksiä vastaan? Nick: Viittaatko siihen pankeille suunnattuun ehdotukseen? Kysyjä: Ei ei, yleisesti siihen, että voidaan laskea ennakkoon... Nick: Aivan, kyllä, eli LogJamin kohdalla oli ongelma, missä oli DH-ryhmä, joka oli oletuksena käytössä monella eri palvelimella. Apachen käyttämä, joka oli 1024 (bittiä). TLS 1.3:ssa tämä rajoitettiin ennalta laskettuun DH-ryhmään, joka on yli 2000 bittiä pienimmilläänkin, ja valtavallakin laskentateholla varustettuna, jos on 2000 bitin DH ryhmä, ei ole käytännössä mahdollista tehdä esilasken- taa minkäänlaista hyökkäystä varten. Mutta kyllä, tuo on hyvä pointti. Filippo: ...ja koska ne ovat kiinteitä, ei ole keinoa pakottaa protokollaa käyttämään mitään muuta, joka ei olisi niin vahva. Kysyjä: Selvä, kiitos! Herald: Seuraava kysymys mikrofonista 4. Kysyjä: Kiitos esityksestä! Tiivistelmässä mainitsitte, että eräs toinen lopetettava ominaisuus oli SNI, yhdessä 0-RTT:n kanssa, mutta on edelleen tapoja implementoida se. Voitteko selventää? Filippo: Pidimme siis tämän esitelmän kahdesti sisäisesti, ja tämä kysymys esitettiin molemmilla kerroilla. Joten... (nauraa) Eli, SNI on pieni parametri, jonka asiakas lähettää palvelimelle kertoakseen, mille sivustolle se yrittää yhdistää. Esim. Cloudflarella on useita sivustoja koneidemme takana, joten sinun täytyy kertoa meille "Haluan siis oikeasti yhdistää "blog.filippo.io":n. Tämä on yksityisyyden kannalta ongelmallista, koska joku voi pelkästään verkon yli kulkevista tavuista nähdä, mihin nimenomaiseen sivuun yhdistät. Epäonninen seikka on se, että tässä on sama onglema kuin alkudatan jatkosuojauksessa. SNI lähetetään "Client Hello":ssa, ja tässä kohtaa ei ole vielä neuvoteltu yhtään avainta, joten ei ole mitään millä sen voisi salata. Mutta jos ei lähetä SNI:tä ensimmäisessä viestissä, palvelin ei tiedä minkä sertifikaatin se lähettää, joten se ei voi lähettää allekirjoitusta ensimäisessä viestissä, joten ei ole avaimia. Eli täytyisi tehdä 2-RTT, ja nyt olisimme taas samassa pisteessä kuin TLS 1.2. Joten, valitettavasti, se ei toimi 1-RTT kättelyissä. Nick: HTTP2:n spesifikaatiossa on kuitenkin ehdotuksia, jotka mahdollistaisivat multi- pleksaamisen. Tämä on vielä työn alla. Voisi olla mahdollista yhdistää ensin yhteen verkkotunnukseen ja sitten luoda toinen yhteys olemassa olevan sisällä. Ja tämä voisi mahdollisesti suojata SNI:tä. Filippo: Eli joku tarkkailija ajattelisi, että menet sivulle blog.filippo.io mutta kun avaat yhteyden, voisit pyytää HTTP2:ta näyttämään myös "tämän toisen sivun". Kiitos! Herald: Selvä, seuraava kysymys, mikrofoni 7, tai itse asiassa 5, pahoittelut. Kysyjä: Mainitsitte, että TLS 1.3:sta on olemassa formaali verifikaatio. Millä ohjelmistolla tämä formaali verifikaatio on tehty? Nick: Oli useita ohjelmisto- implementaatioita ja protokollia... Katsotaanpa, jos pääsen takaisinpäin... tässä. Tamarin on ohjelmisto, jonka on kehittänyt muun muassa Cas Cremers Oxfordissa ja Royal Hollowayssa. miTLS on uskoakseni kirjoitettu F#:lla INRIA:n toimesta. Ja nqsb-TLS on kirjoitettu OCaml:lla. Joten useita eri kieliä käytettiin näiden kehityksessä ja käsittääkseni nqsb-TLS:n kehittäjät ovat paikalla... Herald: Selvä, seuraava kysymys mikrofoni 8. Kysyjä: Hei! Kiitos. Kiitos informatiivisesta esityksestä. SSL:n ja TSL:n historia on täynnä "mikä muka voisi mennä vikaan"-ideoita ja hetkiä, jotka lopulta kostautuivat. Joten kysymykseni, kun otetaan huomioon, että on useita pienempiä organisaatioita tai pienempiä hosting-yrityksiä jne., jotka luultavasti implementoivat 0-RTT:n väärin. Mikä on ensivaikutelmanne? Kuinka todennäköistä on, että tämä todella tulee kostautumaan pian? Kiitos. Filippo: Kuten sanoin, olen itse asiassa aavistuksen skeptinen vaikutusten suhteen koskien HTTP:tä, sillä selaimet saadaan uudelleenlähettämään pyyntöjä jo nyt. Ja olemme nähneet tästä julkaisuja ja blogipostauksia. Mutta kukaan ei kyennyt näyttämään toteen, että se olisi rikkonut suuren osuuden internetistä. Ollakseni rehellinen, en osaa vastata, kuinka pahasti se kostautuu. Mutta muistetaan, että tasapainon toinen puoli on se määrä ihmisiä, jotka sanovat etteivät aio ottaa TSL:ää käyttöön koska se on "hidas". Ei. Se on 0-RTT, TLS on nopea! Menkää ja salatkaa kaikki! Siis nuo ovat ne kaksi huolenaihetta, jotka täytyy saada tasapainoon. Lisäksi, oma henkilökohtainen mielipiteeni ei paina paljoa. Tämä oli päätös, jonka teki koko postituslistasta koostuva yhteisö. Ja voin vakuuttaa, että jokainen on ollut hyvin konservatiivinen kaiken suhteen, ottanut huomioon jopa... niin, senkin olisiko nimi johtanut ihmisiä harhaan. En osaa ennustaa tulevaisuutta. Voin vain sanoa toivovani, että teimme parhaan valinnan tehdäksemme suurimman osan verkosta niin turvalliseksi kuin voimme. Herald: Seuraava kysymys tulee internetistä. Signal Angel, onko meillä vielä kysymys internetistä? Signal Angel: Kyllä meillä on. Mitkä ovat suurimmat implementoinnin yhteensopimattomuudet, jotka on löydetty nyt kun lopullinen spesifikaatio on melko valmis? Herald: Voitko toistaa kysymyksen? (Signal Angel toistaa kysymyksen) Filippo: Okei. Koskien luonnosteluvaihetta? Osa niistä, jotka eivät olleet versio- yhteensopivia oli, uskoakseni, enimmäkseen "middleboxeja" ja palomuureja. Nick: Oli joitain todella isoja sivustojakin. Paypal taisi olla yksi? Filippo: Vaikkakin, prosessin aikana meillä oli yhteensopivuusongelmia monista syistä. Mukaanlukien se, missä toinen kehittäjistä kirjoitti väärin muuttujan numeron. (nauraa) Luonnosten aikana joskus yhteensopivuus meni rikki, mutta oli myös paljon yhteis- työtä asiakasimplementaatioiden ja meidän puolemme palvelinimplementaatioiden välillä. Voin onnekseni todeta, että varsinaisten 1.3 implementaatioiden kanssa tehtiin paljon yhteensopivuustestejä, ja kaikki ongelmat saatiin melko nopeasti korjattua. Herald: Okei, seuraava kysymys tulee mikrofonista numero 1. Kysyjä: Minulla on 2 nopeaa kysmystä koskien istunnon jatkamista. Jos palvelimelle tallennetaan jotain dataa istunnosta, eikö se olisi tavallaan jonkinlainen supereväste? Eikö se ole yksityisyyden kannalta vaarallista? Ja toinen kysymys on: entä DNS- kuormantasaajat tai jotkut muut valtavat määrät palvelimia, missä pyynnöt menevät joka kerta eri palvelimelle? Filippo: Ok, eli nämä koskevat yksityiskohtia istuntolippujen tehokkaasta jakelusta. TLS 1.3 ottaa huomioon yksityisyydensuojan koskien istuntolippuja, ja tosiaan se mahdollistaa palvelimen lähettämään useita istuntolippuja. Palvelin voi siis edelleen tietää mikä asiakas sen lähettää, jos niin haluaa. Mutta kukaan ulkopuolelta yhteyttä tarkkaileva ei siihen kykene, koska ne lähetetään salattuina, toisin kuin TLS 1.2:ssa ja niitä voi olla useita. Kukaan ulko- puolinen ei pysty yhdistämään sitä alkuperäiseen yhteyteen. Tämän parempaan ei pysty, sillä jos palvelimen ja asiakkaan täytyy käyttää uudelleen jotain jaettua tietoa, palvelimen täytyy saada tietää kuka oli kyseessä. Mutta istuntolippuja ei voi 1.3:ssa jäljittää kolmannen osapuolen toimesta. Ja... kun tehdään kuormantasausta... on eräs mielenkiintoinen julkaisu istuntolippujen jakelusta, mutta olennaista on, että kannattaa varmaan selvittää miten asiakkaat liikkuvat palvelimien välillä ja löytää tasapaino sen välillä kannattaako istuntolipun avain jakaa, jolloin se on tehokkaampaa vai jättää istuntolipun avain jakamatta, jolloin niitä on vaikeampi saada käsiinsä. Saattaisit tehdä maantieteellisen sijainnin mukaan, tai yhden räkin... Se riippuu ihan toteutuksesta. Herald: Okei, viimeinen kysymys menee mikrofonille 3. Kysyjä: Minulla on kysymys koskien GREASE-mekanismia, joka toteutetaan asiakkaan puolella. Jos ymmärsin oikein, siinä lisätään satunnaisia versionumeroita olemattomista TLS- tai SSL-versioista ja siten koulutetaan palvelimet mukautumaan spesifikaatioon. Mitkä ovat tosielämän testien tulokset? Moniko palvelin menee tästä oikeasti nurin? Filippo: Odotusarvoisesti ei yksikään, koska ne kaikki ovat nyt ottamassa 1.3:a käyttöön, joten kaikki asiakkaat, joita ne kohtaavat käyttäisivät GREASE:a. Kuitenkin, juuri kun Google otti GREASE:n käyttöön luulen sen rikkoneen... En ole varma, joten en sano mikä palvelin- implementaatio, mutta yhden pienemmistä tunnistettiin heti olevan... se Haskell-kielellä kirjoitettu! Nick: Aivan! Filippo: En muista sen nimeä, en osaa lukea Haskellia, joten en tarkalleen tiedä mitä ne tekivät, mutta ne katkaisivat yhteyksiä GREASE:n takia. Nick: Ja huomautuksena, GREASE:a käytetään myös salausneuvotteluissa ja kaikessa mikä on neuvottelu TLS 1.3:ssa. Tämä tosiaan rikkoi pienen osan palvelimista, mutta sen verran pienen osan, että ihmiset hyväksyivät sen. Kysyjä: Kiitos! Nick: 2 % on liikaa! Herald: Kiitos oikein paljon. Filippo: Kiitos! (aplodeja) (33C3 loppumusiikki) Translated by Roope Salminen (ITKST56 course assignment at JYU.FI)