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ä.