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ä. Tämä tarkoittaa, että joku voi tehdä passiivisesti purkaa salausta hallinnoimalla istuntolippua. Tähän vastataan yleensä sanomalla, että istuntoliput vanhenevat nopeasti. Mutta eikö olisi mukavaa, jos meidän ei tarvitsisi luottaa siihen. Ja on olemassa julkaisuja, jotka kertovat meille, että toteutukset eivät aina tee tätä oikein. Siispä, TLS 1.3 sen sijaan mahdollistaa Diffie-Hellmanin käytön istunnon jatkamisessa. 1.2:ssa ei ollut keinoja suojautua istuntolipun joutumiselta vääriin käsiin. 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ä sertifikaatin 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, sertifikaattia ei ole. Koska ei ole tarvetta uudelleen autentikoida sertifikaatin avulla, koska asiakas ja palvelin juttelivat aiemmin, joten palvelin tietää tarkistaneensa jo palvelimen sertifikaatin, 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ä edestaikaisesta matkasta. TSL 1.2 istunnon jatkamiset voivat olla minimissään yhden edestakaisen matkan. TLS 1.3 istunnon jatkamiset voivat toimia ilman edestakaista matkaa. Kuinka se 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 aiemmin jo 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ä sertifikaatin 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 sertifikaatin väärinkäyttöä vastaan. TLS 1.3 toimii samoin. Ei ole moodia joka olisi jatkosuojaamaton sertifikaatin väärinkäytön varalta. Mutta jos ajatellaan mitä istuntolipun avaimelle voi käydä: TLS 1.2 ei koskaan ole jatkosuojattu. TLS 1.2:ssa istuntolipun murtaminen johtaa aina kykyyn passiivisesti ja jatkossa murtaa 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 istuntolippua. 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 ei 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 10s 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 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 data vastaan vai hylkäänkö sen kaiken?" Jos se hyväksyy 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. Jokatapauksessa. 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ä 1-RTT oletuksena, joihin toistohyökkäykset eivät toimi, ja sitten antaa palvelimen kutsua joitakin API:ja 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 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ökkäykses- sä 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 oman sovelluksena oiken 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ää salli GET-pyynnöt 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 itseasiassa, 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. TLS 1.3 ollessa iteraatio TLS:stä mekin menimme taaksepäin, tai, "me", jotka olemme ihmiset jotka tutkimme TLS:ää, katsoimme taaksepäin ja kertasimme olemassaolevia TLS 1.2 ominai- suuksia, jotka vaikuttivat järkeviltä aikanaan ja päätimme, oliko kompleksisuus tai vaara, jotka 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 sertifikaatin julkisella avaimella, joka on RSA-avain, ja lähettää sen sitten sellaisenaan palvelimelle. Ja palvelin sitten käyttää omaa yksityistä avaintaan purkamaan salauksen ja luomaan yhteisen avaimen. Eli asiakas luo kaiken avainmateriaalin tässä tapauksessa. Yksi asia on melko selvä tässä on, että jos sertifikaatin 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- listaa, 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 internettiä." 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... perus lohkosalain rakennelmia, jotka ovat poissa: AES-CBC. Poissa. RSA-PKCS1-1.5, tämä on tiedetty ongelmalliseksi jo vuodesta 1998, myöskin poissa! Myös useita ominaisuuksia kuten kompressio ja uudellenneuvottelu on poistettu, jonka 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, on mahdottomia TLS 1.3:ssa. (aplodeja)