0:00:00.000,0:00:14.820
Translated by Roope Salminen[br](ITKST56 course assignment at JYU.FI)[br](33C3 intromusiikki)

0:00:14.820,0:00:20.190
Herald: Seuraava esitelmä [br]käsittelee TLS 1.3 käyttöönottoa

0:00:20.190,0:00:23.509
ja sen pitävät Filippo Valsorda [br]sekä Nick Sullivan,

0:00:23.509,0:00:26.989
jotka molemmat [br]työskentelevät Cloudflarelle.

0:00:26.989,0:00:32.110
Joten toivottakaamme lämpimästi [br]tervetulleeksi Nick ja Filippo!

0:00:32.110,0:00:39.490
(aplodeja)

0:00:39.490,0:00:43.820
Filippo: Hei kaikki. Puheen-[br]aiheenamme tänään on TLS 1.3.

0:00:43.820,0:00:48.340
TLS 1.3 on tietenkin uusin versio [br]TLS:stä, joka tulee sanoista

0:00:48.340,0:00:52.960
"Transport Layer Security".[br]Se on ehkä tunnetuin

0:00:52.960,0:00:57.900
vihreästä lukosta selaimessa,[br]tai vanhalta nimestään SSL,

0:00:57.900,0:01:02.510
jota yritämme edelleen[br]tappaa. TLS on

0:01:02.510,0:01:07.890
läpinäkyvä turvallisuusprotokolla,[br]joka voi turvallisesti tunneloida

0:01:07.890,0:01:12.460
mielivaltaista sovellusliikennettä.[br]Sitä käyttävät tietenkin web-selaimet,

0:01:12.460,0:01:16.760
sitä käyttävät sähköpostipalvelimet[br]turvaamaan keskinäistä

0:01:16.760,0:01:22.270
SMTP-liikennettään. Sitä käyttävät [br]Tor-solmut keskinäiseen kommunikointiinsa.

0:01:22.270,0:01:26.810
Mutta... Se kehittyi yli 20 vuoden ajan,

0:01:26.810,0:01:31.320
mutta pohjimmiltaan se koskee asiakasta[br]ja palvelinta, jotka haluavat kommunikoida

0:01:31.320,0:01:36.119
turvallisesti verkon yli.[br]Kommunikoidakseen turvallisesti verkon yli

0:01:36.119,0:01:41.170
niiden täytyy luoda avainmateriaalia,[br]sopia keskenään avainmateriaalista

0:01:41.170,0:01:47.349
molemmin puolin salatakseen[br]tulevan liikenteen.

0:01:47.349,0:01:51.989
Se, miten avainmateriaalista sovitaan,[br]hoidetaan vaiheessa, jota kutsumme

0:01:51.989,0:01:57.890
"kättelyksi". Kättelyssä on mukana[br]julkisen avaimen kryptografiaa ja

0:01:57.890,0:02:02.670
dataa, jota lapioidaan asiakkaalta[br]palvelimelle, palvelimelta asiakkaalle.

0:02:02.670,0:02:07.170
Tältä kättely näyttää TLS 1.2:ssa.

0:02:07.170,0:02:12.790
Asiakas aloittaa tanssit[br]lähettämällä "Client Hello"-viestin,

0:02:12.790,0:02:18.960
jossa kertoo, mitä tuettuja[br]parametreja se voi käyttää.

0:02:18.960,0:02:23.430
Palvelin vastaanottaa sen ja[br]lähettää oman viestinsä, joka on

0:02:23.430,0:02:28.200
"Server Hello", joka sanoo "Selvä![br]Käytetään tätä salausalgoritmien yhdistelmää,

0:02:28.200,0:02:33.230
jota sanot tukevasi, ja tässä on minun[br]avainosuuteni käytettäväksi

0:02:33.230,0:02:39.270
tässä avaintenvaihtoalgoritmissa.[br]Lisäksi, tässä on varmenne,

0:02:39.270,0:02:45.300
jonka on allekirjoittanut auktoriteetti,[br]joka todistaa, että todellakin olen

0:02:45.300,0:02:50.370
Cloudflare.com. Ja tässä on allekirjoitus [br]varmenteesta todistamaan, että tämä

0:02:50.370,0:02:55.450
avainosuus on todellakin se, jota haluan [br]sinun käyttävän avainten luomiseen."

0:02:55.450,0:03:00.940
Asiakas vastaanottaa sen ja generoi[br]oman avainosuutensa, eli oman puolensa

0:03:00.940,0:03:06.200
Diffie-Hellman avaintenvaihdosta,[br]ja lähettää avainosuuden sekä

0:03:06.200,0:03:10.999
viestin kertoakseen: "Se oli siinä.[br]Kättely on nyt paketissa".

0:03:10.999,0:03:15.490
Tätä kutsutaan "Finished" viestiksi.[br]Palvelin vastaanottaa sen, luo

0:03:15.490,0:03:20.679
oman "Finished" viestinsä[br]ja vastaa sillä. Eli

0:03:20.679,0:03:25.930
nyt voimme vihdoin lähettää sovellusdataa. [br]Kerrataanpa vielä prosessi:

0:03:25.930,0:03:30.022
Asiakas -> Palvelin, Palvelin -> Asiakas;[br]Asiakas -> Palvelin, Palvelin -> Asiakas.

0:03:30.022,0:03:34.960
Meidän täytyi tehdä 2 edestakaista matkaa [br]asiakkaan ja palvelimen välillä ennen

0:03:34.960,0:03:40.730
mitään muuta. Emme ole lähettäneet [br]tavuakaan sovelluskerroksella

0:03:40.730,0:03:46.010
ennen tätä. Tämä tietenkin [br]matkapuhelinverkoissa

0:03:46.010,0:03:50.539
tai tietyissä osissa[br]maailmaa voi kerryttää

0:03:50.539,0:03:55.320
satojen millisekuntien viiveen. [br]Ja tämä täytyy tehdä

0:03:55.320,0:04:00.930
joka kerta, kun uutta yhteyttä avataan.[br]Joka kerta asiakkaan ja palvelimen

0:04:00.930,0:04:06.490
täytyy kulkea kahdesti välinsä[br]luodakseen avaimet ennen

0:04:06.490,0:04:12.730
kuin yhteyttä voi oikeasti[br]käyttää. TLS 1.1

0:04:12.730,0:04:17.950
ja 1.0 eivät eronneet suuresti [br]1.2:sta. Voisikin kysyä: "Miksi sitten

0:04:17.950,0:04:23.750
pitää kokonainen esitys TLS 1.3:sta,[br]joka on luultavasti vain taas yksi

0:04:23.750,0:04:31.430
iteraatio samasta konseptista?" No, [br]TLS 1.3 on oikeasti iso uudelleensuunnittelu.

0:04:31.430,0:04:36.740
Erityisesti kättely on restukturoitu. [br]Ja tämän näkyvin tulos

0:04:36.740,0:04:43.139
on se, että yksi kokonainen [br]edestakainen matka on karsittu pois.

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

0:04:48.929,0:04:53.479
Kuinka 1.3 poistaa edestakaisen matkan?[br]Miten se pystyy siihen? Se kykenee siihen

0:04:53.479,0:04:59.799
ennustamalla, mitä [br]avaintenvaihtoalgoritmia

0:04:59.799,0:05:04.740
palvelin tulee käyttämään, ja[br]lähettämällä ennakkoon avainosuuden

0:05:04.740,0:05:10.029
tuota algoritmia varten palvelimelle.[br]Eli ensimmäisessä viestissä meillä oli

0:05:10.029,0:05:15.529
"Client Hello", tuetut parametrit[br]ja avainosuus algoritmille,

0:05:15.529,0:05:21.549
josta asiakas uskoo palvelimen pitävän.[br]Palvelin vastaanottaa viestin

0:05:21.549,0:05:27.239
ja jos kaikki menee hyvin, se ajattelee:[br]"Ah! Okei! Tykkään tästä avainosuudesta.

0:05:27.239,0:05:32.789
Tässä on oma avainosuuteni samaa[br]algoritmia varten, ja tässä muut

0:05:32.789,0:05:37.719
parametrit, joita meidän tulisi käyttää."[br]Se välittömästi sekoittaa avainosuudet

0:05:37.719,0:05:42.319
saadakseen jaetun yhteisen avaimen, koska[br]nyt sillä on molemmat avainosuudet -

0:05:42.319,0:05:47.089
asiakkaan ja palvelimen - ja lähettää[br]taas varmenteen ja allekirjoituksen

0:05:47.089,0:05:51.339
varmenteesta, ja sitten välittömästi[br]lähettää "Finished"-viestin, koska

0:05:51.339,0:05:56.339
se ei tarvitse mitään muuta asiakkaalta. [br]Asiakas vastaanottaa tuon, ottaa

0:05:56.339,0:06:02.020
avainosuuden, luo jaetun yhteisen avaimen [br]ja lähettää oman "Finished" viestinsä,

0:06:02.020,0:06:07.009
ja on valmis lähettämään sitä sovellus-[br]dataa, jota olikaan lähettämässä.

0:06:07.009,0:06:12.650
Esimerkiksi HTTP-pyynnön.[br]Nyt prosessi meni näin:

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

0:06:15.919,0:06:21.330
Ja olemme valmiita lähettämään[br]sovelluskerroksen dataa. Eli, jos olit

0:06:21.330,0:06:27.239
avaamassa HTTPS-yhteyttä, selaimesi

0:06:27.239,0:06:32.769
ei tarvitse odottaa nelinkertaista viivettä, [br]nelinkertaista pingiä. Sen täytyy

0:06:32.769,0:06:38.929
odottaa vain kaksinkertainen, ja tämä[br]tietysti säästää satoja millisekunteja

0:06:38.929,0:06:46.199
viivettä kun avataan uusia yhteyksiä.[br]Tämä oli onnellinen tapaus.

0:06:46.199,0:06:52.299
Näin käy, kun ennustus osuu oikeaan[br]ja palvelin tykkää asiakkaan

0:06:52.299,0:06:58.449
avainosuudesta. Jos palvelin[br]ei tue avainosuutta, jonka

0:06:58.449,0:07:05.169
asiakas lähetti, se lähettää kohteliaan[br]pyynnön käyttää jotain toista algoritmiä,

0:07:05.169,0:07:10.530
jota asiakas sanoi tukevansa. Tätä viestiä[br]kutsutaan nimellä "Hello Retry Request".

0:07:10.530,0:07:16.469
Siinä on eväste, joten se voi olla tilaton[br]mutta periaatteessa se on varakeino,

0:07:16.469,0:07:21.970
jolla palataan käytännössä TLS 1.2-[br]kaltaiseen kättelyyn. Eikä se ole kovin

0:07:21.970,0:07:26.939
vaikea toteuttaa, koska asiakas jatkaa[br]uudella "Client Hello":lla, joka näyttää

0:07:26.939,0:07:34.489
periaattessa täysin samalta kuin[br]täysin tuorekin. Nyt...

0:07:34.489,0:07:42.179
Tässä kohtaa olen valehdellut. TLS 1.2[br]ei aina ole 2 edestakaista matkaa.

0:07:42.179,0:07:47.779
Suurin osa yhteyksistä, joita näemme [br]esimerkiksi Cloudflaren reunalta ovat

0:07:47.779,0:07:53.299
istunnon jatkamisia. Eli asiakas on ollut[br]yhteydessä k.o. sivustolle aiemmin.

0:07:53.299,0:07:59.079
Ja voimme käyttää tätä, voimme hyödyntää[br]tätä ja tehdä kättelystä nopeamman.

0:07:59.079,0:08:06.290
Tämä tarkoittaa, että asiakas muistaa[br]jotain avainmateriaalista, jotta pystyy

0:08:06.290,0:08:10.959
avaamaan seuraavan yhteyden vain yhdellä[br]edestakaisella matkalla myös TLS 1.2:ssa.

0:08:10.959,0:08:16.019
Eli tältä se näyttää. Tässä on normaali[br]TLS 1.2:n täysi kahden edestakaisen

0:08:16.019,0:08:22.479
matkan yhteys. Ja tässä palvelin lähettää[br]lipun uutta istuntoa varten. Istuntolippu

0:08:22.479,0:08:30.029
ei ole sen kummempi kuin salattu[br]kapseloitu blob sisältäen avainmateriaalia,

0:08:30.029,0:08:35.100
jonka asiakas säilyttää. Istuntolippu on[br]salattu ja allekirjoitettu avaimella,

0:08:35.100,0:08:40.039
jonka vain palvelin tietää. Eli se on[br]täysin läpinäkymätön asiakkaalle.

0:08:40.039,0:08:45.040
Mutta asiakas säilyttää sen sekä[br]yhteyden avainmateriaalin,

0:08:45.040,0:08:49.340
jotta seuraavan kerran kun se avaa[br]yhteyttä samalle sivustolle

0:08:49.340,0:08:54.439
se lähettää "Client Hello":n[br]ja istuntolipun.

0:08:54.439,0:08:59.180
Jos palvelin tunnistaa istuntolipun, se[br]purkaa sen salauksen ja löytää sisältä

0:08:59.180,0:09:04.090
avainmateriaalin. Ja nyt, vain yhden edes-[br]takaisen matkan jälkeen, palvelimella on

0:09:04.090,0:09:09.820
yhteistä avainmateriaalia asiakkaan kanssa[br]koska asiakas säilytti sen viime kerrasta

0:09:09.820,0:09:15.460
ja palvelin juuri purki sen [br]salatusta istuntolipusta.

0:09:15.460,0:09:20.890
Ok? Eli nyt palvelimella on jo käytet-[br]tävissä yhteisiä jaettuja avaimia ja se

0:09:20.890,0:09:26.150
lähettää "Finished" viestin ja asiakas [br]vastaa "Finished" viestillä ja pyynnöllä.

0:09:26.150,0:09:31.550
Eli tämä on TLS 1.2. Tätä tapahtuu[br]jo nyt joka päivä useimpien

0:09:31.550,0:09:37.380
modernien TLS-yhteyksien kanssa.

0:09:37.380,0:09:43.530
TLS 1.3-istunnon jatkaminen ei ole kovin[br]erilainen. Siinäkin on istuntolipun käsite

0:09:43.530,0:09:48.300
Istuntolipun sisällön nimi on muutettu[br]"PSK":ksi, mutta se tulee vain sanoista

0:09:48.300,0:09:53.220
"Pre-shared Key", koska sitähän se on:[br]pelkkää avainmateriaalia, josta

0:09:53.220,0:09:58.480
oli sovittu aiemmin.[br]Ja se toimii samalla tavalla:

0:09:58.480,0:10:02.830
palvelin vastaanottaa istuntolipun,[br]purkaa salauksen ja hyppää

0:10:02.830,0:10:07.450
"Finished" viestiin. Nyt...

0:10:07.450,0:10:13.070
Ongelma istunnon jatkamisessa on se,[br]että jos hyökkääjällä on hallussaan

0:10:13.070,0:10:17.130
istuntolipun avain - eli avain, jota [br]palvelin käyttää salamaan istuntolipun,

0:10:17.130,0:10:21.540
jonka sisällä avainmateriaali on -

0:10:21.540,0:10:27.050
hyökkääjä voi passiivisesti, tai jopa[br]tulevaisuudessa kaapatun yhteyden

0:10:27.050,0:10:33.460
tapauksessa, purkaa istuntolipun[br]"Client Hello":sta, löytää sieltä PSK:n

0:10:33.460,0:10:38.320
ja käyttää sitä purkamaan koko loppu-[br]yhteyden salauksen. Tämä ei ole hyvä.

0:10:38.320,0:10:42.519
Tämä tarkoittaa, että joku voi[br]passiivisesti purkaa salauksen

0:10:42.519,0:10:47.819
hallinnoimalla istuntolipun avainta.[br]Tähän vastataan yleensä sanomalla, että

0:10:47.819,0:10:52.540
Lippujen avaimet vanhenevat nopeasti.[br]Mutta eikö olisi mukavaa, jos meidän ei

0:10:52.540,0:10:56.270
tarvitsisi luottaa siihen. Ja on itse[br]asiassa julkaisuja, jotka kertovat meille

0:10:56.270,0:11:01.310
että toteutukset eivät aina[br]tee tuota oikein. Siispä,

0:11:01.310,0:11:07.050
TLS 1.3 sen sijaan mahdollistaa[br]Diffie-Hellmanin käytön

0:11:07.050,0:11:11.760
istunnon jatkamisessa. 1.2:ssa[br]ei ollut keinoja suojautua istunto-

0:11:11.760,0:11:16.720
lipun avaimen murtamisen[br]seurauksilta. 1.3:ssa voi sen sijaan

0:11:16.720,0:11:21.409
lähettää avainosuuden[br]osana "Client Hello":ta

0:11:21.409,0:11:25.499
ja palvelin lähettää avainosuuden [br]"Server Hello":n yhteydessä,

0:11:25.499,0:11:31.710
ja osapuolet suorittavat Diffie-Hellmanin.[br]Diffie-Hellmania käytettiin

0:11:31.710,0:11:36.009
jatkosuojauksen toteuttamiseen esimerkiksi[br]sen varalta, että varmenteen yksityinen

0:11:36.009,0:11:41.339
avain joutuisi vääriin käsiin 1.2:ssa, ja [br]tässä sitä käytetään jatkosuojauksen

0:11:41.339,0:11:46.290
toteuttamiseen istunnon jatkamisessa.[br]Nyt, saatatte miettiä:

0:11:46.290,0:11:51.240
"Tämä näyttää periaatteessa[br]normaalilta 1.3 kättelyltä,

0:11:51.240,0:11:55.770
mikä virka PSK:lla on ylipäätään?"[br]Tästäpä puuttuukin jotakin.

0:11:55.770,0:11:59.510
Varmennetta ei ole. Koska ei ole [br]tarvetta autentikoida uudelleen

0:11:59.510,0:12:04.620
varmenteen avulla, koska asiakas ja [br]palvelin juttelivat aiemmin, joten

0:12:04.620,0:12:09.099
asiakas tietää tarkistaneensa jo[br]palvelimen varmenteen,

0:12:09.099,0:12:12.819
ja mikäli palvelin pystyy purkamaan[br]istuntolipun salauksen, se tarkoittaa,

0:12:12.819,0:12:17.879
että palvelin on se joksi itseään väittää.[br]Joten kaksi avainosuutta yhdistetään.

0:12:17.879,0:12:22.860
Sitten yhdistetään PSK:n kanssa, jotta[br]saadaan avain, jolla salataan loput

0:12:22.860,0:12:29.580
yhteydestä. On olemassa vielä [br]yksi uusi ominaisuus, jonka

0:12:29.580,0:12:34.701
TLS 1.3 istunnon jatkaminen tuo[br]mukanaan. Se on se seikka, että se

0:12:34.701,0:12:40.830
mahdollistaa kättelyn ilman edestakaista[br]matkaa (0-RTT). Muistutuksena,

0:12:40.830,0:12:47.280
kaikki kättelyt 1.3:ssa koostuvat enim-[br]mäkseen yhdestä edestakaisesta matkasta.

0:12:47.280,0:12:52.140
TSL 1.2 istunnon jatkamiset voivat olla[br]minimissään yhden edestakaisen matkan.

0:12:52.140,0:12:58.331
TLS 1.3 istunnon jatkamiset voivat toimia[br]ilman edestakaista matkaa. Kuinka 0-RTT

0:12:58.331,0:13:04.210
kättely toimii? Ajatellaanpa. [br]Alkuun on PSK.

0:13:04.210,0:13:10.119
Pre-shared Key.[br]Asiakas voi käyttää sitä salaamaan

0:13:10.119,0:13:15.680
tämän alkudatan, jonka haluaa lähettää[br]palvelimelle. Joten asiakas avaa

0:13:15.680,0:13:20.439
yhteyden palvelimeen, johon[br]on jo aiemmin ollut yhteydessä,

0:13:20.439,0:13:25.349
ja lähettää "Client Hello":n, [br]istuntolipun,

0:13:25.349,0:13:29.920
avainosuuden Diffie-Hellmaniin ja [br]alkudatan. Alkudata on

0:13:29.920,0:13:34.410
blob sovellusdataa - se voi olla[br]esimerkiksi HTTP-pyyntö -

0:13:34.410,0:13:39.409
salattuna PSK:lla.[br]Palvelin vastaanottaa tämän,

0:13:39.409,0:13:45.369
purkaa istuntolipun, löytää PSK:n,[br]käyttää PSK:ta purkamaan

0:13:45.369,0:13:50.770
alkudatan ja jatkaa sitten normaalisti:[br]yhdistää avainosuudet, lisää PSK:n,

0:13:50.770,0:13:55.270
luo uuden avaimen lopulle[br]yhteydelle ja jatkaa yhteyttä.

0:13:55.270,0:14:00.289
Eli mitä tässä tapahtui? Voimme lähettää[br]sovellusdataa välittömästi yhteyden

0:14:00.289,0:14:05.339
avaamisen yhteydessä. Tämä tarkoittaa,[br]että poistimme suorituskyvyn

0:14:05.339,0:14:11.320
yleiskustannukset TLS:ssä.

0:14:11.320,0:14:16.460
0-RTT kättelyissä on kuitenkin kaksi[br]vaaran paikkaa, jotka ovat teoriassa

0:14:16.460,0:14:22.540
mahdoton poistaa. Yksi on se, että [br]se kiva asia joka tuli PSK ECDHE moodin

0:14:22.540,0:14:27.829
mukana, se jossa käytetään Diffie-[br]Hellmania istunnon jatkamiseen

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

0:14:33.040,0:14:38.620
Käytämme Diffie-Hellmania kun[br]saavumme dian vihreään laatikkoon.

0:14:38.620,0:14:44.000
Tietysti alkudata on salattu vain [br]PSK:lla. Mietitäänpä taas

0:14:44.000,0:14:49.150
hyökkääjää. Hyökkääjä jollain keinolla[br]varasti istuntolippumme salausavaimet.

0:14:49.150,0:14:54.969
Se voi katsoa "Client Hello":a, purkaa [br]istuntolipun, saada PSK:n,

0:14:54.969,0:15:00.029
käyttää PSK:ta purkamaan[br]alkudatan salauksen.

0:15:00.029,0:15:05.350
Se voi tehdä tämän kaapatustakin liiken-[br]teestä, jos saa istuntolipun myöhemmin.

0:15:05.350,0:15:11.519
Siispä alkudata ei ole jatkosuojattu[br]istuntolipun avainten suhteen.

0:15:11.519,0:15:16.679
Pelkkä PSK on kuitenkin hyödytön, jos [br]käytämme Diffie-Hellmania palvelimen

0:15:16.679,0:15:23.020
vastauksessa. Se on hyödyllinen ainoastaan[br]asiakkaan ensimmäisen viestin kohdalla.

0:15:23.020,0:15:28.340
Kerrataanpa. Tässä on[br]paljon asiaa. TLS 1.2 toi

0:15:28.340,0:15:33.379
jatkosuojauksen sen varalle, että[br]varmenteen yksityinen avain

0:15:33.379,0:15:39.119
joutuisi vääriin käsiin, jo kauan sitten[br]käyttämällä ECDHE moodeja.

0:15:39.119,0:15:45.030
Siis 1.2 yhteydet voivat olla aina jatko-[br]suojattuja varmenteen murtamisen

0:15:45.030,0:15:50.300
varalta. TLS 1.3 toimii samoin.

0:15:50.300,0:15:55.090
Ei ole moodia, joka olisi jatkosuojaamaton[br]varmenteen murtamisen varalta.

0:15:55.090,0:16:01.279
Mutta, jos ajatellaan mitä[br]istuntolipun avaimelle voi käydä:

0:16:01.279,0:16:06.000
TLS 1.2 ei koskaan tarjoa jatkosuojausta.

0:16:06.000,0:16:11.149
TLS 1.2:ssa istuntolipun avaimen[br]murtaminen johtaa aina kykyyn passiivisesti

0:16:11.149,0:16:15.819
murtaa tulevien jatkettujen[br]istuntojen salaus.

0:16:15.819,0:16:22.689
1.3:ssa sen sijaan, jos käytämme[br]PSK ECDHE:tä, ainoastaan alkudatan salaus

0:16:22.689,0:16:28.270
voidaan purkaa käyttämällä[br]pelkästään istuntolipun avainta.

0:16:28.270,0:16:33.199
Kuten sanoin, vaaran paikkoja on kaksi.

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

0:16:39.329,0:16:45.449
Olkoon tilanne tämä: alkudata[br]sisältää dataa, joka on jollain tapaa

0:16:45.449,0:16:51.709
autentikoitu. Se voi olla HTTP-[br]pyyntö, joka sisältää evästeitä.

0:16:51.709,0:16:58.070
Tuo HTTP-pyyntö jollain[br]tapaa suorittaa transaktion,

0:16:58.070,0:17:03.150
okei? Ehkä se on tilisiirto. Ohjeistaa[br]palvelinta tekemään jotain. Hyökkääjä

0:17:03.150,0:17:07.580
haluaa toistaa tuota tapahtumaa. Se ei[br]tietenkään voi purkaa sen salausta

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

0:17:13.149,0:17:17.689
muokata sitä, koska se on TLS-suojattu.[br]Mutta se voi kaapata salatun

0:17:17.689,0:17:23.069
viestin ja lähettää sen uudelleen

0:17:23.069,0:17:27.900
palvelimelle. Jos palvelimia on yksi,[br]tähän on helppo ratkaisu.

0:17:27.900,0:17:32.520
Pidä kirjaa nähdyistä viesteistä[br]ja ajattele kutakuinkin näin:

0:17:32.520,0:17:37.500
"Ei. Tämä näyttää täsmälleen samalta kuin[br]mitä sain aiemmin." Mutta jos esimerkiksi,

0:17:37.500,0:17:42.270
kuten Cloudflare, pyörität useita data-[br]keskuksia ympäri maailmaa, et voi pitää

0:17:42.270,0:17:47.650
yhdenmukaisia tiloja jatkuvasti, reaali-[br]ajassa, kaikkien koneiden välillä. Olisi

0:17:47.650,0:17:52.370
eri koneita, jotka tämän viestin[br]saatuaan ajattelisivat näin:

0:17:52.370,0:17:57.530
"Toki, minulla on istuntolipun avain,[br]dekryptaan PSK:n, käytän PSK:ta,

0:17:57.530,0:18:02.080
dekryptaan alkudatan, löydän sieltä jotain[br]ja suoritan sen mitä se käskee minun

0:18:02.080,0:18:07.510
tehdä." Tämä ei tietenkään ole suotavaa.

0:18:07.510,0:18:13.010
Yksi TLS.n tarjoama vastatoimi on,[br]että asiakas lähettää samassa

0:18:13.010,0:18:18.689
paketissa arvon, joka kertoo[br]millisekunteina, kuinka kauan sitten sain

0:18:18.689,0:18:23.790
haltuuni istuntolipun. Palvelin katsoo[br]sitä arvoa, ja jos se ei täsmää

0:18:23.790,0:18:29.080
sen omaan näkemykseen tästä [br]tiedosta, se hylkää viestin.

0:18:29.080,0:18:34.020
Tämä tarkoittaa, että jos hyökkääjä[br]kaappaa viestin ja 10 s myöhemmin

0:18:34.020,0:18:40.000
yrittää toistohyökkäystä, ajat eivät[br]täsmää ja palvelin hylkää viestin.

0:18:40.000,0:18:44.510
Tämä ei kuitenkaan ole täysi ratkaisu,[br]sillä tarpeeksi nopea hyökkääjä voi

0:18:44.510,0:18:50.369
silti tehdä toistohyökkäyksiä.[br]Eli, palvelin voi ainoastaan joko

0:18:50.369,0:18:55.970
hyväksyä 0-RTT datan[br]tai hylätä sen.

0:18:55.970,0:19:00.570
Se ei voi vain ottaa jotain osaa siitä tai[br]kurkistaa siihen ja päättää sitten, koska

0:19:00.570,0:19:05.540
"Server Hello"-viesti kertoo (asiakkaalle)[br]hyväksyttiinkö vai hylättiinkö se.

0:19:05.540,0:19:09.759
Ja asiakas jatkaa alkudatan lähettämistä[br]kunnes se saa "Server Hello"-viestin.

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

0:19:15.960,0:19:20.990
vai hylkäänkö sen kaiken?" Jos se ottaa[br]sen, ja sitten huomaa sen olevan jotain

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

0:19:26.750,0:19:32.470
siirtämään rahaa. En voi tehdä tätä, jos[br]en tiedä ettei tämä ole toistohyökkäys."

0:19:32.470,0:19:37.060
Palvelimen täytyy saada jonkinlainen[br]vahvistus. Hyvä uutinen on se, että jos

0:19:37.060,0:19:40.600
palvelin odottaa "Finished" [br]viestiä... Palvelin lähettää

0:19:40.600,0:19:45.280
"Server Hello":n, "Finished":n ja [br]odottaa asiakkaan vastaavaa.

0:19:45.280,0:19:51.050
Kun asiakkaan oma saapuu, se tarkoittaa,[br]ettei kyseessä ollut toistohyökkäys,

0:19:51.050,0:19:54.950
sillä tuo "Finished" viesti [br]viimeistelee koko kättelyn

0:19:54.950,0:19:59.769
yhdessä tietyn satunnaisarvon kanssa,[br]jonka palvelin lähetti. Kyseessä ei siis

0:19:59.769,0:20:04.380
voi olla toistohyökkäys. Eli nämä ovat[br]palvelimen vaihtoehdot: se voi hyväksyä

0:20:04.380,0:20:08.780
alkudatan ja jos se on jotain mikä[br]ei ole idempotenttia, jotain mikä on

0:20:08.780,0:20:14.610
vaarallista jos se toistetaan, se voi[br]yksinkertaisesti odottaa vahvistusta.

0:20:14.610,0:20:18.850
Mutta se tarkoittaa, että se on laitettava[br]välimuistiin, ja tässä on riski, mikäli

0:20:18.850,0:20:25.580
hyökkääjä lähettää HTTP POST:n valtavalla [br]rungolla tarkoituksenaan täyttää muisti.

0:20:25.580,0:20:31.840
Tajusimme voivamme auttaa tässä,[br]jos kirjoitamme istuntolippuihin,

0:20:31.840,0:20:37.240
mikä on maksimimäärä alkudataa,[br]jonka asiakas voi lähettää.

0:20:37.240,0:20:41.500
Jos huomaamme jonkun lähettävän enemmän,[br]kyseessä on hyökkääjä ja

0:20:41.500,0:20:47.499
katkaisemme yhteyden, tyhjennämme[br]välimuistin vapauttaaksemme muistia.

0:20:47.499,0:20:52.969
Mutta. Joka tapauksessa. Vastatoimista [br]huolimatta, ellemme pysty pitämään

0:20:52.969,0:20:58.780
yhtenäistä maailmanlaajuista tilaa [br]palvelimien välillä, meidän täytyy kertoa

0:20:58.780,0:21:03.429
sovellukselle toistohyökkäyksen mahdol-[br]lisuudesta. Spesifikaatio tietää tämän.

0:21:03.429,0:21:08.150
TLS 1.3 spesifikaatio YKSISELITTEISESTI toteaa

0:21:08.150,0:21:14.420
protokollien EI tule käyttää [br]0-RTT:tä ilman profiilia, joka

0:21:14.420,0:21:19.159
määrittelee sen käytön. Eli tarkoittaa[br]"tietämättä mitä ne ovat tekemässä".

0:21:19.159,0:21:24.419
Tämä tarkoittaa, että TLS-pinon APIen[br]täytyy tehdä oletuksena 1-RTT,

0:21:24.419,0:21:30.360
johon toistohyökkäykset eivät[br]toimi, ja sitten antaa palvelimen

0:21:30.360,0:21:35.571
kutsua joitakin API:a hylätäkseen [br]tai odottaakseen vahvistusta,

0:21:35.571,0:21:41.470
ja antaa asiakkaan päättää, mitä tähän[br]vaaralliseen toistohyökkäysalttiiseen

0:21:41.470,0:21:46.040
dataan tulee. Tämä riippuu

0:21:46.040,0:21:49.840
protokollasta, mutta entäpä [br]lempiprotokollamme? Entäpä

0:21:49.840,0:21:55.329
HTTP? HTTP:n pitäisi olla[br]helppo. HTTP-spesifikaatio,

0:21:55.329,0:22:00.759
käykää vaikka lukemassa, sanoo:[br]"GET-pyynnöt ovat idempotentteja,

0:22:00.759,0:22:06.149
niiden ei tule muuttaa mitään palveli-[br]mella". Selvä! Sallimme nyt ainoastaan

0:22:06.149,0:22:10.670
GET-pyynnöt alkudatassa, koska niitä ei[br]voi hyödyntää toistohyökkäyksissä!

0:22:10.670,0:22:16.640
Jes! Ei. Internetissä on [br]takuuvarmasti palvelin,

0:22:16.640,0:22:23.020
jossa on jotain sen kaltaista kuin[br]“send-money.php?to=filippo&amount=this”

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

0:22:28.870,0:22:33.510
ja sitten käyttää tätä toistohyök-[br]käyksessä toista palvelinta vastaan, se

0:22:33.510,0:22:38.780
suoritetaan kahdesti.[br]Ja se ei käy päinsä.

0:22:38.780,0:22:43.300
Mitä siis voidaan tehdä?

0:22:43.300,0:22:46.890
Teemme kompromisseja!

0:22:46.890,0:22:51.779
Jos tunntet sovelluksesi, voit tehdä hyvin[br]spesifejä kompromisseja. Esimerkiksi

0:22:51.779,0:22:57.020
Google on ajanut QUIC:iä[br]0-RTT:llä hyvinkin pitkään.

0:22:57.020,0:23:02.200
Uskoakseni 3 vuotta? Se tarkoittaa, että[br]he tuntevat sovelluksensa oikein hyvin.

0:23:02.200,0:23:07.419
Ja he tietävät, ettei heillä ole[br]"send-money.php" päätepisteitä.

0:23:07.419,0:23:12.710
Mutta jos olet kuin Cloudflare, joka[br]hallinnnoi suurta määrää sovelluksia,

0:23:12.710,0:23:17.720
et voi tehdä noin laajoja olettamuksia,[br]ja täytyy sen sijaan yrittää

0:23:17.720,0:23:22.570
löytää kultainen keskitie. Me [br]saattaisimme esimerkiksi päättää

0:23:22.570,0:23:28.730
sallia GET-pyynnöt ainoastaan[br]juurihakemistoon. Eli "GET /",

0:23:28.730,0:23:33.200
mikä saattaisi tuoda eniten hyötyä, sillä[br]ehkä suurin osa yhteyksistä alkaa noin,

0:23:33.200,0:23:38.710
ja se on vähiten todennäköinen[br]aiheuttamaan hankaluuksia.

0:23:38.710,0:23:43.140
Mietimme edelleen kuinka sovellamme[br]tätä sovelluksiin. Eli jos tiedossasi

0:23:43.140,0:23:48.199
on sovellus, joka tulisi kärsimään [br]jostain noin yksinkertaisesta,

0:23:48.199,0:23:53.840
lähetä meille sähköpostia. Mutta [br]itse asiassa, jos sinulla on noin

0:23:53.840,0:23:59.160
haavoittuvainen sovellus, minulla[br]on huonoja uutisia. Thai Duong et. al.

0:23:59.160,0:24:04.150
osoittivat, että tämän päivän selaimet,[br]ilman TLS 1.3:a tai muutakaan,

0:24:04.150,0:24:09.740
toistavat HTTP-pyyntöjä[br]verkkovirheiden sattuessa.

0:24:09.740,0:24:15.670
Ja ne toistavat ne hiljaisesti.[br]Eli lopputulema ei välttämättä ole

0:24:15.670,0:24:21.990
huonompi kuin nykytila. Selvä.[br]Näen, että kaikki alkavat olla

0:24:21.990,0:24:27.959
levottomia ja ajattelevat[br]"Kryptografit ovat taas asialla!

0:24:27.959,0:24:32.740
He tekevät tarvitsemastamme turvallisuus-[br]protokollasta tarpeettoman monimutkaisen

0:24:32.740,0:24:38.889
turvatakseen työpaikkansa[br]seuraavaksi 15 vuodeksi!" Eikö?

0:24:38.889,0:24:44.479
Ei. Ei. Voin itseasiassa taata, että

0:24:44.479,0:24:49.709
yksi suurista muutoksista, mielestäni[br]suurempi kuin edestakaiset matkat 1.3:ssa,

0:24:49.709,0:24:54.770
on, että kaikkea punnitaan saadun hyödyn[br]ja sen aiheuttaman monimutkaisuuden

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

0:24:59.180,0:25:02.630
valtaosa ei päässyt.

0:25:02.630,0:25:07.890
Nick: Selvä. Kiitos Filippo. Toimiiko[br]mikrofonini? Kuuletteko minut? Selvä.

0:25:07.890,0:25:13.640
TLS 1.3:n ollessa iteraatio TLS:stä[br]mekin katsoimme taaksepäin, tai,

0:25:13.640,0:25:18.120
"me", jotka olemme ihmiset jotka tutkivat[br]TLS:ää, katsoimme taaksepäin ja

0:25:18.120,0:25:22.770
kertasimme olemassa olevia TLS 1.2:n omi-[br]naisuuksia, jotka vaikuttivat järkeviltä

0:25:22.770,0:25:27.439
aikanaan ja päätimme, oliko kompleksisuus[br]tai vaara, jonka nämä TLS:n ominaisuudet tai

0:25:27.439,0:25:32.349
protokollat tai primitiivit toivat mukanaan

0:25:32.349,0:25:37.739
järkeviä säilyttää. Ja yksi iso,[br]joka sattui prosessin alussa on

0:25:37.739,0:25:43.790
"staattinen RSA" moodi. Näin TLS on[br]toiminut SSL:n ajoista lähtien.

0:25:43.790,0:25:48.179
Sen sijaan, että käytettäisiin Diffie-[br]Hellmania yhteisen avaimen luontiin,

0:25:48.179,0:25:52.320
asiakas luo oman jaetun avaimensa, ja [br]salaa sen palvelimen varmenteen

0:25:52.320,0:25:56.570
julkisella avaimella, joka on[br]RSA-avain, ja lähettää sen sitten

0:25:56.570,0:26:00.770
sellaisenaan palvelimelle. Ja[br]palvelin sitten käyttää omaa

0:26:00.770,0:26:04.650
yksityistä avaintaan purkamaan salauksen[br]ja löytää yhteisen avaimen. Eli asiakas

0:26:04.650,0:26:09.710
luo kaiken avainmateriaalin tässä[br]tapauksessa. Yksi asia on melko selvä

0:26:09.710,0:26:13.650
tässä on, että jos varmenteen[br]yksityinen avain murretaan,

0:26:13.650,0:26:18.149
vaikka vuosiakin myöhemmin, joku[br]jolla on tallenteet tapahtumista voi

0:26:18.149,0:26:23.480
mennä taaksepäin ja purkaa tämän avain-[br]materiaalin ja siten koko keskustelun.

0:26:23.480,0:26:28.419
Tämä poistettiin ihan TLS 1.3-prosessin[br]alkuvaiheessa, noin kaksi vuotta sitten.

0:26:28.419,0:26:33.919
Joten suureksi yllätykseksemme,[br]ja kaikkien, jotka kuuluvat

0:26:33.919,0:26:39.680
TLS:ää koskevaan sähköpostitus-[br]listaan, ihan vasta äskettäin,

0:26:39.680,0:26:44.610
standardointiprosessin loppuvaiheessa,[br]kun TLS 1.3 oli melkein valmis,

0:26:44.610,0:26:50.800
tämä sähköposti ilmestyi. Ja tämä on[br]Andrew Kennedyltä, joka työskentelee

0:26:50.800,0:26:56.550
BITS:lle, mikä tarkoittaa pääpiirteittäin,[br]että hän työskentelee pankeille. Hän sanoo

0:26:56.550,0:27:01.670
"RSA-avaintenvaihdon tuen lopettaminen[br]TLS 1.3:ssa aiheuttaa suuria ongelmia

0:27:01.670,0:27:06.760
finanssilaitoksille, joista melkein kaikki[br]käyttävät TLS:ää sisäisesti ja joilla on

0:27:06.760,0:27:12.510
suuria, turvallisuuskriittisiä investoin-[br]teja ulkopuoliseen TLS-dekryptaamiseen.

0:27:12.510,0:27:17.810
"Ulkopuoliseen (3. osapuolen) TLS-dekryp-[br]taamiseen" hmm.. (naurua - aplodeja)

0:27:17.810,0:27:23.490
Se todella kuulostaa kriittiseltä...[br]kriittiseltä jollekin, eikö?

0:27:23.490,0:27:26.140
(naurua - aplodeja)[br]Eli...

0:27:26.140,0:27:32.200
(naurua)[br](aplodeja)

0:27:32.200,0:27:37.039
Yksi valonpilkahduksista oli Kenny [br]Patersonin vastaus tähän,

0:27:37.039,0:27:41.680
joka kuului näin: "Minun näkemykseni[br]pyyntöäsi koskien: ei.

0:27:41.680,0:27:44.920
Perustelu: Yritämme rakentaa TURVALLISEM-[br]PAA internetiä." Korostus

0:27:44.920,0:27:47.350
on oma lisäykseni, mutta[br]hän varmasti tarkoitti sitä.

0:27:47.350,0:27:54.100
(aplodeja)

0:27:54.100,0:27:58.840
Tämän jälkeen pankkiväki saapui IETF:ään[br]ja näytti tämän dian kuvaillakseen, kuinka

0:27:58.840,0:28:04.460
vaikeaa heidän järjestelmänsä[br]debuggaaminen on. Tämä on yksinkertaista..

0:28:04.460,0:28:09.270
Ilmeisesti pankkiympäristössä. Nuo[br]ovat eri kytkimiä, reitittimiä,

0:28:09.270,0:28:14.480
väliohjelmistoja, web-sovelluksia[br]ja kaikki keskustelevat TLS:llä.

0:28:14.480,0:28:19.730
Tämän keskustelun jälkeen[br]päädyimme kompromissiin.

0:28:19.730,0:28:24.160
Protokollan vaarantamisen[br]sijaan Matthew Green

0:28:24.160,0:28:28.900
opetti heille, kuinka käyttää Diffie-[br]Hellmania väärin. Lopulta he kykenivät

0:28:28.900,0:28:33.110
siihen, mitä halusivat ilman,[br]että me - tai kukaan muu

0:28:33.110,0:28:36.780
akateemisessa yhteisössä tai [br]TLS-yhteisössä - palautti

0:28:36.780,0:28:41.720
TLS:ään tämän turvattoman osan.

0:28:41.720,0:28:45.580
Jos haluat lukea tämän, se kertoo[br]kuinka tähän pystytään. Joka tapauksessa

0:28:45.580,0:28:49.970
- emme laittaneet sitä takaisin.[br]Kiteytettynä, älkää tehkö näin!

0:28:49.970,0:28:54.300
(aplodeja)

0:28:54.300,0:29:00.100
Eli tapoimme staattisen RSA:n, ja mitä[br]muuta tapoimme? No, kun katsotaan

0:29:00.100,0:29:03.769
taaksepäin hyötyihin ja haittoihin,[br]TLS 1.2 käyttää tiettyjä primitiivejä,

0:29:03.769,0:29:08.519
jotka vain eivät ole[br]kestäneet ajan hammasta.

0:29:08.519,0:29:12.130
RC4 jonosalain. Poissa![br](aplodeja)

0:29:12.130,0:29:14.790
3DES (Triple DES) lohkosalain. Poissa![br](aplodeja)

0:29:14.790,0:29:21.529
MD5, SHA1... molemmat poissa. Yo![br](jatkuvia aplodeja)

0:29:21.529,0:29:26.480
On vielä rakennelmia, jotka...[br]peruslohkosalainrakennelmia,

0:29:26.480,0:29:31.640
jotka ovat poissa: AES-CBC.[br]Poissa. RSA-PKCS1-1.5,

0:29:31.640,0:29:36.810
tämä on tiedetty ongelmalliseksi[br]jo vuodesta 1998, myöskin poissa!

0:29:36.810,0:29:41.770
Myös muita ominaisuuksia, kuten kompressio[br]ja uudellenneuvottelu, on poistettu.

0:29:41.770,0:29:47.130
Jälkimmäisen korvasi hyvin kevyt "avaimen[br]päivitys"-mekanismi. Siis TLS 1.3:ssa

0:29:47.130,0:29:52.490
mikään näistä ei läpäissyt hyöty vs.[br]kompleksisuus -testiä. Ja monet näistä

0:29:52.490,0:29:58.030
haavoittuvuksista, joita saatatte[br]tunnistaa, ovat mahdottomia TLS 1.3:ssa.

0:29:58.030,0:30:04.010
(aplodeja)

0:30:04.010,0:30:09.149
TLS 1.3:n filosofia monessa kohtaa[br]on yksinkertaistaa ja lujittaa

0:30:09.149,0:30:14.549
mahdollisimman paljon. Tästä on [br]useita pieniä esimerkkitapauksia.

0:30:14.549,0:30:18.680
Osa tämän julkaisun kirjoittajista[br]saattaa löytyä yleisöstä. Oli tapa

0:30:18.680,0:30:24.030
käytää lohkosalaimia itse [br]tallennekerroksella tavalla,

0:30:24.030,0:30:27.640
joka ei ollut niin kestävä kuin se[br]voisi olla. Se on korvattu paljon

0:30:27.640,0:30:32.340
yksinkertaisemmalla tavalla.[br]TLS 1.2:ssa oli tällainen

0:30:32.340,0:30:37.520
erikoinen "Catch 22", jossa[br]salaimen neuvottelua suojaa

0:30:37.520,0:30:41.810
"Finished"-viesti, joka on viestin[br]autentikointikoodi, mutta

0:30:41.810,0:30:47.020
tuon koodin algoritmi päätettiin[br]salainneuvottelussa, joten

0:30:47.020,0:30:53.090
siinä oli tällainen takaisinsyöttö-[br]efekti. Hyökkäykset kuten FREAK, LogJam ja

0:30:53.090,0:30:59.300
CurveSwap onnistuivat hyödyntämään näitä[br]alentaakseen yhteyksien turvallisuuksia.

0:30:59.300,0:31:02.669
Tätä tapahtui ihan käytännössä.[br]Syy on, että näitä salausalgoritmien

0:31:02.669,0:31:06.980
joukkoja kättelyssä ei ole[br]digitaalisesti allekirjoitettu

0:31:06.980,0:31:11.649
yksityisellä vaimella. Tämä muutettiin[br]TLS 1.3:ssa. Kaikki allekirjoituksen

0:31:11.649,0:31:16.129
yläpuolella oleva on[br]allekirjoitettu. Tämä on hienoa!

0:31:16.129,0:31:21.290
Mitä muuta muutimme? Tai, mitä[br]muuta TLS 1.3 muutti verrattuna

0:31:21.290,0:31:27.860
TLS 1.2:een? Vähemmän, mutta parempia[br]valintoja. Kryptografiassa paremmat

0:31:27.860,0:31:33.410
valinnat tarkoittavat aina vähemmän[br]valintoja. Nyt on tietyt ehdokkaat

0:31:33.410,0:31:36.920
käyrille ja äärellisille kunnille, joita[br]voi käyttää. Ei mielivaltaisia palvelimen

0:31:36.920,0:31:41.949
keksimiä DH-ryhmiä, ei mielivaltaisia[br]käyriä. Ja tämä sopivien parametrien listan

0:31:41.949,0:31:47.940
karsiminen, johtaa siihen[br]että 1-RTT toimii niin usein.

0:31:47.940,0:31:51.960
Kuten Filippo sanoi,[br]asiakkaan täytyy arvata

0:31:51.960,0:31:56.540
mitä avaimenmuodostus-[br]metodeja palvelin tukee,

0:31:56.540,0:32:01.199
ja lähettää sopiva avainosuus. Jos on[br]olemassa lyhyt lista pelkästään turvallisia

0:32:01.199,0:32:05.599
vaihtoehtoja, tätä tapahtuu[br]useammin. Eli, kun konfiguroit

0:32:05.599,0:32:10.760
TLS-palvelintasi, se ei enää näytä[br]monimutkaiselta pikaruokalistalta,

0:32:10.760,0:32:15.690
vaan enemmänkin häämenulta. Ota yksi[br]jokaisesta kategoriasta ja lopputulos on

0:32:15.690,0:32:21.970
herkullisempikin. Voit tutkia tätä[br]Wiresharkissakin, sekin on yksinkertaista.

0:32:21.970,0:32:27.800
Salausalgoritmit, laajennukset,[br]käyrät ja voit jatkaa siitä.

0:32:27.800,0:32:33.301
Filippo: TLS 1.3 korjasi myös[br]sen, mikä mielestäni oli yksi

0:32:33.301,0:32:37.441
suurimpia suunnitteluvirheitä[br]TLS 1.2:ssa. Puhuimme siitä,

0:32:37.441,0:32:43.410
miten jatkosuojaus toimii istuntojen[br]jatkamisessa 1.2:ssa ja 1.3:ssa.

0:32:43.410,0:32:49.199
Mutta TLS 1.2 on vieläkin ongelmallisempi.[br]TLS 1.2 käärii istuntolippujen

0:32:49.199,0:32:55.679
sisään vanhan yhteyden[br]varsinaisen pääsalaisuuden.

0:32:55.679,0:33:02.509
Eli se ottaa varsinaiset alkuperäisen yhteyden [br]liikenteen salaamiseen käytetyt avaimet,

0:33:02.509,0:33:07.860
salaa ne istuntotlipun avaimella, ja[br]lähettää ne asiakkaalle, jotta se voi

0:33:07.860,0:33:13.619
lähettää ne takaisin ensi kerralla.[br]Puhuimme riskistä, että hyökkääjä saa

0:33:13.619,0:33:18.139
istuntolipun avaimet haltuunsa,[br]dekryptaa instuntoliput ja murtaa

0:33:18.139,0:33:23.859
jatkosuojauksen ja[br]dekryptaa jatketut istunnot.

0:33:23.859,0:33:29.780
TLS 1.2:ssa asiat ovat vielä huonommin.[br]Jos hyökkääjä dekryptaa istuntoliput, se

0:33:29.780,0:33:35.950
voi takaperoisesti dekryptata[br]koko alkuperäisen

0:33:35.950,0:33:42.090
jatkamattoman istunnon. Ja[br]tämä on täysin tarpeetonta.

0:33:42.090,0:33:46.770
Meillä on tiivistefunktioita, yksisuun-[br]taisia funktioita, joihin laitetaan syöte

0:33:46.770,0:33:52.990
ja saadaan jotain, josta ei päästä[br]takaisin alkuperäiseen. Näin 1.3 tekee.

0:33:52.990,0:33:58.579
1.3. johtaa uusia, tuoreita avaimia[br]seuraavaa istuntoa varten

0:33:58.579,0:34:04.090
ja käärii ne istuntolipun sisään, jotta[br]niistä saadaan PSK. Eli vaikka

0:34:04.090,0:34:09.439
dekryptaisit 1.3 istuntolipun,[br]voit yrittää murtaa

0:34:09.439,0:34:13.619
seuraavaa yhteyttä ja olemme nähneet,[br]että saatat pystyä dekryptaamaan

0:34:13.619,0:34:18.949
ainoastaan alkudatan, tai koko yhteyden,[br]käytetystä moodista riippuen. Mutta

0:34:18.949,0:34:25.959
et mitenkään voi dekryptata alkuperäistä[br]jatkamattoman istunnon yhteyttä.

0:34:25.959,0:34:31.729
Tämä olisi itsessään riitävän huono asia,[br]mutta 1.2 tekee toisen päätöksen, joka

0:34:31.729,0:34:36.760
ihmetytti minua. Koko "käytetään pää-[br]salaisuutta" saataa johtua siitä, että

0:34:36.760,0:34:41.779
istuntoliput olivat pelkkä laajennus [br]1.2:ssa, mitä ne eivät ole 1.3:ssa.

0:34:41.779,0:34:47.990
Mutta 1.2 lähettää "New Session[br]Ticket"-viestin alkuperäisen

0:34:47.990,0:34:53.490
kättelyn alussa[br]- salaamattomana! Tarkoitan siis,

0:34:53.490,0:34:58.670
salattuna istuntolipun avaimilla, mutta[br]ei nykyisen istunnon avaimilla.

0:34:58.670,0:35:04.040
Eli mikä tahansa palvelin, joka tukee

0:35:04.040,0:35:10.130
istuntolippuja, tulee kaikkien[br]yhteyksien alussa - vaikka

0:35:10.130,0:35:14.670
istunnon jatkamista ei ikinä tapahtuisi -[br]lähettämään istuntolipun, joka ei ole

0:35:14.670,0:35:18.820
muuta kuin sen yhteyden [br]hetkelliset (katoavat) avaimet

0:35:18.820,0:35:23.400
käärittynä istuntolipun [br]avaimilla. Nyt, jos olet

0:35:23.400,0:35:28.620
Maailmanlaajuinen pahantekijä,[br]joka haluaa suorittaa

0:35:28.620,0:35:33.060
joukkovalvontaa ja haluaisit [br]dekryptata jälkikäteen

0:35:33.060,0:35:38.720
kaikki yhteydet, ja jotenkin saisit[br]käsiisi istuntolippujen avaimet,

0:35:38.720,0:35:44.350
se mitä löytäisit kaikkien[br]TLS 1.2-yhteyksien alusta, on

0:35:44.350,0:35:49.830
istuntoavaimet salattuna[br]istuntolipun avaimilla.

0:35:49.830,0:35:55.580
1.3 ratkaisee tämän ja 1.3:ssa tällaiset[br]hyökkäykset ovat täysin mahdottomia.

0:35:55.580,0:35:59.420
Ainoa asia, jonka voisit passivisesti,[br]siis jälkikäteen, dekryptata

0:35:59.420,0:36:04.230
on alkudata. Et mitenkään voisi[br]dekryptata jatkamattomia yhteyksiä ja

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

0:36:10.920,0:36:12.840
Nick: Eli se on turvallisempi.[br]Lyhyesti sanottuna.

0:36:12.840,0:36:15.710
Filippo: Toivon mukaan![br]Nick: ...toivottavasti.

0:36:15.710,0:36:20.670
Ja mistä tiedämme sen olevan turvallisempi?[br]Nämä turvallisuusparametrit ja turvallisuus-

0:36:20.670,0:36:25.840
vaatimukset koskien TLS:ää on [br]formalisoitu ja, toisin kuin aiemmissa

0:36:25.840,0:36:30.310
TLS-versioissa, formalisointia [br]harjoittavat akateemikot otettiin

0:36:30.310,0:36:34.170
mukaan aiemmin. Useat julkaisut[br]ovat analysoineet tilakonetta

0:36:34.170,0:36:40.120
ja TLS 1.3:n eri moodeja, ja[br]nämä ovat auttaneet paljon

0:36:40.120,0:36:45.360
protokollan kehityksessä.

0:36:45.360,0:36:50.570
Kuka siis oikeastaan kehittää[br]TLS 1.3:a? No, kyseessä

0:36:50.570,0:36:54.730
on järjestö nimeltä IETF, joka tulee [br]sanoista Internet Engineering Taskforce.

0:36:54.730,0:36:59.760
Se on ryhmä vapaaehtoisia, jotka tapaavat[br]kolmesti vuodessa, joilla on postituslistoja

0:36:59.760,0:37:03.461
ja he väittelevät loputtomasti näistä[br]protokollista. He määrittelevät internetissä

0:37:03.461,0:37:07.910
käytettävät protokollat. Ja alunperin,[br]ensimmäinen asia mitä tästä näin - tässä

0:37:07.910,0:37:13.250
on twiittini syyskuulta 2013 - oli[br]toivomuslista koskien TLS 1.3:a.

0:37:13.250,0:37:19.920
Ja sen jälkeen IETF julkaisi[br]ensimmäisen version...

0:37:19.920,0:37:24.630
Dokumentit, jotka määrittelevät proto-[br]kollia tunnetaan nimellä RFC, ja

0:37:24.630,0:37:29.200
ennen kuin jostakin tulee RFC, siitä käy-[br]tetään nimeä "Internet Draft". Eli

0:37:29.200,0:37:34.330
aloitetaan Internet Draft 0:sta, ja sitä[br]iteroidaan, kunnes lopulta se joko

0:37:34.330,0:37:39.980
hylätään tai hyväksytään RFC:ksi. Ensim-[br]mäinen oli siis melkein 3 vuotta sitten

0:37:39.980,0:37:46.080
huhtikuussa 2014, ja nykyinen[br]luonnos (18), jonka ajatellaan olevan

0:37:46.080,0:37:51.590
melkein valmis, on vaiheessa jota[br]kutsutaan "Last Call":ksi IETF:ssä,

0:37:51.590,0:37:57.330
julkaistiin vastikään lokakuussa.[br]Tietoturvallisuusympäristössä tällä

0:37:57.330,0:38:02.400
aikavälillä on nähty todella monia[br]erilaisia hyökkäyksiä TLS:ää vastaan.

0:38:02.400,0:38:07.860
Esim: Triple Handshake, POODLE, FREAK,[br]LogJam, DROWN (josta oli esitys aiemmin

0:38:07.860,0:38:12.220
tänään), Lucky Microseconds, SLOTH.[br]Kaikki nämä eri akronyymit - joista

0:38:12.220,0:38:15.550
ehkä olette tai ette ole kuullut -[br]ovat tapahtuneet kehitystyön aikana.

0:38:15.550,0:38:21.380
Eli TLS 1.3 on kehittyvä[br]dokumentti, ja toivottavasti

0:38:21.380,0:38:27.561
siitä tulee lyhyt. Tarkoitan[br]siis, että TLS 1.2 oli 79 sivua.

0:38:27.561,0:38:32.521
Se on vähän vaikeaselkoinen, mutta lukekaa[br]toki jos kiinnostaa. TLS 1.3 sen sijaan,

0:38:32.521,0:38:36.330
jos lopusta karsii ylimääräistä tavaraa[br]pois, tulee aika lähelle. Ja se on

0:38:36.330,0:38:40.980
helppolukuisempi. Se on paljon tarkempi,[br]vaikka sieltä löytyykin kiinnostavia

0:38:40.980,0:38:46.910
ominaisuuksia kuten 0-RTT istunnon jatka-[br]minen. Kuinka se käytännössä kirjoitetaan?

0:38:46.910,0:38:52.810
Vastaus on... Github! Ja postituslista![br]Eli, jos haluat lähettää pull pyynnön

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

0:38:59.020,0:39:04.190
Ja kannattanee lähettää viesti[br]postituslistaan, jossa kuvailet

0:39:04.190,0:39:09.300
muutoksiasi, jos haluat. Ehdottaisin,[br]jos joku haluaa osallistua - nyt on aika

0:39:09.300,0:39:14.190
myöhäistä - onhan se "Last Call"-vaiheessa,[br]mutta postituslista on vielä avoinna.

0:39:14.190,0:39:18.370
Olen työstänyt tätä useiden muiden[br]kanssa, Filippo mukaan lukien. Olimme

0:39:18.370,0:39:23.230
osallisina luonnoksessa, työskennelleet[br]yli vuoden tämän parissa. Voitte käydä

0:39:23.230,0:39:29.230
katsomassa Githubista ongelmat ja[br]näette, kuinka paljon työtä se on vaatinut.

0:39:29.230,0:39:34.130
Luonnos on muuttunut[br]vuosien ja kuukausien varrella.

0:39:34.130,0:39:38.620
Esim. luonnos 9:ssä oli tämä[br]monimutkainen puumalli

0:39:38.620,0:39:43.550
kierrosavaimen laskennalle, tässä[br]näette "htk"... kaikki nämä eri asiat

0:39:43.550,0:39:49.980
liittyivät TLS-kättelyn eri avaimiin.[br]Tämän inspiraation lähteenä oli QUIC,

0:39:49.980,0:39:55.650
Googlen protokolla, jonka Filippo mainitsi[br]aiemmin, sekä julkaisu nimeltä "OPTLS".

0:39:55.650,0:40:00.610
Ja siinä oli useita eri moodeja:[br]semistaattinen Diffie-Hellman ja tämä

0:40:00.610,0:40:04.950
puumallinen avaintenlaskenta. Ajan [br]mittaan tätä pelkistettiin tästä

0:40:04.950,0:40:10.510
monimutkaisesta kaaviosta siihen, mitä[br]nyt käytämme TLS 1.3:ssa. Joka on hyvin

0:40:10.510,0:40:16.330
yksinkertainen avaimenjohtamisalgoritmi.[br]Vaati paljon työtä päästä jostain suuresta

0:40:16.330,0:40:21.670
johonkin näin pieneen. Mutta se onnistui![br]Muita TLS 1.3:n kanssa sattuneita,

0:40:21.670,0:40:27.230
kryptografisesti vähemmän[br]merkittäviä asioita, on

0:40:27.230,0:40:32.550
nimeäminen! Jos joku on seurannut[br]kehitystä, TLS 1.3 ei välttämättä ole

0:40:32.550,0:40:38.180
yksimielinen valinta tämän protokollan[br]nimeksi. Kuten Filippo mainitsi, 1.0,

0:40:38.180,0:40:44.000
1.1, 1.2 ovat melko pieniä iteraatioita[br]jopa SSLv3:een verrattuna, kun taas

0:40:44.000,0:40:49.071
TLS 1.3 on aika iso muutos.[br]Siispä nimelle on paljon

0:40:49.071,0:40:54.950
vaihtoehtoja! Otetaanpa äänestys[br]kättä nostamalla. Kenen

0:40:54.950,0:40:59.860
mielestä nimen pitäisi olla 1.3?[br](nauraa)

0:40:59.860,0:41:02.030
Kiitos Filippo! (Filippo nauraa)[br]Jep, eli aika suuri osa.

0:41:02.030,0:41:07.840
Entäpä TLS 2? Ketään? Oho. Tämä[br]näyttää itse asiassa enemmältä kuin...

0:41:07.840,0:41:12.940
Filippo: Muistakaa että SSLv2[br]on juttu! Ja se on kamala juttu!

0:41:12.940,0:41:18.040
Nick: Ette halua sekoittaa sitä[br]meihin! No entä sitten TLS 4?

0:41:18.040,0:41:22.520
Edelleen merkittävä osa ihmisiä...[br]Entäs TLS 2017? Noniin...

0:41:22.520,0:41:25.780
Selvä. TLS 7 ketään? Okei...

0:41:25.780,0:41:30.400
Filippo: TLS Millenium 2019 X?

0:41:30.400,0:41:35.410
Kyllä! Myyty![br]Nick: TLS Vista?

0:41:35.410,0:41:38.860
(naurua) - (Nick ja Filippo nauravat)[br](aplodeja)

0:41:38.860,0:41:44.800
Nick: Paljon vaihtoehtoja! Mutta ihan[br]vain muistutuksena, muu maailma ei

0:41:44.800,0:41:50.040
oikeastaan käytä nimeä TLS. Tässä on[br]Google trends, kiinnostus aikajanalla,

0:41:50.040,0:41:55.300
kun vertaillaan "SSL vs. TLS". SSL on nimi,[br]jota suuri osa maailmasta käyttää. SSL:n

0:41:55.300,0:42:00.240
korkein versio on versio 3, ja siinä on[br]syy miksi ihmiset ajattelivat, että

0:42:00.240,0:42:05.210
"TLS 4" on hyvä ajatus. Koska: "Ihmiset[br]ovat hämillään: 3 on enemmän

0:42:05.210,0:42:10.720
kuin 1.2 jne. jne."

0:42:10.720,0:42:14.870
Tämä äänestys ei ollut ainoa. Tässä[br]on epävirallisia Twitter-äänestyksiä.

0:42:14.870,0:42:20.030
"Mmm, pekonia!" oli hyvä.[br]52 % Ryan Hurstin äänestykessä.

0:42:20.030,0:42:23.870
(naurua)

0:42:23.870,0:42:28.130
Versionumerot TLS:ssä[br]ovat inhottava aihe.

0:42:28.130,0:42:32.780
Esim. olemassa olevat versiot TLS:stä[br]- jos katsotaan verkon yli kulkevaa tietoa,

0:42:32.780,0:42:37.640
ne eivät täsmää. Eli SSL 3[br]on 3.0, mikä täsmää.

0:42:37.640,0:42:43.720
Mutta TLS 1 on 3.1, 3.2...[br]TLS 1.2 on 3.3 ja alun perin

0:42:43.720,0:42:49.000
uskoakseni TLS 1.3:n [br]luonnokseen 16 asti se oli 3.4

0:42:49.000,0:42:53.761
Eli ikäänkuin pikkupäivitys[br]TLS 1.2:een, hyvin hämmentävää.

0:42:53.761,0:42:58.511
Internetmittausten jälkeen pääteltiin

0:42:58.511,0:43:02.670
että moni palvelin, jos lähetät "Client[br]Hello":n arvolla "3.4", katkaisee yhteyden.

0:43:02.670,0:43:07.960
Tämä on oikeasti todella huono juttu, se[br]estää selaimia alentamasta yhteyttä

0:43:07.960,0:43:13.080
turvallisesti. Mitä palvelimen kuuluisi[br]tehdä, jos se näkee version joka on

0:43:13.080,0:43:18.780
korkeampi kuin 3.3, on vain vastata "3.3"[br]sanoakseen: "Tämän parempaan en pysty".

0:43:18.780,0:43:24.880
Mutta kävi ilmi, että moni näistä vain[br]hajoaa. Joten 3.3 on nyt "Client Hello":ssa

0:43:24.880,0:43:30.680
ja 3.4 neuvotellaan aliprotokollana.[br]Eli tämä on sotkuista.

0:43:30.680,0:43:35.610
Eikö? Mutta punnitsemme hyötyjä moni-[br]mutkaisuutta vastaan, ja tämä on niitä

0:43:35.610,0:43:39.640
missä palvelimien toimivuus painaa[br]enemmän kuin lisääntynyt monimutkaisuus,

0:43:39.640,0:43:44.340
jonka tuo uuden asian lisääminen. Ja tämän[br]estämiseksi tulevaisuudessa

0:43:44.340,0:43:48.820
David Benjamin ehdotti jotain nimeltä[br]GREASE, missä jokaiseen TLS-neuvottelun

0:43:48.820,0:43:53.920
osaan tulee, asiakkaana, lisätä[br]jotain satunnaista tavaraa,

0:43:53.920,0:43:56.980
jotta palvelimet tottuvat[br]näkemään asioita, jotka eivät ole

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

0:44:01.050,0:44:06.320
Filippo: Se on ihan todellinen asia![br]Se on todellinen hyvin hyödyllinen asia!

0:44:06.320,0:44:08.760
Nick: Tämä tulee olemaan hyvin[br]hyödyllinen, tulevaisuutta ajatellen,

0:44:08.760,0:44:13.850
estämään tällaisia asioita tapahtumasta.[br]Mutta on ikävää, että sen täytyi tapahtua.

0:44:13.850,0:44:18.830
Aikamme on käymässä vähiin, mutta[br]me halusimme todella päästä mukaan

0:44:18.830,0:44:23.430
ja sotkemaan kätemme. Ja yksi asia[br]mitä IETF rakastaa, kun kehittelee näitä

0:44:23.430,0:44:28.680
standardeja on koodin ajaminen. Joten [br]aloitimme IETF 95 Hackathonilla,

0:44:28.680,0:44:32.950
joka pidettiin huhtikuussa ja[br]onnistuimme lopulta saamaan Firefoxin

0:44:32.950,0:44:37.740
lataamaan Cloudflaren isännöimän[br]palvelimen TLS 1.3:lla. Tämä oli suuri

0:44:37.740,0:44:43.250
saavutus silloin. Käytimme NSS:ää,[br]joka on Firefoxin turvallisuuskirjasto ja

0:44:43.250,0:44:48.850
"Mint":iä, joka oli uusi tyhjästä

0:44:48.850,0:44:52.890
rakennettu versio TLS 1.3:sta Go-kielellä.

0:44:52.890,0:44:57.640
Ja lopputulema oli, että se toimi! Mutta[br]tämä oli ainoastaan konseptitodistus (PoC).

0:44:57.640,0:45:02.950
Filippo: Rakentaaksemme jotain tuotanto-[br]valmiimpaa, katsoimme TLS-kirjastoa,

0:45:02.950,0:45:08.330
jonka muokkaaminen tuntui meistä [br]helpoimmalta. Yllätyksettömästi se

0:45:08.330,0:45:13.370
ei ollut OpenSSL. Joten päätimme

0:45:13.370,0:45:17.990
rakentaa 1.3:n Go:n [br]crypto/tls-kirjaston päälle,

0:45:17.990,0:45:24.210
joka löytyy Go:n standardikirjastosta.[br]Lopputulos on "tls-tris", ja se on

0:45:24.210,0:45:28.500
suora korvaaja crypto/tls:lle ja[br]se tulee tämän varoituksen

0:45:28.500,0:45:33.970
saattelemana, joka sanoo: "Kaiken hyvän[br]ja oikeudenmukaisuuden nimessä,

0:45:33.970,0:45:38.990
älä käytä tätä!". Varoitus koski alunperin[br]kaikkea, mutta nyt se ei enää niinkään

0:45:38.990,0:45:45.190
koske tietoturvaa, auditoitutimme tämän,[br]mutta se koskee edelleen vakautta.

0:45:45.190,0:45:50.510
Työstämme tämän saamista ylävirtaan,[br]mikä tulee vakiinnuttamaan API:n.

0:45:50.510,0:45:56.000
Ja voitte seurata ylävirtaprosessia, [br]Googlen väki oli ystävällinen ja

0:45:56.000,0:46:00.830
avasi meille oman haaran kehitystyötä[br]varten, ja se ei varmasti tule osumaan

0:46:00.830,0:46:06.960
seuraavaan Go:n julkaisuun, Go 1.8, mutta[br]odotamme innolla, että saamme tämän ylävirtaan.

0:46:06.960,0:46:12.010
Joka tapauksessa, vaikka käyttäisit[br]Go:ta, käyttöönotto on vaikeaa.

0:46:12.010,0:46:17.800
Ensimmäisen kerran kun otimme Tris:n[br]käyttöön, luonnoksen numero oli 13.

0:46:17.800,0:46:23.630
Ja tukeakseen selaimia tästä[br]eteenpäin, meidän täytyi tukea

0:46:23.630,0:46:29.140
useita luonnosversioita saman[br]aikaisesti käyttämällä joskus

0:46:29.140,0:46:34.590
erikoisia yksityiskohtia. Ja joskus meidän[br]täytyi tukea asioita, jotka eivät todellakaan

0:46:34.590,0:46:40.030
olleet edes luonnoksia, koska selaimet[br]alkoivat... hajaantua eri suuntiin.

0:46:40.030,0:46:44.970
No, joka tapauksessa meillä[br]oli testimatriisi, joka ajoi

0:46:44.970,0:46:50.610
kaikki meidän commit:imme kaikkia[br]asiakaskirjastojen versioita vastaan,

0:46:50.610,0:46:54.980
ja tämä varmisti. että olemme[br]aina yhteensopivia selainten kanssa.

0:46:54.980,0:47:00.170
Ja nykyään asiakkaat ovat itse asiassa[br]paljon vakaampia, ja todellakin,

0:47:00.170,0:47:05.050
saatat jopa jo tietämättäsi [br]käyttää sitä. Esim. Chrome Beta,

0:47:05.050,0:47:11.160
beta kanavalla se on päällä noin 50 %[br]instansseista kokeiluna Googlen puolelta.

0:47:11.160,0:47:16.110
Ja tältä meidän kuvaajamme[br]näyttivät julkaisun aikaan,

0:47:16.110,0:47:21.560
kun Firefox Nightly laittoi sen oletuksena[br]päälle ja kun Chrome Canary laittoi sen

0:47:21.560,0:47:26.510
oletuksena päälle. Nykyään meno on[br]vakaata: noin 700 pyyntöä sekunnissa

0:47:26.510,0:47:30.640
kulkee TLS 1.3:a käyttäen. Ja omalla[br]puolellamme laitoimme sen

0:47:30.640,0:47:36.230
päälle miljoonille Cloudflaren [br]isännöimille sivustoille.

0:47:36.230,0:47:40.830
Ja, kuten sanottua, spesifikaatio[br]on muuttuva dokumentti

0:47:40.830,0:47:46.080
ja se on kaikille avoin. Sen voi nähdä[br]Githubissa. Tris implementaatio on siellä

0:47:46.080,0:47:50.860
myös, vaikkakin siinä on tämä pelottava[br]varoitus, ja tässä blogissa tulemme

0:47:50.860,0:47:56.210
luultavasti julkaisemaan kaiken jatko-[br]tutkimuksen ja tulokset. Kiitos paljon ja

0:47:56.210,0:47:59.990
jos teillä on kysymyksiä, astukaa esiin,[br]uskon että meillä on muutama minuutti.

0:47:59.990,0:48:11.770
(aplodeja)

0:48:11.770,0:48:15.690
Herald: Kiitos, meillä on reilusti [br]aikaa kysymyksille. Ensimmäinen

0:48:15.690,0:48:19.770
kysymys tulee internetistä.

0:48:19.770,0:48:23.930
Signal Angel: Ensimmäisessä kysymyksessä [br]ihmiset kysyvät onko viisasta, että

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

0:48:28.160,0:48:32.450
sovelluksen kehittäjille?

0:48:32.450,0:48:34.130
Filippo: (nauraa)[br](aplodeja)

0:48:34.130,0:48:40.230
Filippo: Hyvä kysymys. Kuten sanoimme,[br]tämä tosiaan rikkoo abstraktion.

0:48:40.230,0:48:45.500
Eli se EI ole oletusarvoisesti rikki.[br]Jos ainoastaan päivität Go:n ja

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

0:48:50.791,0:48:54.800
koska tosiaan se vaatisi yhteistyötä[br]sovellukselta. Eli mikäli sovellus ei

0:48:54.800,0:48:59.980
tiedä mitä tekee sen kanssa, se ei[br]yksinkertaisesti voi käyttää sitä, mutta

0:48:59.980,0:49:06.920
saa kaikki turvallisuushyödyt sekä 1-RTT-[br]kättelyn hyödyt joka tapauksessa.

0:49:06.920,0:49:09.570
Herald: Selvä, seuraava kysymys[br]tulee mikrofonista yksi.

0:49:09.570,0:49:12.680
Kysyjä: Protokollan ensimmäisten[br]testien yhteydessä, oletteko

0:49:12.680,0:49:17.610
saaneet konkreettisia arvoja sille, miltä[br]nuo suorituskyvyn parannukset näyttävät?

0:49:17.610,0:49:21.170
(Filippo huokaisee)

0:49:21.170,0:49:24.580
Nick: Yhdeltä edestakaiselta matkalta![br](nauraa) Riippuu siitä paljonko 1-RTT on.

0:49:24.580,0:49:28.000
Filippo: Nimenomaan. Yksi edestakainen[br]matka on... en pysty sanomaan lukua

0:49:28.000,0:49:33.250
koska tietysti, jos asut San Franciscossa,[br]jossa on nopea kuituyhteys, se on

0:49:33.250,0:49:39.120
mitä? Ehkä 3 millisekuntia? 6...? [br]Jos taas asut vaikka jossain maassa,

0:49:39.120,0:49:43.260
missä EDGE on ainoa [br]käytettävissä oleva yhteys,

0:49:43.260,0:49:47.700
se on ehkä sekunti. Meillä taitaa[br]olla keskiarvo, joka on noin... 100

0:49:47.700,0:49:55.100
ja 200 millisekunnin välillä, mutta emme[br]ole virallisesti mitanneet näitä lukuja.

0:49:55.100,0:49:57.630
Herald: Ok, seuraava kysymys[br]tulee mikrofonista 3.

0:49:57.630,0:50:01.720
Kysyjä: Yksi huomautus, jonka haluan sanoa[br]on, että yksi parannus joka saavutettiin

0:50:01.720,0:50:07.350
TLS 1.3:ssa on että asiakas-[br]varmenteisiin lisättiin salaus.

0:50:07.350,0:50:11.330
Joten asiakasvarmenteet lähetetään[br]salattuina, mikä on tärkeää, jos

0:50:11.330,0:50:17.670
ajattelee asiakasta, joka liikkuu sekä [br]joukkovalvovaa elintä, joka voisi

0:50:17.670,0:50:23.120
jäljittää asiakkaita tällä. Ja toinen[br]huomio/kysymys, joka saattaisi...

0:50:23.120,0:50:27.080
Herald: Kysymykset päättyvät kysymys-[br]merkkiin. Joten yritäthän pitää lyhyenä?

0:50:27.080,0:50:31.820
Kysyjä: Kyllä... Tämä saattaa[br]olla tyhmä kysymys...

0:50:31.820,0:50:36.400
Vakio Diffie-Hellman-ryhmät...[br]eivätkö ne olleet ongelma LogJam-

0:50:36.400,0:50:42.890
hyökkäyksessä, joten... auttaako[br]tämä LogJam-hyökkäyksiä vastaan?

0:50:42.890,0:50:46.660
Nick: Viittaatko siihen pankeille[br]suunnattuun ehdotukseen?

0:50:46.660,0:50:49.590
Kysyjä: Ei ei, yleisesti siihen, [br]että voidaan laskea ennakkoon...

0:50:49.590,0:50:54.430
Nick: Aivan, kyllä, eli LogJamin kohdalla[br]oli ongelma, missä oli DH-ryhmä, joka

0:50:54.430,0:50:57.940
oli oletuksena käytössä monella[br]eri palvelimella. Apachen käyttämä,

0:50:57.940,0:51:03.800
joka oli 1024 (bittiä).[br]TLS 1.3:ssa tämä rajoitettiin

0:51:03.800,0:51:09.190
ennalta laskettuun DH-ryhmään,[br]joka on yli 2000 bittiä pienimmilläänkin,

0:51:09.190,0:51:14.600
ja valtavallakin laskentateholla varustettuna,[br]jos on 2000 bitin DH ryhmä, ei ole

0:51:14.600,0:51:20.140
käytännössä mahdollista tehdä esilasken-[br]taa minkäänlaista hyökkäystä varten.

0:51:20.140,0:51:21.990
Mutta kyllä, tuo on hyvä pointti.

0:51:21.990,0:51:24.950
Filippo: ...ja koska ne ovat kiinteitä, ei[br]ole keinoa pakottaa protokollaa käyttämään

0:51:24.950,0:51:28.940
mitään muuta, joka ei olisi niin vahva.[br]Kysyjä: Selvä, kiitos!

0:51:28.940,0:51:32.720
Herald: Seuraava kysymys mikrofonista 4.

0:51:32.720,0:51:37.120
Kysyjä: Kiitos esityksestä! [br]Tiivistelmässä mainitsitte, että eräs

0:51:37.120,0:51:41.550
toinen lopetettava ominaisuus oli SNI,

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

0:51:45.920,0:51:49.670
Filippo: Pidimme siis tämän esitelmän[br]kahdesti sisäisesti, ja tämä kysymys

0:51:49.670,0:51:55.590
esitettiin molemmilla[br]kerroilla. Joten... (nauraa)

0:51:55.590,0:52:01.790
Eli, SNI on pieni parametri, jonka asiakas[br]lähettää palvelimelle kertoakseen,

0:52:01.790,0:52:06.210
mille sivustolle se yrittää[br]yhdistää. Esim. Cloudflarella on

0:52:06.210,0:52:11.250
useita sivustoja koneidemme takana, joten[br]sinun täytyy kertoa meille "Haluan siis

0:52:11.250,0:52:17.230
oikeasti yhdistää "blog.filippo.io":n. Tämä[br]on yksityisyyden kannalta ongelmallista,

0:52:17.230,0:52:22.550
koska joku voi pelkästään verkon yli[br]kulkevista tavuista nähdä, mihin

0:52:22.550,0:52:29.450
nimenomaiseen sivuun yhdistät. Epäonninen[br]seikka on se, että tässä on sama onglema

0:52:29.450,0:52:35.270
kuin alkudatan jatkosuojauksessa.[br]SNI lähetetään "Client Hello":ssa, ja

0:52:35.270,0:52:39.620
tässä kohtaa ei ole vielä neuvoteltu[br]yhtään avainta, joten ei ole mitään millä

0:52:39.620,0:52:44.960
sen voisi salata. Mutta jos ei lähetä[br]SNI:tä ensimmäisessä viestissä,

0:52:44.960,0:52:49.140
palvelin ei tiedä minkä sertifikaatin[br]se lähettää, joten se ei voi lähettää

0:52:49.140,0:52:53.050
allekirjoitusta ensimäisessä viestissä,[br]joten ei ole avaimia. Eli täytyisi tehdä

0:52:53.050,0:52:59.030
2-RTT, ja nyt olisimme taas samassa[br]pisteessä kuin TLS 1.2. Joten,

0:52:59.030,0:53:03.180
valitettavasti, se ei[br]toimi 1-RTT kättelyissä.

0:53:03.180,0:53:08.820
Nick: HTTP2:n spesifikaatiossa on kuitenkin[br]ehdotuksia, jotka mahdollistaisivat multi-

0:53:08.820,0:53:14.210
pleksaamisen. Tämä on vielä työn alla. [br]Voisi olla mahdollista yhdistää ensin

0:53:14.210,0:53:19.700
yhteen verkkotunnukseen ja sitten luoda[br]toinen yhteys olemassa olevan sisällä.

0:53:19.700,0:53:21.950
Ja tämä voisi mahdollisesti[br]suojata SNI:tä.

0:53:21.950,0:53:25.520
Filippo: Eli joku tarkkailija ajattelisi,[br]että menet sivulle blog.filippo.io mutta

0:53:25.520,0:53:29.480
kun avaat yhteyden, voisit pyytää[br]HTTP2:ta näyttämään myös

0:53:29.480,0:53:33.200
"tämän toisen sivun". Kiitos!

0:53:33.200,0:53:38.170
Herald: Selvä, seuraava[br]kysymys, mikrofoni 7,

0:53:38.170,0:53:41.240
tai itse asiassa 5, pahoittelut.

0:53:41.240,0:53:47.440
Kysyjä: Mainitsitte, että TLS 1.3:sta[br]on olemassa formaali verifikaatio.

0:53:47.440,0:53:54.350
Millä ohjelmistolla tämä[br]formaali verifikaatio on tehty?

0:53:54.350,0:53:59.030
Nick: Oli useita ohjelmisto-[br]implementaatioita ja protokollia...

0:53:59.030,0:54:02.650
Katsotaanpa, jos pääsen[br]takaisinpäin... tässä.

0:54:02.650,0:54:06.600
Tamarin on ohjelmisto, jonka on[br]kehittänyt muun muassa Cas Cremers

0:54:06.600,0:54:11.810
Oxfordissa ja Royal Hollowayssa.[br]miTLS on uskoakseni kirjoitettu F#:lla

0:54:11.810,0:54:18.430
INRIA:n toimesta. Ja nqsb-TLS[br]on kirjoitettu OCaml:lla.

0:54:18.430,0:54:22.970
Joten useita eri kieliä käytettiin näiden[br]kehityksessä ja käsittääkseni nqsb-TLS:n

0:54:22.970,0:54:27.490
kehittäjät ovat paikalla...

0:54:27.490,0:54:30.960
Herald: Selvä, seuraava[br]kysymys mikrofoni 8.

0:54:30.960,0:54:36.440
Kysyjä: Hei! Kiitos. Kiitos [br]informatiivisesta esityksestä.

0:54:36.440,0:54:42.690
SSL:n ja TSL:n historia on täynnä "mikä[br]muka voisi mennä vikaan"-ideoita ja hetkiä,

0:54:42.690,0:54:48.810
jotka lopulta kostautuivat. Joten[br]kysymykseni, kun otetaan huomioon,

0:54:48.810,0:54:52.740
että on useita pienempiä organisaatioita[br]tai pienempiä hosting-yrityksiä jne.,

0:54:52.740,0:54:59.600
jotka luultavasti implementoivat 0-RTT:n[br]väärin. Mikä on ensivaikutelmanne? Kuinka

0:54:59.600,0:55:04.180
todennäköistä on, että tämä todella[br]tulee kostautumaan pian? Kiitos.

0:55:04.180,0:55:09.990
Filippo: Kuten sanoin, olen itse asiassa[br]aavistuksen skeptinen vaikutusten suhteen

0:55:09.990,0:55:16.460
koskien HTTP:tä, sillä selaimet saadaan[br]uudelleenlähettämään pyyntöjä jo nyt.

0:55:16.460,0:55:21.610
Ja olemme nähneet tästä[br]julkaisuja ja blogipostauksia. Mutta

0:55:21.610,0:55:25.830
kukaan ei kyennyt näyttämään[br]toteen, että se olisi rikkonut

0:55:25.830,0:55:30.620
suuren osuuden internetistä. Ollakseni[br]rehellinen, en osaa vastata, kuinka

0:55:30.620,0:55:35.990
pahasti se kostautuu. Mutta muistetaan,[br]että tasapainon toinen puoli

0:55:35.990,0:55:41.650
on se määrä ihmisiä, jotka sanovat[br]etteivät aio ottaa TSL:ää käyttöön

0:55:41.650,0:55:45.670
koska se on "hidas". Ei.

0:55:45.670,0:55:51.620
Se on 0-RTT, TLS on nopea![br]Menkää ja salatkaa kaikki!

0:55:51.620,0:55:57.940
Siis nuo ovat ne kaksi huolenaihetta, [br]jotka täytyy saada tasapainoon.

0:55:57.940,0:56:01.910
Lisäksi, oma henkilökohtainen[br]mielipiteeni ei paina paljoa.

0:56:01.910,0:56:07.310
Tämä oli päätös, jonka teki koko[br]postituslistasta koostuva yhteisö.

0:56:07.310,0:56:12.900
Ja voin vakuuttaa, että jokainen on ollut[br]hyvin konservatiivinen kaiken suhteen,

0:56:12.900,0:56:18.630
ottanut huomioon jopa... niin, senkin[br]olisiko nimi johtanut ihmisiä harhaan.

0:56:18.630,0:56:23.910
En osaa ennustaa tulevaisuutta. Voin[br]vain sanoa toivovani, että teimme

0:56:23.910,0:56:28.520
parhaan valinnan tehdäksemme suurimman[br]osan verkosta niin turvalliseksi kuin voimme.

0:56:28.520,0:56:32.490
Herald: Seuraava kysymys[br]tulee internetistä.

0:56:32.490,0:56:34.610
Signal Angel, onko meillä vielä[br]kysymys internetistä?

0:56:34.610,0:56:37.760
Signal Angel: Kyllä meillä on.

0:56:37.760,0:56:43.060
Mitkä ovat suurimmat implementoinnin[br]yhteensopimattomuudet, jotka on löydetty

0:56:43.060,0:56:45.800
nyt kun lopullinen spesifikaatio[br]on melko valmis?

0:56:45.800,0:56:47.910
Herald: Voitko toistaa kysymyksen?

0:56:47.910,0:56:53.250
(Signal Angel toistaa kysymyksen)

0:56:53.250,0:56:59.290
Filippo: Okei. Koskien[br]luonnosteluvaihetta?

0:56:59.290,0:57:03.450
Osa niistä, jotka eivät olleet versio-[br]yhteensopivia oli, uskoakseni, enimmäkseen

0:57:03.450,0:57:06.750
"middleboxeja" ja palomuureja.

0:57:06.750,0:57:12.690
Nick: Oli joitain todella isoja [br]sivustojakin. Paypal taisi olla yksi?

0:57:12.690,0:57:18.310
Filippo: Vaikkakin, prosessin aikana[br]meillä oli yhteensopivuusongelmia monista

0:57:18.310,0:57:23.540
syistä. Mukaanlukien se, missä[br]toinen kehittäjistä kirjoitti väärin

0:57:23.540,0:57:28.110
muuttujan numeron.[br](nauraa)

0:57:28.110,0:57:32.420
Luonnosten aikana joskus yhteensopivuus[br]meni rikki, mutta oli myös paljon yhteis-

0:57:32.420,0:57:37.970
työtä asiakasimplementaatioiden ja meidän[br]puolemme palvelinimplementaatioiden välillä.

0:57:37.970,0:57:44.040
Voin onnekseni todeta, että varsinaisten[br]1.3 implementaatioiden kanssa tehtiin

0:57:44.040,0:57:50.980
paljon yhteensopivuustestejä, ja kaikki[br]ongelmat saatiin melko nopeasti korjattua.

0:57:50.980,0:57:54.050
Herald: Okei, seuraava kysymys[br]tulee mikrofonista numero 1.

0:57:54.050,0:57:59.300
Kysyjä: Minulla on 2 nopeaa kysmystä[br]koskien istunnon jatkamista.

0:57:59.300,0:58:02.951
Jos palvelimelle tallennetaan jotain[br]dataa istunnosta, eikö se olisi tavallaan

0:58:02.951,0:58:08.010
jonkinlainen supereväste? Eikö se ole[br]yksityisyyden kannalta vaarallista?

0:58:08.010,0:58:13.990
Ja toinen kysymys on: entä DNS-[br]kuormantasaajat tai jotkut muut

0:58:13.990,0:58:21.070
valtavat määrät palvelimia, missä pyynnöt[br]menevät joka kerta eri palvelimelle?

0:58:21.070,0:58:28.150
Filippo: Ok, eli nämä koskevat yksityiskohtia[br]istuntolippujen tehokkaasta jakelusta.

0:58:28.150,0:58:32.950
TLS 1.3 ottaa huomioon yksityisyydensuojan[br]koskien istuntolippuja, ja tosiaan se

0:58:32.950,0:58:37.650
mahdollistaa palvelimen lähettämään useita[br]istuntolippuja. Palvelin voi siis edelleen

0:58:37.650,0:58:42.470
tietää mikä asiakas sen lähettää, jos niin[br]haluaa. Mutta kukaan ulkopuolelta yhteyttä

0:58:42.470,0:58:47.460
tarkkaileva ei siihen kykene, koska ne [br]lähetetään salattuina, toisin kuin TLS 1.2:ssa

0:58:47.460,0:58:53.171
ja niitä voi olla useita. Kukaan ulko-[br]puolinen ei pysty yhdistämään sitä

0:58:53.171,0:58:57.600
alkuperäiseen yhteyteen. Tämän parempaan[br]ei pysty, sillä jos palvelimen ja asiakkaan

0:58:57.600,0:59:02.560
täytyy käyttää uudelleen jotain jaettua[br]tietoa, palvelimen täytyy saada tietää

0:59:02.560,0:59:08.240
kuka oli kyseessä. Mutta istuntolippuja[br]ei voi 1.3:ssa jäljittää kolmannen

0:59:08.240,0:59:13.010
osapuolen toimesta. Ja... kun tehdään[br]kuormantasausta... on eräs mielenkiintoinen

0:59:13.010,0:59:18.750
julkaisu istuntolippujen jakelusta, mutta[br]olennaista on, että kannattaa varmaan

0:59:18.750,0:59:24.960
selvittää miten asiakkaat liikkuvat[br]palvelimien välillä ja löytää tasapaino

0:59:24.960,0:59:30.340
sen välillä kannattaako istuntolipun[br]avain jakaa, jolloin se on tehokkaampaa

0:59:30.340,0:59:35.500
vai jättää istuntolipun avain jakamatta,[br]jolloin niitä on vaikeampi saada käsiinsä.

0:59:35.500,0:59:41.610
Saattaisit tehdä maantieteellisen[br]sijainnin mukaan, tai yhden räkin...

0:59:41.610,0:59:44.540
Se riippuu ihan toteutuksesta.

0:59:44.540,0:59:47.480
Herald: Okei, viimeinen[br]kysymys menee mikrofonille 3.

0:59:47.480,0:59:51.750
Kysyjä: Minulla on kysymys koskien[br]GREASE-mekanismia, joka toteutetaan

0:59:51.750,0:59:57.110
asiakkaan puolella. Jos[br]ymmärsin oikein, siinä lisätään

0:59:57.110,1:00:02.350
satunnaisia versionumeroita[br]olemattomista TLS- tai SSL-versioista

1:00:02.350,1:00:08.640
ja siten koulutetaan[br]palvelimet mukautumaan

1:00:08.640,1:00:14.480
spesifikaatioon. Mitkä ovat[br]tosielämän testien tulokset?

1:00:14.480,1:00:18.490
Moniko palvelin menee[br]tästä oikeasti nurin?

1:00:18.490,1:00:22.780
Filippo: Odotusarvoisesti ei yksikään,[br]koska ne kaikki ovat nyt ottamassa

1:00:22.780,1:00:28.070
1.3:a käyttöön, joten kaikki asiakkaat,[br]joita ne kohtaavat käyttäisivät GREASE:a.

1:00:28.070,1:00:33.100
Kuitenkin, juuri kun Google otti GREASE:n[br]käyttöön luulen sen rikkoneen... En ole

1:00:33.100,1:00:38.330
varma, joten en sano mikä palvelin-[br]implementaatio, mutta yhden pienemmistä

1:00:38.330,1:00:41.860
tunnistettiin heti olevan... [br]se Haskell-kielellä kirjoitettu!

1:00:41.860,1:00:43.890
Nick: Aivan![br]Filippo: En muista sen nimeä,

1:00:43.890,1:00:47.450
en osaa lukea Haskellia, joten en[br]tarkalleen tiedä mitä ne tekivät, mutta

1:00:47.450,1:00:49.590
ne katkaisivat yhteyksiä[br]GREASE:n takia.

1:00:49.590,1:00:53.480
Nick: Ja huomautuksena, GREASE:a käytetään[br]myös salausneuvotteluissa ja kaikessa

1:00:53.480,1:00:58.800
mikä on neuvottelu TLS 1.3:ssa.[br]Tämä tosiaan rikkoi

1:00:58.800,1:01:03.020
pienen osan palvelimista, mutta[br]sen verran pienen osan,

1:01:03.020,1:01:06.600
että ihmiset hyväksyivät sen.

1:01:06.600,1:01:08.670
Kysyjä: Kiitos![br]Nick: 2 % on liikaa!

1:01:08.670,1:01:11.430
Herald: Kiitos oikein paljon.[br]Filippo: Kiitos!

1:01:11.430,1:01:20.010
(aplodeja)

1:01:20.010,1:01:39.080
(33C3 loppumusiikki)

1:01:39.080,1:01:43.981
Translated by Roope Salminen[br](ITKST56 course assignment at JYU.FI)