WEBVTT

00:00:00.000 --> 00:00:14.820
Translated by Roope Salminen
(ITKST56 course assignment at JYU.FI)
(33C3 intromusiikki)

00:00:14.820 --> 00:00:20.190
Herald: Seuraava esitelmä 
käsittelee TLS 1.3:n käyttöönottoa

00:00:20.190 --> 00:00:23.509
ja sen pitävät Filippo Valsorda 
sekä Nick Sullivan,

00:00:23.509 --> 00:00:26.989
jotka molemmat 
työskentelevät Cloudflarelle.

00:00:26.989 --> 00:00:32.110
Joten toivottakaamme lämpimästi 
tervetulleeksi Nick ja Filippo!

00:00:32.110 --> 00:00:39.490
(aplodeja)

00:00:39.490 --> 00:00:43.820
Filippo: Hei kaikki. Puheen-
aiheenamme tänään on TLS 1.3.

00:00:43.820 --> 00:00:48.340
TLS 1.3 on tietenkin uusin versio 
TLS:stä, joka tulee sanoista

00:00:48.340 --> 00:00:52.960
"Transport Layer Security".
Se on ehkä tunnetuin

00:00:52.960 --> 00:00:57.900
vihreästä lukosta selaimessa,
tai vanhalta nimeltään SSL,

00:00:57.900 --> 00:01:02.510
jota yritämme edelleen
tappaa. TLS on

00:01:02.510 --> 00:01:07.890
läpinäkyvä turvallisuusprotokolla,
joka voi turvallisesti tunneloida

00:01:07.890 --> 00:01:12.460
mielivaltaista sovellusliikennettä.
Sitä käyttävät tietenkin web-selaimet,

00:01:12.460 --> 00:01:16.760
sitä käyttävät sähköpostipalvelimet
turvaamaan keskinäistä

00:01:16.760 --> 00:01:22.270
SMTP-liikennettään. Sitä käyttävät 
Tor-solmut keskinäiseen kommunikointiinsa.

00:01:22.270 --> 00:01:26.810
Mutta... Se kehittyi yli 20 vuoden ajan,

00:01:26.810 --> 00:01:31.320
mutta pohjimmiltaan se koskee asiakasta
ja palvelinta, jotka haluavat kommunikoida

00:01:31.320 --> 00:01:36.119
turvallisesti verkon yli.
Kommunikoidakseen turvallisesti verkon yli

00:01:36.119 --> 00:01:41.170
niiden täytyy luoda avainmateriaalia,
sopia keskenään avainmateriaalista

00:01:41.170 --> 00:01:47.349
molemmin puolin salatakseen
tulevan liikenteen.

00:01:47.349 --> 00:01:51.989
Se, miten avainmateriaalista sovitaan,
hoidetaan vaiheessa, jota kutsumme

00:01:51.989 --> 00:01:57.890
"kättelyksi". Kättelyssä on mukana
julkisen avaimen kryptografiaa ja

00:01:57.890 --> 00:02:02.670
dataa, jota lapioidaan asiakkaalta
palvelimelle, palvelimelta asiakkaalle.

00:02:02.670 --> 00:02:07.170
Tältä kättely näyttää TLS 1.2:ssa.

00:02:07.170 --> 00:02:12.790
Asiakas aloittaa tanssit
lähettämällä "Client Hello"-viestin,

00:02:12.790 --> 00:02:18.960
jossa kertoo, mitä tuettuja
parametreja se voi käyttää.

NOTE Paragraph

00:02:18.960 --> 00:02:23.430
Palvelin vastaanottaa sen ja
lähettää oman viestinsä, joka on

00:02:23.430 --> 00:02:28.200
"Server Hello", joka sanoo "Selvä! Käyte-
tään tätä salausalgoritmien yhdistelmää,

00:02:28.200 --> 00:02:33.230
jota sanot tukevasi, ja tässä on minun
avainosuuteni käytettäväksi

00:02:33.230 --> 00:02:39.270
tässä avaintenvaihtoalgoritmissa.
Lisäksi, tässä on varmenne,

00:02:39.270 --> 00:02:45.300
jonka on allekirjoittanut auktoriteetti,
joka todistaa, että todellakin olen

00:02:45.300 --> 00:02:50.370
Cloudflare.com. Ja tässä on allekirjoitus 
varmenteesta todistamaan, että tämä

00:02:50.370 --> 00:02:55.450
avainosuus on todellakin se, jota haluan 
sinun käyttävän avainten luomiseen."

00:02:55.450 --> 00:03:00.940
Asiakas vastaanottaa sen ja generoi
oman avainosuutensa, eli oman puolensa

00:03:00.940 --> 00:03:06.200
Diffie-Hellman avaintenvaihdosta,
ja lähettää avainosuuden sekä

NOTE Paragraph

00:03:06.200 --> 00:03:10.999
viestin kertoakseen: "Se oli siinä.
Kättely on nyt paketissa".

00:03:10.999 --> 00:03:15.490
Tätä kutsutaan "Finished" viestiksi.
Palvelin vastaanottaa sen, luo

00:03:15.490 --> 00:03:20.679
oman "Finished" viestinsä
ja vastaa sillä. Eli

00:03:20.679 --> 00:03:25.930
nyt voimme vihdoin lähettää sovellusdataa. 
Kerrataanpa vielä prosessi:

00:03:25.930 --> 00:03:30.022
Asiakas -> Palvelin, Palvelin -> Asiakas;
Asiakas -> Palvelin, Palvelin -> Asiakas.

00:03:30.022 --> 00:03:34.960
Meidän täytyi tehdä 2 edestakaista matkaa 
asiakkaan ja palvelimen välillä ennen

00:03:34.960 --> 00:03:40.730
mitään muuta. Emme ole lähettäneet 
tavuakaan sovelluskerroksella

00:03:40.730 --> 00:03:46.010
ennen tätä. Tämä tietenkin 
matkapuhelinverkoissa

00:03:46.010 --> 00:03:50.539
tai tietyissä osissa
maailmaa voi kerryttää

00:03:50.539 --> 00:03:55.320
satojen millisekuntien viiveen. 
Ja tämä täytyy tehdä

00:03:55.320 --> 00:04:00.930
joka kerta, kun uutta yhteyttä avataan.
Joka kerta asiakkaan ja palvelimen

00:04:00.930 --> 00:04:06.490
täytyy kulkea kahdesti välinsä
luodakseen avaimet ennen

00:04:06.490 --> 00:04:12.730
kuin yhteyttä voi oikeasti
käyttää. TLS 1.1

00:04:12.730 --> 00:04:17.950
ja 1.0 eivät eronneet suuresti 
1.2:sta. Voisikin kysyä: "Miksi sitten

00:04:17.950 --> 00:04:23.750
pitää kokonainen esitys TLS 1.3:sta,
joka on luultavasti vain taas yksi

00:04:23.750 --> 00:04:31.430
iteraatio samasta konseptista?" No, TLS
1.3 on oikeasti iso uudelleensuunnittelu.

00:04:31.430 --> 00:04:36.740
Erityisesti kättely on restukturoitu. 
Ja tämän näkyvin tulos

00:04:36.740 --> 00:04:43.139
on se, että yksi kokonainen 
edestakainen matka on karsittu pois.

00:04:43.139 --> 00:04:48.929
Eli, tältä näyttää TLS 1.3-kättely.

00:04:48.929 --> 00:04:53.479
Kuinka 1.3 poistaa edestakaisen matkan?
Miten se pystyy siihen? Se kykenee siihen

00:04:53.479 --> 00:04:59.799
ennustamalla, mitä 
avaintenvaihtoalgoritmia

00:04:59.799 --> 00:05:04.740
palvelin tulee käyttämään, ja
lähettämällä ennakkoon avainosuuden

00:05:04.740 --> 00:05:10.029
tuota algoritmia varten palvelimelle.
Eli ensimmäisessä viestissä meillä oli

00:05:10.029 --> 00:05:15.529
"Client Hello", tuetut parametrit
ja avainosuus algoritmille,

00:05:15.529 --> 00:05:21.549
josta asiakas uskoo palvelimen pitävän.
Palvelin vastaanottaa viestin,

00:05:21.549 --> 00:05:27.239
ja jos kaikki menee hyvin, se ajattelee:
"Ah! Okei! Tykkään tästä avainosuudesta.

00:05:27.239 --> 00:05:32.789
Tässä on oma avainosuuteni samaa
algoritmia varten, ja tässä muut

00:05:32.789 --> 00:05:37.719
parametrit, joita meidän tulisi käyttää."
Se välittömästi sekoittaa avainosuudet

00:05:37.719 --> 00:05:42.319
saadakseen jaetun yhteisen avaimen, koska
nyt sillä on molemmat avainosuudet -

00:05:42.319 --> 00:05:47.089
asiakkaan ja palvelimen - ja lähettää
taas varmenteen ja allekirjoituksen

00:05:47.089 --> 00:05:51.339
varmenteesta, ja sitten välittömästi
lähettää "Finished"-viestin, koska

00:05:51.339 --> 00:05:56.339
se ei tarvitse mitään muuta asiakkaalta. 
Asiakas vastaanottaa tuon, ottaa

00:05:56.339 --> 00:06:02.020
avainosuuden, luo jaetun yhteisen avaimen 
ja lähettää oman "Finished" viestinsä,

00:06:02.020 --> 00:06:07.009
ja on valmis lähettämään sitä sovellus-
dataa, jota olikaan lähettämässä.

00:06:07.009 --> 00:06:12.650
Esimerkiksi HTTP-pyynnön.
Nyt prosessi meni näin:

00:06:12.650 --> 00:06:15.919
Asiakas -> Palvelin, Palvelin -> Asiakas.

00:06:15.919 --> 00:06:21.330
Ja olemme valmiita lähettämään
sovelluskerroksen dataa. Eli, jos olit

00:06:21.330 --> 00:06:27.239
avaamassa HTTPS-yhteyttä, selaimesi

00:06:27.239 --> 00:06:32.769
ei tarvitse odottaa nelinkertaista viivettä, 
nelinkertaista pingiä. Sen täytyy

00:06:32.769 --> 00:06:38.929
odottaa vain kaksinkertainen, ja tämä
tietysti säästää satoja millisekunteja

00:06:38.929 --> 00:06:46.199
viivettä kun avataan uusia yhteyksiä.
Tämä oli onnellinen tapaus.

00:06:46.199 --> 00:06:52.299
Näin käy, kun ennustus osuu oikeaan
ja palvelin tykkää asiakkaan

00:06:52.299 --> 00:06:58.449
avainosuudesta. Jos palvelin
ei tue avainosuutta, jonka

00:06:58.449 --> 00:07:05.169
asiakas lähetti, se lähettää kohteliaan
pyynnön käyttää jotain toista algoritmia,

00:07:05.169 --> 00:07:10.530
jota asiakas sanoi tukevansa. Tätä viestiä
kutsutaan nimellä "Hello Retry Request".

00:07:10.530 --> 00:07:16.469
Siinä on eväste, joten se voi olla tilaton
mutta periaatteessa se on varakeino,

00:07:16.469 --> 00:07:21.970
jolla palataan käytännössä TLS 1.2-
kaltaiseen kättelyyn. Eikä se ole kovin

00:07:21.970 --> 00:07:26.939
vaikea toteuttaa, koska asiakas jatkaa
uudella "Client Hello":lla, joka näyttää

00:07:26.939 --> 00:07:34.489
periaattessa täysin samalta kuin
täysin tuorekin. Nyt...

00:07:34.489 --> 00:07:42.179
Tässä kohtaa olen valehdellut. TLS 1.2
ei aina ole 2 edestakaista matkaa.

00:07:42.179 --> 00:07:47.779
Suurin osa yhteyksistä, joita näemme 
esimerkiksi Cloudflaren reunalta ovat

00:07:47.779 --> 00:07:53.299
istunnon jatkamisia. Eli asiakas on ollut
yhteydessä k.o. sivustolle aiemmin.

00:07:53.299 --> 00:07:59.079
Ja voimme käyttää tätä, voimme hyödyntää
tätä ja tehdä kättelystä nopeamman.

00:07:59.079 --> 00:08:06.290
Tämä tarkoittaa, että asiakas muistaa
jotain avainmateriaalista, jotta pystyy

00:08:06.290 --> 00:08:10.959
avaamaan seuraavan yhteyden vain yhdellä
edestakaisella matkalla myös TLS 1.2:ssa.

00:08:10.959 --> 00:08:16.019
Eli tältä se näyttää. Tässä on normaali
TLS 1.2:n täysi kahden edestakaisen

00:08:16.019 --> 00:08:22.479
matkan yhteys. Ja tässä palvelin lähettää
lipun uutta istuntoa varten. Istuntolippu

00:08:22.479 --> 00:08:30.029
ei ole sen kummempi kuin salattu kapse-
loitu blob sisältäen avainmateriaalia,

00:08:30.029 --> 00:08:35.100
jonka asiakas säilyttää. Istuntolippu on
salattu ja allekirjoitettu avaimella,

00:08:35.100 --> 00:08:40.039
jonka vain palvelin tietää. Eli se on
täysin läpinäkymätön asiakkaalle.

00:08:40.039 --> 00:08:45.040
Mutta asiakas säilyttää sen sekä
yhteyden avainmateriaalin,

00:08:45.040 --> 00:08:49.340
jotta seuraavan kerran kun se avaa
yhteyttä samalle sivustolle

00:08:49.340 --> 00:08:54.439
se lähettää "Client Hello":n
ja istuntolipun.

00:08:54.439 --> 00:08:59.180
Jos palvelin tunnistaa istuntolipun, se
purkaa sen salauksen ja löytää sisältä

00:08:59.180 --> 00:09:04.090
avainmateriaalin. Ja nyt, vain yhden edes-
takaisen matkan jälkeen, palvelimella on

00:09:04.090 --> 00:09:09.820
yhteistä avainmateriaalia asiakkaan kanssa
koska asiakas säilytti sen viime kerrasta

00:09:09.820 --> 00:09:15.460
ja palvelin juuri purki sen 
salatusta istuntolipusta.

00:09:15.460 --> 00:09:20.890
Ok? Eli nyt palvelimella on jo käytet-
tävissä yhteisiä jaettuja avaimia ja se

00:09:20.890 --> 00:09:26.150
lähettää "Finished"-viestin ja asiakas 
vastaa "Finished"-viestillä ja pyynnöllä.

00:09:26.150 --> 00:09:31.550
Eli tämä on TLS 1.2. Tätä tapahtuu
jo nyt joka päivä useimpien

00:09:31.550 --> 00:09:37.380
modernien TLS-yhteyksien kanssa.

00:09:37.380 --> 00:09:43.530
TLS 1.3-istunnon jatkaminen ei ole kovin
erilainen. Siinäkin on istuntolipun käsite

00:09:43.530 --> 00:09:48.300
Istuntolipun sisällön nimi on muutettu
"PSK":ksi, mutta se tulee vain sanoista

00:09:48.300 --> 00:09:53.220
"Pre-shared Key", koska sitähän se on:
pelkkää avainmateriaalia, josta

00:09:53.220 --> 00:09:58.480
oli sovittu aiemmin.
Ja se toimii samalla tavalla:

00:09:58.480 --> 00:10:02.830
palvelin vastaanottaa istuntolipun,
purkaa salauksen ja hyppää

00:10:02.830 --> 00:10:07.450
"Finished"-viestiin. Nyt...

00:10:07.450 --> 00:10:13.070
Ongelma istunnon jatkamisessa on se,
että jos hyökkääjällä on hallussaan

00:10:13.070 --> 00:10:17.130
istuntolipun avain - eli avain, jota 
palvelin käyttää salamaan istuntolipun,

00:10:17.130 --> 00:10:21.540
jonka sisällä avainmateriaali on -

00:10:21.540 --> 00:10:27.050
hyökkääjä voi passiivisesti, tai jopa
tulevaisuudessa kaapatun yhteyden

00:10:27.050 --> 00:10:33.460
tapauksessa, purkaa istuntolipun
"Client Hello":sta, löytää sieltä PSK:n

00:10:33.460 --> 00:10:38.320
ja käyttää sitä purkamaan koko loppu-
yhteyden salauksen. Tämä ei ole hyvä.

00:10:38.320 --> 00:10:42.519
Tämä tarkoittaa, että joku voi
passiivisesti purkaa salauksen

00:10:42.519 --> 00:10:47.819
hallinnoimalla istuntolipun avainta.
Tähän vastataan yleensä sanomalla, että

00:10:47.819 --> 00:10:52.540
Lippujen avaimet vanhenevat nopeasti.
Mutta eikö olisi mukavaa, jos meidän ei

00:10:52.540 --> 00:10:56.270
tarvitsisi luottaa siihen. Ja on itse
asiassa julkaisuja, jotka kertovat meille

00:10:56.270 --> 00:11:01.310
että toteutukset eivät aina
tee tuota oikein. Siispä,

00:11:01.310 --> 00:11:07.050
TLS 1.3 sen sijaan mahdollistaa
Diffie-Hellmanin käytön

00:11:07.050 --> 00:11:11.760
istunnon jatkamisessa. 1.2:ssa
ei ollut keinoja suojautua istunto-

00:11:11.760 --> 00:11:16.720
lipun avaimen murtamisen
seurauksilta. 1.3:ssa voi sen sijaan

00:11:16.720 --> 00:11:21.409
lähettää avainosuuden
osana "Client Hello":ta

00:11:21.409 --> 00:11:25.499
ja palvelin lähettää avainosuuden 
"Server Hello":n yhteydessä,

00:11:25.499 --> 00:11:31.710
ja osapuolet suorittavat Diffie-Hellmanin.
Diffie-Hellmania käytettiin

00:11:31.710 --> 00:11:36.009
jatkosuojauksen toteuttamiseen esimerkiksi
sen varalta, että varmenteen yksityinen

00:11:36.009 --> 00:11:41.339
avain joutuisi vääriin käsiin 1.2:ssa, ja 
tässä sitä käytetään jatkosuojauksen

00:11:41.339 --> 00:11:46.290
toteuttamiseen istunnon jatkamisessa.
Nyt, saatatte miettiä:

00:11:46.290 --> 00:11:51.240
"Tämä näyttää periaatteessa
normaalilta 1.3 kättelyltä,

00:11:51.240 --> 00:11:55.770
mikä virka PSK:lla on ylipäätään?"
Tästäpä puuttuukin jotakin.

00:11:55.770 --> 00:11:59.510
Varmennetta ei ole. Koska ei ole 
tarvetta autentikoida uudelleen

00:11:59.510 --> 00:12:04.620
varmenteen avulla, koska asiakas ja 
palvelin juttelivat aiemmin, joten

00:12:04.620 --> 00:12:09.099
asiakas tietää tarkistaneensa jo
palvelimen varmenteen,

00:12:09.099 --> 00:12:12.819
ja mikäli palvelin pystyy purkamaan
istuntolipun salauksen, se tarkoittaa,

00:12:12.819 --> 00:12:17.879
että palvelin on se joksi itseään väittää.
Joten kaksi avainosuutta yhdistetään.

00:12:17.879 --> 00:12:22.860
Sitten ne yhdistetään PSK:n kanssa, jotta
saadaan avain, jolla salataan loput

00:12:22.860 --> 00:12:29.580
yhteydestä. On olemassa vielä 
yksi uusi ominaisuus, jonka

00:12:29.580 --> 00:12:34.701
TLS 1.3 istunnon jatkaminen tuo
mukanaan. Se on se seikka, että se

00:12:34.701 --> 00:12:40.830
mahdollistaa kättelyn ilman edestakaista
matkaa (0-RTT). Muistutuksena,

00:12:40.830 --> 00:12:47.280
kaikki kättelyt 1.3:ssa koostuvat enim-
mäkseen yhdestä edestakaisesta matkasta.

00:12:47.280 --> 00:12:52.140
TSL 1.2 istunnon jatkamiset voivat olla
minimissään yhden edestakaisen matkan.

00:12:52.140 --> 00:12:58.331
TLS 1.3 istunnon jatkamiset voivat toimia
ilman edestakaista matkaa. Kuinka 0-RTT

00:12:58.331 --> 00:13:04.210
kättely toimii? Ajatellaanpa. 
Alkuun on PSK.

00:13:04.210 --> 00:13:10.119
Pre-shared Key.
Asiakas voi käyttää sitä salaamaan

00:13:10.119 --> 00:13:15.680
tämän alkudatan, jonka haluaa lähettää
palvelimelle. Joten asiakas avaa

00:13:15.680 --> 00:13:20.439
yhteyden palvelimeen, johon
on jo aiemmin ollut yhteydessä,

00:13:20.439 --> 00:13:25.349
ja lähettää "Client Hello":n, 
istuntolipun,

00:13:25.349 --> 00:13:29.920
avainosuuden Diffie-Hellmaniin ja 
alkudatan. Alkudata on

00:13:29.920 --> 00:13:34.410
blob sovellusdataa - se voi olla
esimerkiksi HTTP-pyyntö -

00:13:34.410 --> 00:13:39.409
salattuna PSK:lla.
Palvelin vastaanottaa tämän,

00:13:39.409 --> 00:13:45.369
purkaa istuntolipun, löytää PSK:n,
käyttää PSK:ta purkamaan

00:13:45.369 --> 00:13:50.770
alkudatan ja jatkaa sitten normaalisti:
yhdistää avainosuudet, lisää PSK:n,

00:13:50.770 --> 00:13:55.270
luo uuden avaimen lopulle
yhteydelle ja jatkaa yhteyttä.

00:13:55.270 --> 00:14:00.289
Eli mitä tässä tapahtui? Voimme lähettää
sovellusdataa välittömästi yhteyden

00:14:00.289 --> 00:14:05.339
avaamisen yhteydessä. Tämä tarkoittaa,
että poistimme suorituskyvyn

00:14:05.339 --> 00:14:11.320
yleiskustannukset TLS:ssä.

00:14:11.320 --> 00:14:16.460
0-RTT kättelyissä on kuitenkin kaksi
vaaran paikkaa, jotka ovat teoriassa

00:14:16.460 --> 00:14:22.540
mahdoton poistaa. Yksi on se, että 
se kiva asia joka tuli PSK ECDHE moodin

00:14:22.540 --> 00:14:27.829
mukana, se jossa käytetään Diffie-
Hellmania istunnon jatkamiseen

00:14:27.829 --> 00:14:33.040
1.3:ssa, ei auta 0-RTT datan kanssa.

00:14:33.040 --> 00:14:38.620
Käytämme Diffie-Hellmania kun
saavumme dian vihreään laatikkoon.

00:14:38.620 --> 00:14:44.000
Tietysti alkudata on salattu vain 
PSK:lla. Mietitäänpä taas

00:14:44.000 --> 00:14:49.150
hyökkääjää. Hyökkääjä jollain keinolla
varasti istuntolippumme salausavaimet.

00:14:49.150 --> 00:14:54.969
Se voi katsoa "Client Hello":a, purkaa 
istuntolipun, saada PSK:n,

00:14:54.969 --> 00:15:00.029
käyttää PSK:ta purkamaan
alkudatan salauksen.

00:15:00.029 --> 00:15:05.350
Se voi tehdä tämän kaapatustakin liiken-
teestä, jos saa istuntolipun myöhemmin.

00:15:05.350 --> 00:15:11.519
Siispä alkudata ei ole jatkosuojattu
istuntolipun avainten suhteen.

00:15:11.519 --> 00:15:16.679
Pelkkä PSK on kuitenkin hyödytön, jos 
käytämme Diffie-Hellmania palvelimen

00:15:16.679 --> 00:15:23.020
vastauksessa. Se on hyödyllinen ainoastaan
asiakkaan ensimmäisen viestin kohdalla.

00:15:23.020 --> 00:15:28.340
Kerrataanpa. Tässä on
paljon asiaa. TLS 1.2 toi

00:15:28.340 --> 00:15:33.379
jatkosuojauksen sen varalle, että
varmenteen yksityinen avain

00:15:33.379 --> 00:15:39.119
joutuisi vääriin käsiin, jo kauan sitten
käyttämällä ECDHE moodeja.

00:15:39.119 --> 00:15:45.030
Siis 1.2 yhteydet voivat olla aina jatko-
suojattuja varmenteen murtamisen

00:15:45.030 --> 00:15:50.300
varalta. TLS 1.3 toimii samoin.

00:15:50.300 --> 00:15:55.090
Ei ole moodia, joka olisi jatkosuojaamaton
varmenteen murtamisen varalta.

00:15:55.090 --> 00:16:01.279
Mutta, jos ajatellaan mitä
istuntolipun avaimelle voi käydä:

00:16:01.279 --> 00:16:06.000
TLS 1.2 ei koskaan tarjoa jatkosuojausta.

00:16:06.000 --> 00:16:11.149
TLS 1.2:ssa istuntolipun avaimen
murtaminen johtaa aina kykyyn passiivisesti

00:16:11.149 --> 00:16:15.819
murtaa tulevien jatkettujen
istuntojen salaus.

00:16:15.819 --> 00:16:22.689
1.3:ssa sen sijaan, jos käytämme
PSK ECDHE:tä, ainoastaan alkudatan salaus

00:16:22.689 --> 00:16:28.270
voidaan purkaa käyttämällä
pelkästään istuntolipun avainta.

00:16:28.270 --> 00:16:33.199
Kuten sanoin, vaaran paikkoja on kaksi.

00:16:33.199 --> 00:16:39.329
Toinen se, että 0-RTT dataa voidaan
käyttää toistohyökkäyksessä.

00:16:39.329 --> 00:16:45.449
Olkoon tilanne tämä: alkudata
sisältää dataa, joka on jollain tapaa

00:16:45.449 --> 00:16:51.709
autentikoitu. Se voi olla HTTP-
pyyntö, joka sisältää evästeitä.

00:16:51.709 --> 00:16:58.070
Tuo HTTP-pyyntö jollain
tapaa suorittaa transaktion,

00:16:58.070 --> 00:17:03.150
okei? Ehkä se on tilisiirto. Ohjeistaa
palvelinta tekemään jotain. Hyökkääjä

00:17:03.150 --> 00:17:07.580
haluaa toistaa tuota tapahtumaa. Se ei
tietenkään voi purkaa sen salausta

00:17:07.580 --> 00:17:13.149
- sehän on suojattu TLS:llä. Eli se ei voi
nähdä evästeen sisältöä, eikä se voi

00:17:13.149 --> 00:17:17.689
muokata sitä, koska se on TLS-suojattu.
Mutta se voi kaapata salatun

00:17:17.689 --> 00:17:23.069
viestin ja lähettää sen uudelleen

00:17:23.069 --> 00:17:27.900
palvelimelle. Jos palvelimia on yksi,
tähän on helppo ratkaisu.

00:17:27.900 --> 00:17:32.520
Pidä kirjaa nähdyistä viesteistä
ja ajattele kutakuinkin näin:

00:17:32.520 --> 00:17:37.500
"Ei. Tämä näyttää täsmälleen samalta kuin
mitä sain aiemmin." Mutta jos esimerkiksi,

00:17:37.500 --> 00:17:42.270
kuten Cloudflare, pyörität useita data-
keskuksia ympäri maailmaa, et voi pitää

00:17:42.270 --> 00:17:47.650
yhdenmukaisia tiloja jatkuvasti, reaali-
ajassa, kaikkien koneiden välillä. Olisi

00:17:47.650 --> 00:17:52.370
eri koneita, jotka tämän viestin
saatuaan ajattelisivat näin:

00:17:52.370 --> 00:17:57.530
"Toki, minulla on istuntolipun avain,
dekryptaan PSK:n, käytän PSK:ta,

00:17:57.530 --> 00:18:02.080
dekryptaan alkudatan, löydän sieltä jotain
ja suoritan sen mitä se käskee minun

00:18:02.080 --> 00:18:07.510
tehdä." Tämä ei tietenkään ole suotavaa.

00:18:07.510 --> 00:18:13.010
Yksi TLS.n tarjoama vastatoimi on,
että asiakas lähettää samassa

00:18:13.010 --> 00:18:18.689
paketissa arvon, joka kertoo
millisekunteina, kuinka kauan sitten sain

00:18:18.689 --> 00:18:23.790
haltuuni istuntolipun. Palvelin katsoo
sitä arvoa, ja jos se ei täsmää

00:18:23.790 --> 00:18:29.080
sen omaan näkemykseen tästä 
tiedosta, se hylkää viestin.

00:18:29.080 --> 00:18:34.020
Tämä tarkoittaa, että jos hyökkääjä
kaappaa viestin ja 10 s myöhemmin

00:18:34.020 --> 00:18:40.000
yrittää toistohyökkäystä, ajat eivät
täsmää ja palvelin hylkää viestin.

00:18:40.000 --> 00:18:44.510
Tämä ei kuitenkaan ole täysi ratkaisu,
sillä tarpeeksi nopea hyökkääjä voi

00:18:44.510 --> 00:18:50.369
silti tehdä toistohyökkäyksiä.
Eli, palvelin voi ainoastaan joko

00:18:50.369 --> 00:18:55.970
hyväksyä 0-RTT datan
tai hylätä sen.

00:18:55.970 --> 00:19:00.570
Se ei voi vain ottaa jotain osaa siitä tai
kurkistaa siihen ja päättää sitten, koska

00:19:00.570 --> 00:19:05.540
"Server Hello"-viesti kertoo (asiakkaalle)
hyväksyttiinkö vai hylättiinkö se.

00:19:05.540 --> 00:19:09.759
Ja asiakas jatkaa alkudatan lähettämistä
kunnes se saa "Server Hello"-viestin.

00:19:09.759 --> 00:19:15.960
Tässä on kilpailu. Joten palvelimen täytyy
sokkona päättää "Otanko 0-RTT dataa vastaan

00:19:15.960 --> 00:19:20.990
vai hylkäänkö sen kaiken?" Jos se ottaa
sen, ja sitten huomaa sen olevan jotain

00:19:20.990 --> 00:19:26.750
mitä se ei voi prosessoida koska "Herran-
jestas, täällä on HTTP POST, joka käskee

00:19:26.750 --> 00:19:32.470
siirtämään rahaa. En voi tehdä tätä, jos
en tiedä ettei tämä ole toistohyökkäys."

00:19:32.470 --> 00:19:37.060
Palvelimen täytyy saada jonkinlainen
vahvistus. Hyvä uutinen on se, että jos

00:19:37.060 --> 00:19:40.600
palvelin odottaa "Finished" 
viestiä... Palvelin lähettää

00:19:40.600 --> 00:19:45.280
"Server Hello":n, "Finished":n ja 
odottaa asiakkaan vastaavaa.

00:19:45.280 --> 00:19:51.050
Kun asiakkaan oma saapuu, se tarkoittaa,
ettei kyseessä ollut toistohyökkäys,

00:19:51.050 --> 00:19:54.950
sillä tuo "Finished" viesti 
viimeistelee koko kättelyn

00:19:54.950 --> 00:19:59.769
yhdessä tietyn satunnaisarvon kanssa,
jonka palvelin lähetti. Kyseessä ei siis

00:19:59.769 --> 00:20:04.380
voi olla toistohyökkäys. Eli nämä ovat
palvelimen vaihtoehdot: se voi hyväksyä

00:20:04.380 --> 00:20:08.780
alkudatan ja jos se on jotain mikä
ei ole idempotenttia, jotain mikä on

00:20:08.780 --> 00:20:14.610
vaarallista jos se toistetaan, se voi
yksinkertaisesti odottaa vahvistusta.

00:20:14.610 --> 00:20:18.850
Mutta se tarkoittaa, että se on laitettava
välimuistiin, ja tässä on riski, mikäli

00:20:18.850 --> 00:20:25.580
hyökkääjä lähettää HTTP POST:n valtavalla 
rungolla tarkoituksenaan täyttää muisti.

00:20:25.580 --> 00:20:31.840
Tajusimme voivamme auttaa tässä,
jos kirjoitamme istuntolippuihin,

00:20:31.840 --> 00:20:37.240
mikä on maksimimäärä alkudataa,
jonka asiakas voi lähettää.

00:20:37.240 --> 00:20:41.500
Jos huomaamme jonkun lähettävän
enemmän, kyseessä on hyökkääjä ja

00:20:41.500 --> 00:20:47.499
katkaisemme yhteyden, tyhjennämme
välimuistin vapauttaaksemme muistia.

00:20:47.499 --> 00:20:52.969
Mutta. Joka tapauksessa. Vastatoimista 
huolimatta, ellemme pysty pitämään

00:20:52.969 --> 00:20:58.780
yhtenäistä maailmanlaajuista tilaa 
palvelimien välillä, meidän täytyy kertoa

00:20:58.780 --> 00:21:03.429
sovellukselle toistohyökkäyksen mahdol-
lisuudesta. Spesifikaatio tietää tämän.

00:21:03.429 --> 00:21:08.150
TLS 1.3 spesifikaatio YKSISELITTEISESTI toteaa

00:21:08.150 --> 00:21:14.420
protokollien EI tule käyttää 
0-RTT:tä ilman profiilia, joka

00:21:14.420 --> 00:21:19.159
määrittelee sen käytön. Eli tarkoittaa
"tietämättä mitä ne ovat tekemässä".

00:21:19.159 --> 00:21:24.419
Tämä tarkoittaa, että TLS-pinon APIen
täytyy tehdä oletuksena 1-RTT,

00:21:24.419 --> 00:21:30.360
johon toistohyökkäykset eivät
toimi, ja sitten antaa palvelimen

00:21:30.360 --> 00:21:35.571
kutsua joitakin API:a hylätäkseen 
tai odottaakseen vahvistusta,

00:21:35.571 --> 00:21:41.470
ja antaa asiakkaan päättää, mitä tähän
vaaralliseen toistohyökkäysalttiiseen

00:21:41.470 --> 00:21:46.040
dataan tulee. Tämä riippuu

00:21:46.040 --> 00:21:49.840
protokollasta, mutta entäpä 
lempiprotokollamme? Entäpä

00:21:49.840 --> 00:21:55.329
HTTP? HTTP:n pitäisi olla
helppo. HTTP-spesifikaatio,

00:21:55.329 --> 00:22:00.759
käykää vaikka lukemassa, sanoo:
"GET-pyynnöt ovat idempotentteja,

00:22:00.759 --> 00:22:06.149
niiden ei tule muuttaa mitään palveli-
mella". Selvä! Sallimme nyt ainoastaan

00:22:06.149 --> 00:22:10.670
GET-pyynnöt alkudatassa, koska niitä ei
voi hyödyntää toistohyökkäyksissä!

00:22:10.670 --> 00:22:16.640
Jes! Ei. (huokaus) Internetissä on 
takuuvarmasti palvelin,

00:22:16.640 --> 00:22:23.020
jossa on jotain sen kaltaista kuin
“send-money.php?to=filippo&amount=this”

00:22:23.020 --> 00:22:28.870
ja se on GET-pyyntö. Ja jos hyökkääjä
kaappaa tämän, mikä on alkudataa,

00:22:28.870 --> 00:22:33.510
ja sitten käyttää tätä toistohyök-
käyksessä toista palvelinta vastaan, se

00:22:33.510 --> 00:22:38.780
suoritetaan kahdesti.
Ja se ei käy päinsä.

00:22:38.780 --> 00:22:43.300
Mitä siis voidaan tehdä?

00:22:43.300 --> 00:22:46.890
Teemme kompromisseja!

00:22:46.890 --> 00:22:51.779
Jos tunntet sovelluksesi, voit tehdä hyvin
spesifejä kompromisseja. Esimerkiksi

00:22:51.779 --> 00:22:57.020
Google on ajanut QUIC:iä
0-RTT:llä hyvinkin pitkään.

00:22:57.020 --> 00:23:02.200
Uskoakseni 3 vuotta? Se tarkoittaa, että
he tuntevat sovelluksensa oikein hyvin.

00:23:02.200 --> 00:23:07.419
Ja he tietävät, ettei heillä ole
"send-money.php" päätepisteitä.

00:23:07.419 --> 00:23:12.710
Mutta jos olet kuin Cloudflare, joka
hallinnnoi suurta määrää sovelluksia,

00:23:12.710 --> 00:23:17.720
et voi tehdä noin laajoja olettamuksia,
ja täytyy sen sijaan yrittää

00:23:17.720 --> 00:23:22.570
löytää kultainen keskitie. Me 
saattaisimme esimerkiksi päättää

00:23:22.570 --> 00:23:28.730
sallia GET-pyynnöt ainoastaan
juurihakemistoon. Eli "GET /",

00:23:28.730 --> 00:23:33.200
mikä saattaisi tuoda eniten hyötyä, sillä
ehkä suurin osa yhteyksistä alkaa noin,

00:23:33.200 --> 00:23:38.710
ja se on vähiten todennäköinen
aiheuttamaan hankaluuksia.

00:23:38.710 --> 00:23:43.140
Mietimme edelleen kuinka sovellamme
tätä sovelluksiin. Eli jos tiedossasi

00:23:43.140 --> 00:23:48.199
on sovellus, joka tulisi kärsimään 
jostain noin yksinkertaisesta,

00:23:48.199 --> 00:23:53.840
lähetä meille sähköpostia. Mutta 
itse asiassa, jos sinulla on noin

00:23:53.840 --> 00:23:59.160
haavoittuvainen sovellus, minulla
on huonoja uutisia. Thai Duong et. al.

00:23:59.160 --> 00:24:04.150
osoittivat, että tämän päivän selaimet,
ilman TLS 1.3:a tai muutakaan,

00:24:04.150 --> 00:24:09.740
toistavat HTTP-pyyntöjä
verkkovirheiden sattuessa.

00:24:09.740 --> 00:24:15.670
Ja ne toistavat ne hiljaisesti.
Eli lopputulema ei välttämättä ole

00:24:15.670 --> 00:24:21.990
huonompi kuin nykytila. Selvä.
Näen, että kaikki alkavat olla

00:24:21.990 --> 00:24:27.959
levottomia ja ajattelevat
"Kryptografit ovat taas asialla!

00:24:27.959 --> 00:24:32.740
He tekevät tarvitsemastamme turvallisuus-
protokollasta tarpeettoman monimutkaisen

00:24:32.740 --> 00:24:38.889
turvatakseen työpaikkansa
seuraavaksi 15 vuodeksi!" Eikö?

00:24:38.889 --> 00:24:44.479
Ei. Ei. Voin itseasiassa taata, että

00:24:44.479 --> 00:24:49.709
yksi suurista muutoksista, mielestäni
suurempi kuin edestakaiset matkat 1.3:ssa,

00:24:49.709 --> 00:24:54.770
on, että kaikkea punnitaan saadun hyödyn
ja sen aiheuttaman monimutkaisuuden

00:24:54.770 --> 00:24:59.180
kannalta. Ja vaikka 0-RTT pääsi jatkoon

00:24:59.180 --> 00:25:02.630
valtaosa ei päässyt.

00:25:02.630 --> 00:25:07.890
Nick: Selvä. Kiitos Filippo. Toimiiko
mikrofonini? Kuuletteko minut? Selvä.

00:25:07.890 --> 00:25:13.640
TLS 1.3:n ollessa iteraatio TLS:stä
mekin katsoimme taaksepäin, tai,

00:25:13.640 --> 00:25:18.120
"me", jotka olemme ihmiset jotka tutkivat
TLS:ää, katsoimme taaksepäin ja

00:25:18.120 --> 00:25:22.770
kertasimme olemassa olevia TLS 1.2:n omi-
naisuuksia, jotka vaikuttivat järkeviltä

00:25:22.770 --> 00:25:27.439
aikanaan ja päätimme, oliko kompleksisuus
tai vaara, jonka nämä TLS:n ominaisuudet tai

00:25:27.439 --> 00:25:32.349
protokollat tai primitiivit toivat mukanaan

00:25:32.349 --> 00:25:37.739
järkeviä säilyttää. Ja yksi iso,
joka sattui prosessin alussa on

00:25:37.739 --> 00:25:43.790
"staattinen RSA" moodi. Näin TLS on
toiminut SSL:n ajoista lähtien.

00:25:43.790 --> 00:25:48.179
Sen sijaan, että käytettäisiin Diffie-
Hellmania yhteisen avaimen luontiin,

00:25:48.179 --> 00:25:52.320
asiakas luo oman jaetun avaimensa, ja 
salaa sen palvelimen varmenteen

00:25:52.320 --> 00:25:56.570
julkisella avaimella, joka on
RSA-avain, ja lähettää sen sitten

00:25:56.570 --> 00:26:00.770
sellaisenaan palvelimelle. Ja
palvelin sitten käyttää omaa

00:26:00.770 --> 00:26:04.650
yksityistä avaintaan purkamaan salauksen
ja löytää yhteisen avaimen. Eli asiakas

00:26:04.650 --> 00:26:09.710
luo kaiken avainmateriaalin tässä
tapauksessa. Yksi asia on melko selvä

00:26:09.710 --> 00:26:13.650
tässä on, että jos varmenteen
yksityinen avain murretaan,

00:26:13.650 --> 00:26:18.149
vaikka vuosiakin myöhemmin, joku
jolla on tallenteet tapahtumista voi

00:26:18.149 --> 00:26:23.480
mennä taaksepäin ja purkaa tämän avain-
materiaalin ja siten koko keskustelun.

00:26:23.480 --> 00:26:28.419
Tämä poistettiin ihan TLS 1.3-prosessin
alkuvaiheessa, noin kaksi vuotta sitten.

00:26:28.419 --> 00:26:33.919
Joten suureksi yllätykseksemme,
ja kaikkien, jotka kuuluvat

00:26:33.919 --> 00:26:39.680
TLS:ää koskevaan sähköpostitus-
listaan, ihan vasta äskettäin,

00:26:39.680 --> 00:26:44.610
standardointiprosessin loppuvaiheessa,
kun TLS 1.3 oli melkein valmis,

00:26:44.610 --> 00:26:50.800
tämä sähköposti ilmestyi. Ja tämä on
Andrew Kennedyltä, joka työskentelee

00:26:50.800 --> 00:26:56.550
BITS:lle, mikä tarkoittaa pääpiirteittäin,
että hän työskentelee pankeille. Hän sanoo

00:26:56.550 --> 00:27:01.670
"RSA-avaintenvaihdon tuen lopettaminen
TLS 1.3:ssa aiheuttaa suuria ongelmia

00:27:01.670 --> 00:27:06.760
finanssilaitoksille, joista melkein kaikki
käyttävät TLS:ää sisäisesti ja joilla on

00:27:06.760 --> 00:27:12.510
suuria, turvallisuuskriittisiä investoin-
teja ulkopuoliseen TLS-dekryptaamiseen.

00:27:12.510 --> 00:27:17.810
"Ulkopuoliseen (3. osapuolen) TLS-dekryp-
taamiseen" hmm.. (naurua - aplodeja)

00:27:17.810 --> 00:27:23.490
Se todella kuulostaa kriittiseltä...
kriittiseltä jollekin, eikö?

00:27:23.490 --> 00:27:26.140
(naurua - aplodeja)
Eli...

00:27:26.140 --> 00:27:32.200
(naurua)
(aplodeja)

00:27:32.200 --> 00:27:37.039
Yksi valonpilkahduksista oli Kenny 
Patersonin vastaus tähän,

00:27:37.039 --> 00:27:41.680
joka kuului näin: "Minun näkemykseni
pyyntöäsi koskien: ei.

00:27:41.680 --> 00:27:44.920
Perustelu: Yritämme rakentaa TURVALLISEM-
PAA internetiä." Korostus

00:27:44.920 --> 00:27:47.350
on oma lisäykseni, mutta
hän varmasti tarkoitti sitä.

00:27:47.350 --> 00:27:54.100
(aplodeja)

00:27:54.100 --> 00:27:58.840
Tämän jälkeen pankkiväki saapui IETF:ään
ja näytti tämän dian kuvaillakseen, kuinka

00:27:58.840 --> 00:28:04.460
vaikeaa heidän järjestelmänsä
debuggaaminen on. Tämä on yksinkertaista..

00:28:04.460 --> 00:28:09.270
Ilmeisesti pankkiympäristössä. Nuo
ovat eri kytkimiä, reitittimiä,

00:28:09.270 --> 00:28:14.480
väliohjelmistoja, web-sovelluksia
ja kaikki keskustelevat TLS:llä.

00:28:14.480 --> 00:28:19.730
Tämän keskustelun jälkeen
päädyimme kompromissiin.

00:28:19.730 --> 00:28:24.160
Protokollan vaarantamisen
sijaan Matthew Green

00:28:24.160 --> 00:28:28.900
opetti heille, kuinka käyttää Diffie-
Hellmania väärin. Lopulta he kykenivät

00:28:28.900 --> 00:28:33.110
siihen, mitä halusivat ilman,
että me - tai kukaan muu

00:28:33.110 --> 00:28:36.780
akateemisessa yhteisössä tai 
TLS-yhteisössä - palautti

00:28:36.780 --> 00:28:41.720
TLS:ään tämän turvattoman osan.

00:28:41.720 --> 00:28:45.580
Jos haluat lukea tämän, se kertoo
kuinka tähän pystytään. Joka tapauksessa

00:28:45.580 --> 00:28:49.970
- emme laittaneet sitä takaisin.
Kiteytettynä, älkää tehkö näin!

00:28:49.970 --> 00:28:54.300
(aplodeja)

00:28:54.300 --> 00:29:00.100
Eli tapoimme staattisen RSA:n, ja mitä
muuta tapoimme? No, kun katsotaan

00:29:00.100 --> 00:29:03.769
taaksepäin hyötyihin ja haittoihin,
TLS 1.2 käyttää tiettyjä primitiivejä,

00:29:03.769 --> 00:29:08.519
jotka vain eivät ole
kestäneet ajan hammasta.

00:29:08.519 --> 00:29:12.130
RC4 jonosalain. Poissa!
(aplodeja)

00:29:12.130 --> 00:29:14.790
3DES (Triple DES) lohkosalain. Poissa!
(aplodeja)

00:29:14.790 --> 00:29:21.529
MD5, SHA1... molemmat poissa. Yo!
(jatkuvia aplodeja)

00:29:21.529 --> 00:29:26.480
On vielä rakennelmia, jotka...
peruslohkosalainrakennelmia,

00:29:26.480 --> 00:29:31.640
jotka ovat poissa: AES-CBC.
Poissa. RSA-PKCS1-1.5,

00:29:31.640 --> 00:29:36.810
tämä on tiedetty ongelmalliseksi
jo vuodesta 1998, myöskin poissa!

00:29:36.810 --> 00:29:41.770
Myös muita ominaisuuksia, kuten kompressio
ja uudellenneuvottelu, on poistettu.

00:29:41.770 --> 00:29:47.130
Jälkimmäisen korvasi hyvin kevyt "avaimen
päivitys"-mekanismi. Siis TLS 1.3:ssa

00:29:47.130 --> 00:29:52.490
mikään näistä ei läpäissyt hyöty vs.
kompleksisuus -testiä. Ja monet näistä

00:29:52.490 --> 00:29:58.030
haavoittuvuksista, joita saatatte
tunnistaa, ovat mahdottomia TLS 1.3:ssa.

00:29:58.030 --> 00:30:04.010
(aplodeja)

00:30:04.010 --> 00:30:09.149
TLS 1.3:n filosofia monessa kohtaa
on yksinkertaistaa ja lujittaa

00:30:09.149 --> 00:30:14.549
mahdollisimman paljon. Tästä on 
useita pieniä esimerkkitapauksia.

00:30:14.549 --> 00:30:18.680
Osa tämän julkaisun kirjoittajista
saattaa löytyä yleisöstä. Oli tapa

00:30:18.680 --> 00:30:24.030
käytää lohkosalaimia itse 
tallennekerroksella tavalla,

00:30:24.030 --> 00:30:27.640
joka ei ollut niin kestävä kuin se
voisi olla. Se on korvattu paljon

00:30:27.640 --> 00:30:32.340
yksinkertaisemmalla tavalla.
TLS 1.2:ssa oli tällainen

00:30:32.340 --> 00:30:37.520
erikoinen "Catch 22", jossa
salaimen neuvottelua suojaa

00:30:37.520 --> 00:30:41.810
"Finished"-viesti, joka on viestin
autentikointikoodi, mutta

00:30:41.810 --> 00:30:47.020
tuon koodin algoritmi päätettiin
salainneuvottelussa, joten

00:30:47.020 --> 00:30:53.090
siinä oli tällainen takaisinsyöttö-
efekti. Hyökkäykset kuten FREAK, LogJam ja

00:30:53.090 --> 00:30:59.300
CurveSwap onnistuivat hyödyntämään näitä
alentaakseen yhteyksien turvallisuuksia.

00:30:59.300 --> 00:31:02.669
Tätä tapahtui ihan käytännössä.
Syy on, että näitä salausalgoritmien

00:31:02.669 --> 00:31:06.980
joukkoja kättelyssä ei ole
digitaalisesti allekirjoitettu

00:31:06.980 --> 00:31:11.649
yksityisellä vaimella. Tämä muutettiin
TLS 1.3:ssa. Kaikki allekirjoituksen

00:31:11.649 --> 00:31:16.129
yläpuolella oleva on
allekirjoitettu. Tämä on hienoa!

00:31:16.129 --> 00:31:21.290
Mitä muuta muutimme? Tai, mitä
muuta TLS 1.3 muutti verrattuna

00:31:21.290 --> 00:31:27.860
TLS 1.2:een? Vähemmän, mutta parempia
valintoja. Kryptografiassa paremmat

00:31:27.860 --> 00:31:33.410
valinnat tarkoittavat aina vähemmän
valintoja. Nyt on tietyt ehdokkaat

00:31:33.410 --> 00:31:36.920
käyrille ja äärellisille kunnille, joita
voi käyttää. Ei mielivaltaisia palvelimen

00:31:36.920 --> 00:31:41.949
keksimiä DH-ryhmiä, ei mielivaltaisia
käyriä. Ja tämä sopivien parametrien listan

00:31:41.949 --> 00:31:47.940
karsiminen, johtaa siihen
että 1-RTT toimii niin usein.

00:31:47.940 --> 00:31:51.960
Kuten Filippo sanoi,
asiakkaan täytyy arvata

00:31:51.960 --> 00:31:56.540
mitä avaimenmuodostus-
metodeja palvelin tukee,

00:31:56.540 --> 00:32:01.199
ja lähettää sopiva avainosuus. Jos on
olemassa lyhyt lista pelkästään turvallisia

00:32:01.199 --> 00:32:05.599
vaihtoehtoja, tätä tapahtuu
useammin. Eli, kun konfiguroit

00:32:05.599 --> 00:32:10.760
TLS-palvelintasi, se ei enää näytä
monimutkaiselta pikaruokalistalta,

00:32:10.760 --> 00:32:15.690
vaan enemmänkin häämenulta. Ota yksi
jokaisesta kategoriasta ja lopputulos on

00:32:15.690 --> 00:32:21.970
herkullisempikin. Voit tutkia tätä
Wiresharkissakin, sekin on yksinkertaista.

00:32:21.970 --> 00:32:27.800
Salausalgoritmit, laajennukset,
käyrät ja voit jatkaa siitä.

00:32:27.800 --> 00:32:33.301
Filippo: TLS 1.3 korjasi myös
sen, mikä mielestäni oli yksi

00:32:33.301 --> 00:32:37.441
suurimpia suunnitteluvirheitä
TLS 1.2:ssa. Puhuimme siitä,

00:32:37.441 --> 00:32:43.410
miten jatkosuojaus toimii istuntojen
jatkamisessa 1.2:ssa ja 1.3:ssa.

00:32:43.410 --> 00:32:49.199
Mutta TLS 1.2 on vieläkin ongelmallisempi.
TLS 1.2 käärii istuntolippujen

00:32:49.199 --> 00:32:55.679
sisään vanhan yhteyden
varsinaisen pääsalaisuuden.

00:32:55.679 --> 00:33:02.509
Eli se ottaa varsinaiset alkuperäisen yhteyden 
liikenteen salaamiseen käytetyt avaimet,

00:33:02.509 --> 00:33:07.860
salaa ne istuntolipun avaimella, ja
lähettää ne asiakkaalle, jotta se voi

00:33:07.860 --> 00:33:13.619
lähettää ne takaisin ensi kerralla.
Puhuimme riskistä, että hyökkääjä saa

00:33:13.619 --> 00:33:18.139
istuntolipun avaimet haltuunsa,
dekryptaa instuntoliput ja murtaa

00:33:18.139 --> 00:33:23.859
jatkosuojauksen ja
dekryptaa jatketut istunnot.

00:33:23.859 --> 00:33:29.780
TLS 1.2:ssa asiat ovat vielä huonommin.
Jos hyökkääjä dekryptaa istuntoliput, se

00:33:29.780 --> 00:33:35.950
voi takaperoisesti dekryptata
koko alkuperäisen

00:33:35.950 --> 00:33:42.090
jatkamattoman istunnon. Ja
tämä on täysin tarpeetonta.

00:33:42.090 --> 00:33:46.770
Meillä on tiivistefunktioita, yksisuun-
taisia funktioita, joihin laitetaan syöte

00:33:46.770 --> 00:33:52.990
ja saadaan jotain, josta ei päästä
takaisin alkuperäiseen. Näin 1.3 tekee.

00:33:52.990 --> 00:33:58.579
1.3. johtaa uusia, tuoreita avaimia
seuraavaa istuntoa varten

00:33:58.579 --> 00:34:04.090
ja käärii ne istuntolipun sisään, jotta
niistä saadaan PSK. Eli vaikka

00:34:04.090 --> 00:34:09.439
dekryptaisit 1.3 istuntolipun,
voit yrittää murtaa

00:34:09.439 --> 00:34:13.619
seuraavaa yhteyttä ja olemme nähneet,
että saatat pystyä dekryptaamaan

00:34:13.619 --> 00:34:18.949
ainoastaan alkudatan, tai koko yhteyden,
käytetystä moodista riippuen. Mutta

00:34:18.949 --> 00:34:25.959
et mitenkään voi dekryptata alkuperäistä
jatkamattoman istunnon yhteyttä.

00:34:25.959 --> 00:34:31.729
Tämä olisi itsessään riitävän huono asia,
mutta 1.2 tekee toisen päätöksen, joka

00:34:31.729 --> 00:34:36.760
ihmetytti minua. Koko "käytetään pää-
salaisuutta" saataa johtua siitä, että

00:34:36.760 --> 00:34:41.779
istuntoliput olivat pelkkä laajennus 
1.2:ssa, mitä ne eivät ole 1.3:ssa.

00:34:41.779 --> 00:34:47.990
Mutta 1.2 lähettää "New Session
Ticket"-viestin alkuperäisen

00:34:47.990 --> 00:34:53.490
kättelyn alussa
- salaamattomana! Tarkoitan siis,

00:34:53.490 --> 00:34:58.670
salattuna istuntolipun avaimilla, mutta
ei nykyisen istunnon avaimilla.

00:34:58.670 --> 00:35:04.040
Eli mikä tahansa palvelin, joka tukee

00:35:04.040 --> 00:35:10.130
istuntolippuja, tulee kaikkien
yhteyksien alussa - vaikka

00:35:10.130 --> 00:35:14.670
istunnon jatkamista ei ikinä tapahtuisi -
lähettämään istuntolipun, joka ei ole

00:35:14.670 --> 00:35:18.820
muuta kuin sen yhteyden 
hetkelliset (katoavat) avaimet

00:35:18.820 --> 00:35:23.400
käärittynä istuntolipun 
avaimilla. Nyt, jos olet

00:35:23.400 --> 00:35:28.620
Maailmanlaajuinen pahantekijä,
joka haluaa suorittaa

00:35:28.620 --> 00:35:33.060
joukkovalvontaa ja haluaisit 
dekryptata jälkikäteen

00:35:33.060 --> 00:35:38.720
kaikki yhteydet, ja jotenkin saisit
käsiisi istuntolippujen avaimet,

00:35:38.720 --> 00:35:44.350
se mitä löytäisit kaikkien
TLS 1.2-yhteyksien alusta, on

00:35:44.350 --> 00:35:49.830
istuntoavaimet salattuna
istuntolipun avaimilla.

00:35:49.830 --> 00:35:55.580
1.3 ratkaisee tämän ja 1.3:ssa tällaiset
hyökkäykset ovat täysin mahdottomia.

00:35:55.580 --> 00:35:59.420
Ainoa asia, jonka voisit passivisesti,
siis jälkikäteen, dekryptata

00:35:59.420 --> 00:36:04.230
on alkudata. Et mitenkään voisi
dekryptata jatkamattomia yhteyksiä ja

00:36:04.230 --> 00:36:10.920
mitään mikä tulee 0-RTT:n jälkeen.

00:36:10.920 --> 00:36:12.840
Nick: Eli se on turvallisempi.
Lyhyesti sanottuna.

00:36:12.840 --> 00:36:15.710
Filippo: Toivon mukaan!
Nick: ...toivottavasti.

00:36:15.710 --> 00:36:20.670
Ja mistä tiedämme sen olevan turvallisempi?
Nämä turvallisuusparametrit ja turvallisuus-

00:36:20.670 --> 00:36:25.840
vaatimukset koskien TLS:ää on 
formalisoitu ja, toisin kuin aiemmissa

00:36:25.840 --> 00:36:30.310
TLS-versioissa, formalisointia 
harjoittavat akateemikot otettiin

00:36:30.310 --> 00:36:34.170
mukaan aiemmin. Useat julkaisut
ovat analysoineet tilakonetta

00:36:34.170 --> 00:36:40.120
ja TLS 1.3:n eri moodeja, ja
nämä ovat auttaneet paljon

00:36:40.120 --> 00:36:45.360
protokollan kehityksessä.

00:36:45.360 --> 00:36:50.570
Kuka siis oikeastaan kehittää
TLS 1.3:a? No, kyseessä

00:36:50.570 --> 00:36:54.730
on järjestö nimeltä IETF, joka tulee 
sanoista Internet Engineering Taskforce.

00:36:54.730 --> 00:36:59.760
Se on ryhmä vapaaehtoisia, jotka tapaavat
kolmesti vuodessa, joilla on postituslistoja

00:36:59.760 --> 00:37:03.461
ja he väittelevät loputtomasti näistä
protokollista. He määrittelevät internetissä

00:37:03.461 --> 00:37:07.910
käytettävät protokollat. Ja alunperin,
ensimmäinen asia mitä tästä näin - tässä

00:37:07.910 --> 00:37:13.250
on twiittini syyskuulta 2013 - oli
toivomuslista koskien TLS 1.3:a.

00:37:13.250 --> 00:37:19.920
Ja sen jälkeen IETF julkaisi
ensimmäisen version...

00:37:19.920 --> 00:37:24.630
Dokumentit, jotka määrittelevät proto-
kollia tunnetaan nimellä RFC, ja

00:37:24.630 --> 00:37:29.200
ennen kuin jostakin tulee RFC, siitä käy-
tetään nimeä "Internet Draft". Eli

00:37:29.200 --> 00:37:34.330
aloitetaan Internet Draft 0:sta, ja sitä
iteroidaan, kunnes lopulta se joko

00:37:34.330 --> 00:37:39.980
hylätään tai hyväksytään RFC:ksi. Ensim-
mäinen oli siis melkein 3 vuotta sitten

00:37:39.980 --> 00:37:46.080
huhtikuussa 2014, ja nykyinen
luonnos (18), jonka ajatellaan olevan

00:37:46.080 --> 00:37:51.590
melkein valmis, on vaiheessa jota
kutsutaan "Last Call":ksi IETF:ssä,

00:37:51.590 --> 00:37:57.330
julkaistiin vastikään lokakuussa.
Tietoturvallisuusympäristössä tällä

00:37:57.330 --> 00:38:02.400
aikavälillä on nähty todella monia
erilaisia hyökkäyksiä TLS:ää vastaan.

00:38:02.400 --> 00:38:07.860
Esim: Triple Handshake, POODLE, FREAK,
LogJam, DROWN (josta oli esitys aiemmin

00:38:07.860 --> 00:38:12.220
tänään), Lucky Microseconds, SLOTH.
Kaikki nämä eri akronyymit - joista

00:38:12.220 --> 00:38:15.550
ehkä olette tai ette ole kuullut -
ovat tapahtuneet kehitystyön aikana.

00:38:15.550 --> 00:38:21.380
Eli TLS 1.3 on kehittyvä
dokumentti, ja toivottavasti

00:38:21.380 --> 00:38:27.561
siitä tulee lyhyt. Tarkoitan
siis, että TLS 1.2 oli 79 sivua.

00:38:27.561 --> 00:38:32.521
Se on vähän vaikeaselkoinen, mutta lukekaa
toki jos kiinnostaa. TLS 1.3 sen sijaan,

00:38:32.521 --> 00:38:36.330
jos lopusta karsii ylimääräistä tavaraa
pois, tulee aika lähelle. Ja se on

00:38:36.330 --> 00:38:40.980
helppolukuisempi. Se on paljon tarkempi,
vaikka sieltä löytyykin kiinnostavia

00:38:40.980 --> 00:38:46.910
ominaisuuksia kuten 0-RTT istunnon jatka-
minen. Kuinka se käytännössä kirjoitetaan?

00:38:46.910 --> 00:38:52.810
Vastaus on... Github! Ja postituslista!
Eli, jos haluat lähettää pull pyynnön

00:38:52.810 --> 00:38:59.020
tähän TLS-työryhmään, sieltä se löytyy.
Tällä tavoin luonnos oikeasti muotoutuu.

00:38:59.020 --> 00:39:04.190
Ja kannattanee lähettää viesti
postituslistaan, jossa kuvailet

00:39:04.190 --> 00:39:09.300
muutoksiasi, jos haluat. Ehdottaisin,
jos joku haluaa osallistua - nyt on aika

00:39:09.300 --> 00:39:14.190
myöhäistä - onhan se "Last Call"-vaiheessa,
mutta postituslista on vielä avoinna.

00:39:14.190 --> 00:39:18.370
Olen työstänyt tätä useiden muiden
kanssa, Filippo mukaan lukien. Olimme

00:39:18.370 --> 00:39:23.230
osallisina luonnoksessa, työskennelleet
yli vuoden tämän parissa. Voitte käydä

00:39:23.230 --> 00:39:29.230
katsomassa Githubista ongelmat ja
näette, kuinka paljon työtä se on vaatinut.

00:39:29.230 --> 00:39:34.130
Luonnos on muuttunut
vuosien ja kuukausien varrella.

00:39:34.130 --> 00:39:38.620
Esim. luonnos 9:ssä oli tämä
monimutkainen puumalli

00:39:38.620 --> 00:39:43.550
kierrosavaimen laskennalle, tässä
näette "htk"... kaikki nämä eri asiat

00:39:43.550 --> 00:39:49.980
liittyivät TLS-kättelyn eri avaimiin.
Tämän inspiraation lähteenä oli QUIC,

00:39:49.980 --> 00:39:55.650
Googlen protokolla, jonka Filippo mainitsi
aiemmin, sekä julkaisu nimeltä "OPTLS".

00:39:55.650 --> 00:40:00.610
Ja siinä oli useita eri moodeja:
semistaattinen Diffie-Hellman ja tämä

00:40:00.610 --> 00:40:04.950
puumallinen avaintenlaskenta. Ajan 
mittaan tätä pelkistettiin tästä

00:40:04.950 --> 00:40:10.510
monimutkaisesta kaaviosta siihen, mitä
nyt käytämme TLS 1.3:ssa. Joka on hyvin

00:40:10.510 --> 00:40:16.330
yksinkertainen avaimenjohtamisalgoritmi.
Vaati paljon työtä päästä jostain suuresta

00:40:16.330 --> 00:40:21.670
johonkin näin pieneen. Mutta se onnistui!
Muita TLS 1.3:n kanssa sattuneita,

00:40:21.670 --> 00:40:27.230
kryptografisesti vähemmän
merkittäviä asioita, on

00:40:27.230 --> 00:40:32.550
nimeäminen! Jos joku on seurannut
kehitystä, TLS 1.3 ei välttämättä ole

00:40:32.550 --> 00:40:38.180
yksimielinen valinta tämän protokollan
nimeksi. Kuten Filippo mainitsi, 1.0,

00:40:38.180 --> 00:40:44.000
1.1, 1.2 ovat melko pieniä iteraatioita
jopa SSLv3:een verrattuna, kun taas

00:40:44.000 --> 00:40:49.071
TLS 1.3 on aika iso muutos.
Siispä nimelle on paljon

00:40:49.071 --> 00:40:54.950
vaihtoehtoja! Otetaanpa äänestys
kättä nostamalla. Kenen

00:40:54.950 --> 00:40:59.860
mielestä nimen pitäisi olla 1.3?
(nauraa)

00:40:59.860 --> 00:41:02.030
Kiitos Filippo! (Filippo nauraa)
Jep, eli aika suuri osa.

00:41:02.030 --> 00:41:07.840
Entäpä TLS 2? Ketään? Oho. Tämä
näyttää itse asiassa enemmältä kuin...

00:41:07.840 --> 00:41:12.940
Filippo: Muistakaa että SSLv2
on juttu! Ja se on kamala juttu!

00:41:12.940 --> 00:41:18.040
Nick: Ette halua sekoittaa sitä
meihin! No entä sitten TLS 4?

00:41:18.040 --> 00:41:22.520
Edelleen merkittävä osa ihmisiä...
Entäs TLS 2017? Noniin...

00:41:22.520 --> 00:41:25.780
Selvä. TLS 7 ketään? Okei...

00:41:25.780 --> 00:41:30.400
Filippo: TLS Millenium 2019 X?

00:41:30.400 --> 00:41:35.410
Kyllä! Myyty!
Nick: TLS Vista?

00:41:35.410 --> 00:41:38.860
(naurua) - (Nick ja Filippo nauravat)
(aplodeja)

00:41:38.860 --> 00:41:44.800
Nick: Paljon vaihtoehtoja! Mutta ihan
vain muistutuksena, muu maailma ei

00:41:44.800 --> 00:41:50.040
oikeastaan käytä nimeä TLS. Tässä on
Google trends, kiinnostus aikajanalla,

00:41:50.040 --> 00:41:55.300
kun vertaillaan "SSL vs. TLS". SSL on nimi,
jota suuri osa maailmasta käyttää. SSL:n

00:41:55.300 --> 00:42:00.240
korkein versio on versio 3, ja siinä on
syy miksi ihmiset ajattelivat, että

00:42:00.240 --> 00:42:05.210
"TLS 4" on hyvä ajatus. Koska: "Ihmiset
ovat hämillään: 3 on enemmän

00:42:05.210 --> 00:42:10.720
kuin 1.2 jne. jne."

00:42:10.720 --> 00:42:14.870
Tämä äänestys ei ollut ainoa. Tässä
on epävirallisia Twitter-äänestyksiä.

00:42:14.870 --> 00:42:20.030
"Mmm, pekonia!" oli hyvä.
52 % Ryan Hurstin äänestykessä.

00:42:20.030 --> 00:42:23.870
(naurua)

00:42:23.870 --> 00:42:28.130
Versionumerot TLS:ssä
ovat inhottava aihe.

00:42:28.130 --> 00:42:32.780
Esim. olemassa olevat versiot TLS:stä
- jos katsotaan verkon yli kulkevaa tietoa,

00:42:32.780 --> 00:42:37.640
ne eivät täsmää. Eli SSL 3
on 3.0, mikä täsmää.

00:42:37.640 --> 00:42:43.720
Mutta TLS 1 on 3.1, 3.2...
TLS 1.2 on 3.3 ja alun perin

00:42:43.720 --> 00:42:49.000
uskoakseni TLS 1.3:n 
luonnokseen 16 asti se oli 3.4

00:42:49.000 --> 00:42:53.761
Eli ikäänkuin pikkupäivitys
TLS 1.2:een, hyvin hämmentävää.

00:42:53.761 --> 00:42:58.511
Internetmittausten jälkeen pääteltiin,

00:42:58.511 --> 00:43:02.670
että moni palvelin, jos lähetät "Client
Hello":n arvolla "3.4", katkaisee yhteyden.

00:43:02.670 --> 00:43:07.960
Tämä on oikeasti todella huono juttu, se
estää selaimia alentamasta yhteyttä

00:43:07.960 --> 00:43:13.080
turvallisesti. Mitä palvelimen kuuluisi
tehdä, jos se näkee version joka on

00:43:13.080 --> 00:43:18.780
korkeampi kuin 3.3, on vain vastata "3.3"
sanoakseen: "Tämän parempaan en pysty".

00:43:18.780 --> 00:43:24.880
Mutta kävi ilmi, että moni näistä vain
hajoaa. Joten 3.3 on nyt "Client Hello":ssa

00:43:24.880 --> 00:43:30.680
ja 3.4 neuvotellaan aliprotokollana.
Eli tämä on sotkuista.

00:43:30.680 --> 00:43:35.610
Eikö? Mutta punnitsemme hyötyjä moni-
mutkaisuutta vastaan, ja tämä on niitä

00:43:35.610 --> 00:43:39.640
missä palvelimien toimivuus painaa
enemmän kuin lisääntynyt monimutkaisuus,

00:43:39.640 --> 00:43:44.340
jonka tuo uuden asian lisääminen. Ja tämän
estämiseksi tulevaisuudessa

00:43:44.340 --> 00:43:48.820
David Benjamin ehdotti jotain nimeltä
GREASE, missä jokaiseen TLS-neuvottelun

00:43:48.820 --> 00:43:53.920
osaan tulee, asiakkaana, lisätä
jotain satunnaista tavaraa,

00:43:53.920 --> 00:43:56.980
jotta palvelimet tottuvat
näkemään asioita, jotka eivät ole

00:43:56.980 --> 00:44:01.050
versioita, joihin ne ovat tottuneet.
Eli, 0x8a8a. Se on GREASE-d!

00:44:01.050 --> 00:44:06.320
Filippo: Se on ihan todellinen asia!
Se on todellinen hyvin hyödyllinen asia!

00:44:06.320 --> 00:44:08.760
Nick: Tämä tulee olemaan hyvin
hyödyllinen, tulevaisuutta ajatellen,

00:44:08.760 --> 00:44:13.850
estämään tällaisia asioita tapahtumasta.
Mutta on ikävää, että sen täytyi tapahtua.

00:44:13.850 --> 00:44:18.830
Aikamme on käymässä vähiin, mutta
me halusimme todella päästä mukaan

00:44:18.830 --> 00:44:23.430
ja sotkemaan kätemme. Ja yksi asia
mitä IETF rakastaa, kun kehittelee näitä

00:44:23.430 --> 00:44:28.680
standardeja on koodin ajaminen. Joten 
aloitimme IETF 95 Hackathonilla,

00:44:28.680 --> 00:44:32.950
joka pidettiin huhtikuussa ja
onnistuimme lopulta saamaan Firefoxin

00:44:32.950 --> 00:44:37.740
lataamaan Cloudflaren isännöimän
palvelimen TLS 1.3:lla. Tämä oli suuri

00:44:37.740 --> 00:44:43.250
saavutus silloin. Käytimme NSS:ää,
joka on Firefoxin turvallisuuskirjasto ja

00:44:43.250 --> 00:44:48.850
"Mint":iä, joka oli uusi tyhjästä

00:44:48.850 --> 00:44:52.890
rakennettu versio TLS 1.3:sta Go-kielellä.

00:44:52.890 --> 00:44:57.640
Ja lopputulema oli, että se toimi! Mutta
tämä oli ainoastaan konseptitodistus (PoC).

00:44:57.640 --> 00:45:02.950
Filippo: Rakentaaksemme jotain tuotanto-
valmiimpaa, katsoimme TLS-kirjastoa,

00:45:02.950 --> 00:45:08.330
jonka muokkaaminen tuntui meistä 
helpoimmalta. Yllätyksettömästi se

00:45:08.330 --> 00:45:13.370
ei ollut OpenSSL. Joten päätimme

00:45:13.370 --> 00:45:17.990
rakentaa 1.3:n Go:n 
crypto/tls-kirjaston päälle,

00:45:17.990 --> 00:45:24.210
joka löytyy Go:n standardikirjastosta.
Lopputulos on "tls-tris", ja se on

00:45:24.210 --> 00:45:28.500
suora korvaaja crypto/tls:lle ja
se tulee tämän varoituksen

00:45:28.500 --> 00:45:33.970
saattelemana, joka sanoo: "Kaiken hyvän
ja oikeudenmukaisuuden nimessä,

00:45:33.970 --> 00:45:38.990
älä käytä tätä!". Varoitus koski alunperin
kaikkea, mutta nyt se ei enää niinkään

00:45:38.990 --> 00:45:45.190
koske tietoturvaa, auditoitutimme tämän,
mutta se koskee edelleen vakautta.

00:45:45.190 --> 00:45:50.510
Työstämme tämän saamista ylävirtaan,
mikä tulee vakiinnuttamaan API:n.

00:45:50.510 --> 00:45:56.000
Ja voitte seurata ylävirtaprosessia, 
Googlen väki oli ystävällinen ja

00:45:56.000 --> 00:46:00.830
avasi meille oman haaran kehitystyötä
varten, ja se ei varmasti tule osumaan

00:46:00.830 --> 00:46:06.960
seuraavaan Go:n julkaisuun, Go 1.8, mutta
odotamme innolla, että saamme tämän ylävirtaan.

00:46:06.960 --> 00:46:12.010
Joka tapauksessa, vaikka käyttäisit
Go:ta, käyttöönotto on vaikeaa.

00:46:12.010 --> 00:46:17.800
Ensimmäisen kerran kun otimme Tris:n
käyttöön, luonnoksen numero oli 13.

00:46:17.800 --> 00:46:23.630
Ja tukeakseen selaimia tästä
eteenpäin, meidän täytyi tukea

00:46:23.630 --> 00:46:29.140
useita luonnosversioita saman
aikaisesti käyttämällä joskus

00:46:29.140 --> 00:46:34.590
erikoisia yksityiskohtia. Ja joskus meidän
täytyi tukea asioita, jotka eivät todellakaan

00:46:34.590 --> 00:46:40.030
olleet edes luonnoksia, koska selaimet
alkoivat... hajaantua eri suuntiin.

00:46:40.030 --> 00:46:44.970
No, joka tapauksessa meillä
oli testimatriisi, joka ajoi

00:46:44.970 --> 00:46:50.610
kaikki meidän commit:imme kaikkia
asiakaskirjastojen versioita vastaan,

00:46:50.610 --> 00:46:54.980
ja tämä varmisti, että olemme
aina yhteensopivia selainten kanssa.

00:46:54.980 --> 00:47:00.170
Ja nykyään asiakkaat ovat itse asiassa
paljon vakaampia, ja todellakin,

00:47:00.170 --> 00:47:05.050
saatat jopa jo tietämättäsi 
käyttää sitä. Esim. Chrome Beta,

00:47:05.050 --> 00:47:11.160
beta-kanavalla se on päällä noin 50 %:lla
instansseista kokeiluna Googlen puolelta.

00:47:11.160 --> 00:47:16.110
Ja tältä meidän kuvaajamme
näyttivät julkaisun aikaan,

00:47:16.110 --> 00:47:21.560
kun Firefox Nightly laittoi sen oletuksena
päälle ja kun Chrome Canary laittoi sen

00:47:21.560 --> 00:47:26.510
oletuksena päälle. Nykyään meno on
vakaata: noin 700 pyyntöä sekunnissa

00:47:26.510 --> 00:47:30.640
kulkee TLS 1.3:a käyttäen. Ja omalla
puolellamme laitoimme sen

00:47:30.640 --> 00:47:36.230
päälle miljoonille Cloudflaren 
isännöimille sivustoille.

00:47:36.230 --> 00:47:40.830
Ja, kuten sanottua, spesifikaatio
on muuttuva dokumentti

00:47:40.830 --> 00:47:46.080
ja se on kaikille avoin. Sen voi nähdä
Githubissa. Tris implementaatio on siellä

00:47:46.080 --> 00:47:50.860
myös, vaikkakin siinä on tämä pelottava
varoitus, ja tässä blogissa tulemme

00:47:50.860 --> 00:47:56.210
luultavasti julkaisemaan kaiken jatko-
tutkimuksen ja tulokset. Kiitos paljon ja

00:47:56.210 --> 00:47:59.990
jos teillä on kysymyksiä, astukaa esiin,
uskon että meillä on muutama minuutti.

00:47:59.990 --> 00:48:11.770
(aplodeja)

00:48:11.770 --> 00:48:15.690
Herald: Kiitos, meillä on reilusti 
aikaa kysymyksille. Ensimmäinen

00:48:15.690 --> 00:48:19.770
kysymys tulee internetistä.

00:48:19.770 --> 00:48:23.930
Signal Angel: Ensimmäisessä kysymyksessä 
ihmiset kysyvät onko viisasta, että

00:48:23.930 --> 00:48:28.160
päätös 0-RTT:n suhteen menee
sovellukselle, eli se jätetään

00:48:28.160 --> 00:48:32.450
sovelluksen kehittäjille?

00:48:32.450 --> 00:48:34.130
Filippo: (nauraa)
(aplodeja)

00:48:34.130 --> 00:48:40.230
Filippo: Hyvä kysymys. Kuten sanoimme,
tämä tosiaan rikkoo abstraktion.

00:48:40.230 --> 00:48:45.500
Eli se EI ole oletusarvoisesti rikki.
Jos ainoastaan päivität Go:n ja

00:48:45.500 --> 00:48:50.791
saat käyttöösi TLS 1.3:n, et tule
kohtaamaan yhtään 0-RTT:tä,

00:48:50.791 --> 00:48:54.800
koska tosiaan se vaatisi yhteistyötä
sovellukselta. Eli mikäli sovellus ei

00:48:54.800 --> 00:48:59.980
tiedä mitä tekee sen kanssa, se ei
yksinkertaisesti voi käyttää sitä, mutta

00:48:59.980 --> 00:49:06.920
saa kaikki turvallisuushyödyt sekä 1-RTT-
kättelyn hyödyt joka tapauksessa.

00:49:06.920 --> 00:49:09.570
Herald: Selvä, seuraava kysymys
tulee mikrofonista yksi.

00:49:09.570 --> 00:49:12.680
Kysyjä: Protokollan ensimmäisten
testien yhteydessä, oletteko

00:49:12.680 --> 00:49:17.610
saaneet konkreettisia arvoja sille, miltä
nuo suorituskyvyn parannukset näyttävät?

00:49:17.610 --> 00:49:21.170
(Filippo huokaisee)

00:49:21.170 --> 00:49:24.580
Nick: Yhdeltä edestakaiselta matkalta!
(nauraa) Riippuu siitä paljonko 1-RTT on.

00:49:24.580 --> 00:49:28.000
Filippo: Nimenomaan. Yksi edestakainen
matka on... en pysty sanomaan lukua

00:49:28.000 --> 00:49:33.250
koska tietysti, jos asut San Franciscossa,
jossa on nopea kuituyhteys, se on

00:49:33.250 --> 00:49:39.120
mitä? Ehkä 3 millisekuntia? 6...? 
Jos taas asut vaikka jossain maassa,

00:49:39.120 --> 00:49:43.260
missä EDGE on ainoa 
käytettävissä oleva yhteys,

00:49:43.260 --> 00:49:47.700
se on ehkä sekunti. Meillä taitaa
olla keskiarvo, joka on noin... 100

00:49:47.700 --> 00:49:55.100
ja 200 millisekunnin välillä, mutta emme
ole virallisesti mitanneet näitä lukuja.

00:49:55.100 --> 00:49:57.630
Herald: Ok, seuraava kysymys
tulee mikrofonista 3.

00:49:57.630 --> 00:50:01.720
Kysyjä: Yksi huomautus, jonka haluan sanoa
on, että yksi parannus joka saavutettiin

00:50:01.720 --> 00:50:07.350
TLS 1.3:ssa on että asiakas-
varmenteisiin lisättiin salaus.

00:50:07.350 --> 00:50:11.330
Joten asiakasvarmenteet lähetetään
salattuina, mikä on tärkeää, jos

00:50:11.330 --> 00:50:17.670
ajattelee asiakasta, joka liikkuu sekä 
joukkovalvovaa elintä, joka voisi

00:50:17.670 --> 00:50:23.120
jäljittää asiakkaita tällä. Ja toinen
huomio/kysymys, joka saattaisi...

00:50:23.120 --> 00:50:27.080
Herald: Kysymykset päättyvät kysymys-
merkkiin. Joten yritäthän pitää lyhyenä?

00:50:27.080 --> 00:50:31.820
Kysyjä: Kyllä... Tämä saattaa
olla tyhmä kysymys...

00:50:31.820 --> 00:50:36.400
Vakio Diffie-Hellman-ryhmät...
eivätkö ne olleet ongelma LogJam-

00:50:36.400 --> 00:50:42.890
hyökkäyksessä, joten... auttaako
tämä LogJam-hyökkäyksiä vastaan?

00:50:42.890 --> 00:50:46.660
Nick: Viittaatko siihen pankeille
suunnattuun ehdotukseen?

00:50:46.660 --> 00:50:49.590
Kysyjä: Ei ei, yleisesti siihen, 
että voidaan laskea ennakkoon...

00:50:49.590 --> 00:50:54.430
Nick: Aivan, kyllä, eli LogJamin kohdalla
oli ongelma, missä oli DH-ryhmä, joka

00:50:54.430 --> 00:50:57.940
oli oletuksena käytössä monella
eri palvelimella. Apachen käyttämä,

00:50:57.940 --> 00:51:03.800
joka oli 1024 (bittiä).
TLS 1.3:ssa tämä rajoitettiin

00:51:03.800 --> 00:51:09.190
ennalta laskettuun DH-ryhmään,
joka on yli 2000 bittiä pienimmilläänkin,

00:51:09.190 --> 00:51:14.600
ja valtavallakin laskentateholla varustettuna,
jos on 2000 bitin DH ryhmä, ei ole

00:51:14.600 --> 00:51:20.140
käytännössä mahdollista tehdä esilasken-
taa minkäänlaista hyökkäystä varten.

00:51:20.140 --> 00:51:21.990
Mutta kyllä, tuo on hyvä pointti.

00:51:21.990 --> 00:51:24.950
Filippo: ...ja koska ne ovat kiinteitä, ei
ole keinoa pakottaa protokollaa käyttämään

00:51:24.950 --> 00:51:28.940
mitään muuta, joka ei olisi niin vahva.
Kysyjä: Selvä, kiitos!

00:51:28.940 --> 00:51:32.720
Herald: Seuraava kysymys mikrofonista 4.

00:51:32.720 --> 00:51:37.120
Kysyjä: Kiitos esityksestä! 
Tiivistelmässä mainitsitte, että eräs

00:51:37.120 --> 00:51:41.550
toinen lopetettava ominaisuus oli SNI,

00:51:41.550 --> 00:51:45.920
yhdessä 0-RTT:n kanssa, mutta on edelleen
tapoja implementoida se. Voitteko selventää?

00:51:45.920 --> 00:51:49.670
Filippo: Pidimme siis tämän esitelmän
kahdesti sisäisesti, ja tämä kysymys

00:51:49.670 --> 00:51:55.590
esitettiin molemmilla
kerroilla. Joten... (nauraa)

00:51:55.590 --> 00:52:01.790
Eli, SNI on pieni parametri, jonka asiakas
lähettää palvelimelle kertoakseen,

00:52:01.790 --> 00:52:06.210
mille sivustolle se yrittää
yhdistää. Esim. Cloudflarella on

00:52:06.210 --> 00:52:11.250
useita sivustoja koneidemme takana, joten
sinun täytyy kertoa meille "Haluan siis

00:52:11.250 --> 00:52:17.230
oikeasti yhdistää "blog.filippo.io":n. Tämä
on yksityisyyden kannalta ongelmallista,

00:52:17.230 --> 00:52:22.550
koska joku voi pelkästään verkon yli
kulkevista tavuista nähdä, mihin

00:52:22.550 --> 00:52:29.450
nimenomaiseen sivuun yhdistät. Epäonninen
seikka on se, että tässä on sama onglema

00:52:29.450 --> 00:52:35.270
kuin alkudatan jatkosuojauksessa.
SNI lähetetään "Client Hello":ssa, ja

00:52:35.270 --> 00:52:39.620
tässä kohtaa ei ole vielä neuvoteltu
yhtään avainta, joten ei ole mitään millä

00:52:39.620 --> 00:52:44.960
sen voisi salata. Mutta jos ei lähetä
SNI:tä ensimmäisessä viestissä,

00:52:44.960 --> 00:52:49.140
palvelin ei tiedä minkä sertifikaatin
se lähettää, joten se ei voi lähettää

00:52:49.140 --> 00:52:53.050
allekirjoitusta ensimäisessä viestissä,
joten ei ole avaimia. Eli täytyisi tehdä

00:52:53.050 --> 00:52:59.030
2-RTT, ja nyt olisimme taas samassa
pisteessä kuin TLS 1.2. Joten,

00:52:59.030 --> 00:53:03.180
valitettavasti, se ei
toimi 1-RTT kättelyissä.

00:53:03.180 --> 00:53:08.820
Nick: HTTP2:n spesifikaatiossa on kuitenkin
ehdotuksia, jotka mahdollistaisivat multi-

00:53:08.820 --> 00:53:14.210
pleksaamisen. Tämä on vielä työn alla. 
Voisi olla mahdollista yhdistää ensin

00:53:14.210 --> 00:53:19.700
yhteen verkkotunnukseen ja sitten luoda
toinen yhteys olemassa olevan sisällä.

00:53:19.700 --> 00:53:21.950
Ja tämä voisi mahdollisesti
suojata SNI:tä.

00:53:21.950 --> 00:53:25.520
Filippo: Eli joku tarkkailija ajattelisi,
että menet sivulle blog.filippo.io mutta

00:53:25.520 --> 00:53:29.480
kun avaat yhteyden, voisit pyytää
HTTP2:ta näyttämään myös

00:53:29.480 --> 00:53:33.200
"tämän toisen sivun". Kiitos!

00:53:33.200 --> 00:53:38.170
Herald: Selvä, seuraava
kysymys, mikrofoni 7,

00:53:38.170 --> 00:53:41.240
tai itse asiassa 5, pahoittelut.

00:53:41.240 --> 00:53:47.440
Kysyjä: Mainitsitte, että TLS 1.3:sta
on olemassa formaali verifikaatio.

00:53:47.440 --> 00:53:54.350
Millä ohjelmistolla tämä
formaali verifikaatio on tehty?

00:53:54.350 --> 00:53:59.030
Nick: Oli useita ohjelmisto-
implementaatioita ja protokollia...

00:53:59.030 --> 00:54:02.650
Katsotaanpa, jos pääsen
takaisinpäin... tässä.

00:54:02.650 --> 00:54:06.600
Tamarin on ohjelmisto, jonka on
kehittänyt muun muassa Cas Cremers

00:54:06.600 --> 00:54:11.810
Oxfordissa ja Royal Hollowayssa.
miTLS on uskoakseni kirjoitettu F#:lla

00:54:11.810 --> 00:54:18.430
INRIA:n toimesta. Ja nqsb-TLS
on kirjoitettu OCaml:lla.

00:54:18.430 --> 00:54:22.970
Joten useita eri kieliä käytettiin näiden
kehityksessä ja käsittääkseni nqsb-TLS:n

00:54:22.970 --> 00:54:27.490
kehittäjät ovat paikalla...

00:54:27.490 --> 00:54:30.960
Herald: Selvä, seuraava
kysymys mikrofoni 8.

00:54:30.960 --> 00:54:36.440
Kysyjä: Hei! Kiitos. Kiitos 
informatiivisesta esityksestä.

00:54:36.440 --> 00:54:42.690
SSL:n ja TSL:n historia on täynnä "mikä
muka voisi mennä vikaan"-ideoita ja hetkiä,

00:54:42.690 --> 00:54:48.810
jotka lopulta kostautuivat. Joten
kysymykseni, kun otetaan huomioon,

00:54:48.810 --> 00:54:52.740
että on useita pienempiä organisaatioita
tai pienempiä hosting-yrityksiä jne.,

00:54:52.740 --> 00:54:59.600
jotka luultavasti implementoivat 0-RTT:n
väärin. Mikä on ensivaikutelmanne? Kuinka

00:54:59.600 --> 00:55:04.180
todennäköistä on, että tämä todella
tulee kostautumaan pian? Kiitos.

00:55:04.180 --> 00:55:09.990
Filippo: Kuten sanoin, olen itse asiassa
aavistuksen skeptinen vaikutusten suhteen

00:55:09.990 --> 00:55:16.460
koskien HTTP:tä, sillä selaimet saadaan
uudelleenlähettämään pyyntöjä jo nyt.

00:55:16.460 --> 00:55:21.610
Ja olemme nähneet tästä
julkaisuja ja blogipostauksia. Mutta

00:55:21.610 --> 00:55:25.830
kukaan ei kyennyt näyttämään
toteen, että se olisi rikkonut

00:55:25.830 --> 00:55:30.620
suuren osuuden internetistä. Ollakseni
rehellinen, en osaa vastata, kuinka

00:55:30.620 --> 00:55:35.990
pahasti se kostautuu. Mutta muistetaan,
että tasapainon toinen puoli

00:55:35.990 --> 00:55:41.650
on se määrä ihmisiä, jotka sanovat
etteivät aio ottaa TSL:ää käyttöön

00:55:41.650 --> 00:55:45.670
koska se on "hidas". Ei.

00:55:45.670 --> 00:55:51.620
Se on 0-RTT, TLS on nopea!
Menkää ja salatkaa kaikki!

00:55:51.620 --> 00:55:57.940
Siis nuo ovat ne kaksi huolenaihetta, 
jotka täytyy saada tasapainoon.

00:55:57.940 --> 00:56:01.910
Lisäksi, oma henkilökohtainen
mielipiteeni ei paina paljoa.

00:56:01.910 --> 00:56:07.310
Tämä oli päätös, jonka teki koko
postituslistasta koostuva yhteisö.

00:56:07.310 --> 00:56:12.900
Ja voin vakuuttaa, että jokainen on ollut
hyvin konservatiivinen kaiken suhteen,

00:56:12.900 --> 00:56:18.630
ottanut huomioon jopa... niin, senkin
olisiko nimi johtanut ihmisiä harhaan.

00:56:18.630 --> 00:56:23.910
En osaa ennustaa tulevaisuutta. Voin
vain sanoa toivovani, että teimme

00:56:23.910 --> 00:56:28.520
parhaan valinnan tehdäksemme suurimman
osan verkosta niin turvalliseksi kuin voimme.

00:56:28.520 --> 00:56:32.490
Herald: Seuraava kysymys
tulee internetistä.

00:56:32.490 --> 00:56:34.610
Signal Angel, onko meillä vielä
kysymys internetistä?

00:56:34.610 --> 00:56:37.760
Signal Angel: Kyllä meillä on.

00:56:37.760 --> 00:56:43.060
Mitkä ovat suurimmat implementoinnin
yhteensopimattomuudet, jotka on löydetty

00:56:43.060 --> 00:56:45.800
nyt kun lopullinen spesifikaatio
on melko valmis?

00:56:45.800 --> 00:56:47.910
Herald: Voitko toistaa kysymyksen?

00:56:47.910 --> 00:56:53.250
(Signal Angel toistaa kysymyksen)

00:56:53.250 --> 00:56:59.290
Filippo: Okei. Koskien
luonnosteluvaihetta?

00:56:59.290 --> 00:57:03.450
Osa niistä, jotka eivät olleet versio-
yhteensopivia oli, uskoakseni, enimmäkseen

00:57:03.450 --> 00:57:06.750
"middleboxeja" ja palomuureja.

00:57:06.750 --> 00:57:12.690
Nick: Oli joitain todella isoja 
sivustojakin. Paypal taisi olla yksi?

00:57:12.690 --> 00:57:18.310
Filippo: Vaikkakin, prosessin aikana
meillä oli yhteensopivuusongelmia monista

00:57:18.310 --> 00:57:23.540
syistä. Mukaanlukien se, missä
toinen kehittäjistä kirjoitti väärin

00:57:23.540 --> 00:57:28.110
muuttujan numeron.
(nauraa)

00:57:28.110 --> 00:57:32.420
Luonnosten aikana joskus yhteensopivuus
meni rikki, mutta oli myös paljon yhteis-

00:57:32.420 --> 00:57:37.970
työtä asiakasimplementaatioiden ja meidän
puolemme palvelinimplementaatioiden välillä.

00:57:37.970 --> 00:57:44.040
Voin onnekseni todeta, että varsinaisten
1.3 implementaatioiden kanssa tehtiin

00:57:44.040 --> 00:57:50.980
paljon yhteensopivuustestejä, ja kaikki
ongelmat saatiin melko nopeasti korjattua.

00:57:50.980 --> 00:57:54.050
Herald: Okei, seuraava kysymys
tulee mikrofonista numero 1.

00:57:54.050 --> 00:57:59.300
Kysyjä: Minulla on 2 nopeaa kysmystä
koskien istunnon jatkamista.

00:57:59.300 --> 00:58:02.951
Jos palvelimelle tallennetaan jotain
dataa istunnosta, eikö se olisi tavallaan

00:58:02.951 --> 00:58:08.010
jonkinlainen supereväste? Eikö se ole
yksityisyyden kannalta vaarallista?

00:58:08.010 --> 00:58:13.990
Ja toinen kysymys on: entä DNS-
kuormantasaajat tai jotkut muut

00:58:13.990 --> 00:58:21.070
valtavat määrät palvelimia, missä pyynnöt
menevät joka kerta eri palvelimelle?

00:58:21.070 --> 00:58:28.150
Filippo: Ok, eli nämä koskevat yksityiskohtia
istuntolippujen tehokkaasta jakelusta.

00:58:28.150 --> 00:58:32.950
TLS 1.3 ottaa huomioon yksityisyydensuojan
koskien istuntolippuja, ja tosiaan se

00:58:32.950 --> 00:58:37.650
mahdollistaa palvelimen lähettämään useita
istuntolippuja. Palvelin voi siis edelleen

00:58:37.650 --> 00:58:42.470
tietää mikä asiakas sen lähettää, jos niin
haluaa. Mutta kukaan ulkopuolelta yhteyttä

00:58:42.470 --> 00:58:47.460
tarkkaileva ei siihen kykene, koska ne 
lähetetään salattuina, toisin kuin TLS 1.2:ssa

00:58:47.460 --> 00:58:53.171
ja niitä voi olla useita. Kukaan ulko-
puolinen ei pysty yhdistämään sitä

00:58:53.171 --> 00:58:57.600
alkuperäiseen yhteyteen. Tämän parempaan
ei pysty, sillä jos palvelimen ja asiakkaan

00:58:57.600 --> 00:59:02.560
täytyy käyttää uudelleen jotain jaettua
tietoa, palvelimen täytyy saada tietää

00:59:02.560 --> 00:59:08.240
kuka oli kyseessä. Mutta istuntolippuja
ei voi 1.3:ssa jäljittää kolmannen

00:59:08.240 --> 00:59:13.010
osapuolen toimesta. Ja... kun tehdään
kuormantasausta... on eräs mielenkiintoinen

00:59:13.010 --> 00:59:18.750
julkaisu istuntolippujen jakelusta, mutta
olennaista on, että kannattaa varmaan

00:59:18.750 --> 00:59:24.960
selvittää miten asiakkaat liikkuvat
palvelimien välillä ja löytää tasapaino

00:59:24.960 --> 00:59:30.340
sen välillä kannattaako istuntolipun
avain jakaa, jolloin se on tehokkaampaa

00:59:30.340 --> 00:59:35.500
vai jättää istuntolipun avain jakamatta,
jolloin niitä on vaikeampi saada käsiinsä.

00:59:35.500 --> 00:59:41.610
Saattaisit tehdä maantieteellisen
sijainnin mukaan, tai yhden räkin...

00:59:41.610 --> 00:59:44.540
Se riippuu ihan toteutuksesta.

00:59:44.540 --> 00:59:47.480
Herald: Okei, viimeinen
kysymys menee mikrofonille 3.

00:59:47.480 --> 00:59:51.750
Kysyjä: Minulla on kysymys koskien
GREASE-mekanismia, joka toteutetaan

00:59:51.750 --> 00:59:57.110
asiakkaan puolella. Jos
ymmärsin oikein, siinä lisätään

00:59:57.110 --> 01:00:02.350
satunnaisia versionumeroita
olemattomista TLS- tai SSL-versioista

01:00:02.350 --> 01:00:08.640
ja siten koulutetaan
palvelimet mukautumaan

01:00:08.640 --> 01:00:14.480
spesifikaatioon. Mitkä ovat
tosielämän testien tulokset?

01:00:14.480 --> 01:00:18.490
Moniko palvelin menee
tästä oikeasti nurin?

01:00:18.490 --> 01:00:22.780
Filippo: Odotusarvoisesti ei yksikään,
koska ne kaikki ovat nyt ottamassa

01:00:22.780 --> 01:00:28.070
1.3:a käyttöön, joten kaikki asiakkaat,
joita ne kohtaavat käyttäisivät GREASE:a.

01:00:28.070 --> 01:00:33.100
Kuitenkin, juuri kun Google otti GREASE:n
käyttöön luulen sen rikkoneen... En ole

01:00:33.100 --> 01:00:38.330
varma, joten en sano mikä palvelin-
implementaatio, mutta yhden pienemmistä

01:00:38.330 --> 01:00:41.860
tunnistettiin heti olevan... 
se Haskell-kielellä kirjoitettu!

01:00:41.860 --> 01:00:43.890
Nick: Aivan!
Filippo: En muista sen nimeä,

01:00:43.890 --> 01:00:47.450
en osaa lukea Haskellia, joten en
tarkalleen tiedä mitä ne tekivät, mutta

01:00:47.450 --> 01:00:49.590
ne katkaisivat yhteyksiä
GREASE:n takia.

01:00:49.590 --> 01:00:53.480
Nick: Ja huomautuksena, GREASE:a käytetään
myös salausneuvotteluissa ja kaikessa

01:00:53.480 --> 01:00:58.800
mikä on neuvottelu TLS 1.3:ssa.
Tämä tosiaan rikkoi

01:00:58.800 --> 01:01:03.020
pienen osan palvelimista, mutta
sen verran pienen osan,

01:01:03.020 --> 01:01:06.600
että ihmiset hyväksyivät sen.

01:01:06.600 --> 01:01:08.670
Kysyjä: Kiitos!
Nick: 2 % on liikaa!

01:01:08.670 --> 01:01:11.430
Herald: Kiitos oikein paljon.
Filippo: Kiitos!

01:01:11.430 --> 01:01:20.010
(aplodeja)

01:01:20.010 --> 01:01:39.080
(33C3 loppumusiikki)

01:01:39.080 --> 01:01:43.981
Translated by Roope Salminen
(ITKST56 course assignment at JYU.FI)