Deploying TLS 1.3: the great, the good and the bad (33c3)

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)