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

Translated by Roope Salminen
(ITKST56 course assignment at JYU.FI)
(33C3 intromusiikki)

Herald: Seuraava esitelmä
käsittelee TLS 1.3:n 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 nimeltää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äyte-
tää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 algoritmia,

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 ne 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. (huokaus) 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 istuntolipun 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 %:lla
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)