1
00:00:00,000 --> 00:00:14,820
Translated by Roope Salminen
(ITKST56 course assignment at JYU.FI)
(33C3 intromusiikki)

2
00:00:14,820 --> 00:00:20,190
Herald: Seuraava esitelmä 
käsittelee TLS 1.3:n käyttöönottoa

3
00:00:20,190 --> 00:00:23,509
ja sen pitävät Filippo Valsorda 
sekä Nick Sullivan,

4
00:00:23,509 --> 00:00:26,989
jotka molemmat 
työskentelevät Cloudflarelle.

5
00:00:26,989 --> 00:00:32,110
Joten toivottakaamme lämpimästi 
tervetulleeksi Nick ja Filippo!

6
00:00:32,110 --> 00:00:39,490
(aplodeja)

7
00:00:39,490 --> 00:00:43,820
Filippo: Hei kaikki. Puheen-
aiheenamme tänään on TLS 1.3.

8
00:00:43,820 --> 00:00:48,340
TLS 1.3 on tietenkin uusin versio 
TLS:stä, joka tulee sanoista

9
00:00:48,340 --> 00:00:52,960
"Transport Layer Security".
Se on ehkä tunnetuin

10
00:00:52,960 --> 00:00:57,900
vihreästä lukosta selaimessa,
tai vanhalta nimeltään SSL,

11
00:00:57,900 --> 00:01:02,510
jota yritämme edelleen
tappaa. TLS on

12
00:01:02,510 --> 00:01:07,890
läpinäkyvä turvallisuusprotokolla,
joka voi turvallisesti tunneloida

13
00:01:07,890 --> 00:01:12,460
mielivaltaista sovellusliikennettä.
Sitä käyttävät tietenkin web-selaimet,

14
00:01:12,460 --> 00:01:16,760
sitä käyttävät sähköpostipalvelimet
turvaamaan keskinäistä

15
00:01:16,760 --> 00:01:22,270
SMTP-liikennettään. Sitä käyttävät 
Tor-solmut keskinäiseen kommunikointiinsa.

16
00:01:22,270 --> 00:01:26,810
Mutta... Se kehittyi yli 20 vuoden ajan,

17
00:01:26,810 --> 00:01:31,320
mutta pohjimmiltaan se koskee asiakasta
ja palvelinta, jotka haluavat kommunikoida

18
00:01:31,320 --> 00:01:36,119
turvallisesti verkon yli.
Kommunikoidakseen turvallisesti verkon yli

19
00:01:36,119 --> 00:01:41,170
niiden täytyy luoda avainmateriaalia,
sopia keskenään avainmateriaalista

20
00:01:41,170 --> 00:01:47,349
molemmin puolin salatakseen
tulevan liikenteen.

21
00:01:47,349 --> 00:01:51,989
Se, miten avainmateriaalista sovitaan,
hoidetaan vaiheessa, jota kutsumme

22
00:01:51,989 --> 00:01:57,890
"kättelyksi". Kättelyssä on mukana
julkisen avaimen kryptografiaa ja

23
00:01:57,890 --> 00:02:02,670
dataa, jota lapioidaan asiakkaalta
palvelimelle, palvelimelta asiakkaalle.

24
00:02:02,670 --> 00:02:07,170
Tältä kättely näyttää TLS 1.2:ssa.

25
00:02:07,170 --> 00:02:12,790
Asiakas aloittaa tanssit
lähettämällä "Client Hello"-viestin,

26
00:02:12,790 --> 00:02:18,960
jossa kertoo, mitä tuettuja
parametreja se voi käyttää.

27
00:02:18,960 --> 00:02:23,430
Palvelin vastaanottaa sen ja
lähettää oman viestinsä, joka on

28
00:02:23,430 --> 00:02:28,200
"Server Hello", joka sanoo "Selvä! Käyte-
tään tätä salausalgoritmien yhdistelmää,

29
00:02:28,200 --> 00:02:33,230
jota sanot tukevasi, ja tässä on minun
avainosuuteni käytettäväksi

30
00:02:33,230 --> 00:02:39,270
tässä avaintenvaihtoalgoritmissa.
Lisäksi, tässä on varmenne,

31
00:02:39,270 --> 00:02:45,300
jonka on allekirjoittanut auktoriteetti,
joka todistaa, että todellakin olen

32
00:02:45,300 --> 00:02:50,370
Cloudflare.com. Ja tässä on allekirjoitus 
varmenteesta todistamaan, että tämä

33
00:02:50,370 --> 00:02:55,450
avainosuus on todellakin se, jota haluan 
sinun käyttävän avainten luomiseen."

34
00:02:55,450 --> 00:03:00,940
Asiakas vastaanottaa sen ja generoi
oman avainosuutensa, eli oman puolensa

35
00:03:00,940 --> 00:03:06,200
Diffie-Hellman avaintenvaihdosta,
ja lähettää avainosuuden sekä

36
00:03:06,200 --> 00:03:10,999
viestin kertoakseen: "Se oli siinä.
Kättely on nyt paketissa".

37
00:03:10,999 --> 00:03:15,490
Tätä kutsutaan "Finished" viestiksi.
Palvelin vastaanottaa sen, luo

38
00:03:15,490 --> 00:03:20,679
oman "Finished" viestinsä
ja vastaa sillä. Eli

39
00:03:20,679 --> 00:03:25,930
nyt voimme vihdoin lähettää sovellusdataa. 
Kerrataanpa vielä prosessi:

40
00:03:25,930 --> 00:03:30,022
Asiakas -> Palvelin, Palvelin -> Asiakas;
Asiakas -> Palvelin, Palvelin -> Asiakas.

41
00:03:30,022 --> 00:03:34,960
Meidän täytyi tehdä 2 edestakaista matkaa 
asiakkaan ja palvelimen välillä ennen

42
00:03:34,960 --> 00:03:40,730
mitään muuta. Emme ole lähettäneet 
tavuakaan sovelluskerroksella

43
00:03:40,730 --> 00:03:46,010
ennen tätä. Tämä tietenkin 
matkapuhelinverkoissa

44
00:03:46,010 --> 00:03:50,539
tai tietyissä osissa
maailmaa voi kerryttää

45
00:03:50,539 --> 00:03:55,320
satojen millisekuntien viiveen. 
Ja tämä täytyy tehdä

46
00:03:55,320 --> 00:04:00,930
joka kerta, kun uutta yhteyttä avataan.
Joka kerta asiakkaan ja palvelimen

47
00:04:00,930 --> 00:04:06,490
täytyy kulkea kahdesti välinsä
luodakseen avaimet ennen

48
00:04:06,490 --> 00:04:12,730
kuin yhteyttä voi oikeasti
käyttää. TLS 1.1

49
00:04:12,730 --> 00:04:17,950
ja 1.0 eivät eronneet suuresti 
1.2:sta. Voisikin kysyä: "Miksi sitten

50
00:04:17,950 --> 00:04:23,750
pitää kokonainen esitys TLS 1.3:sta,
joka on luultavasti vain taas yksi

51
00:04:23,750 --> 00:04:31,430
iteraatio samasta konseptista?" No, TLS
1.3 on oikeasti iso uudelleensuunnittelu.

52
00:04:31,430 --> 00:04:36,740
Erityisesti kättely on restukturoitu. 
Ja tämän näkyvin tulos

53
00:04:36,740 --> 00:04:43,139
on se, että yksi kokonainen 
edestakainen matka on karsittu pois.

54
00:04:43,139 --> 00:04:48,929
Eli, tältä näyttää TLS 1.3-kättely.

55
00:04:48,929 --> 00:04:53,479
Kuinka 1.3 poistaa edestakaisen matkan?
Miten se pystyy siihen? Se kykenee siihen

56
00:04:53,479 --> 00:04:59,799
ennustamalla, mitä 
avaintenvaihtoalgoritmia

57
00:04:59,799 --> 00:05:04,740
palvelin tulee käyttämään, ja
lähettämällä ennakkoon avainosuuden

58
00:05:04,740 --> 00:05:10,029
tuota algoritmia varten palvelimelle.
Eli ensimmäisessä viestissä meillä oli

59
00:05:10,029 --> 00:05:15,529
"Client Hello", tuetut parametrit
ja avainosuus algoritmille,

60
00:05:15,529 --> 00:05:21,549
josta asiakas uskoo palvelimen pitävän.
Palvelin vastaanottaa viestin,

61
00:05:21,549 --> 00:05:27,239
ja jos kaikki menee hyvin, se ajattelee:
"Ah! Okei! Tykkään tästä avainosuudesta.

62
00:05:27,239 --> 00:05:32,789
Tässä on oma avainosuuteni samaa
algoritmia varten, ja tässä muut

63
00:05:32,789 --> 00:05:37,719
parametrit, joita meidän tulisi käyttää."
Se välittömästi sekoittaa avainosuudet

64
00:05:37,719 --> 00:05:42,319
saadakseen jaetun yhteisen avaimen, koska
nyt sillä on molemmat avainosuudet -

65
00:05:42,319 --> 00:05:47,089
asiakkaan ja palvelimen - ja lähettää
taas varmenteen ja allekirjoituksen

66
00:05:47,089 --> 00:05:51,339
varmenteesta, ja sitten välittömästi
lähettää "Finished"-viestin, koska

67
00:05:51,339 --> 00:05:56,339
se ei tarvitse mitään muuta asiakkaalta. 
Asiakas vastaanottaa tuon, ottaa

68
00:05:56,339 --> 00:06:02,020
avainosuuden, luo jaetun yhteisen avaimen 
ja lähettää oman "Finished" viestinsä,

69
00:06:02,020 --> 00:06:07,009
ja on valmis lähettämään sitä sovellus-
dataa, jota olikaan lähettämässä.

70
00:06:07,009 --> 00:06:12,650
Esimerkiksi HTTP-pyynnön.
Nyt prosessi meni näin:

71
00:06:12,650 --> 00:06:15,919
Asiakas -> Palvelin, Palvelin -> Asiakas.

72
00:06:15,919 --> 00:06:21,330
Ja olemme valmiita lähettämään
sovelluskerroksen dataa. Eli, jos olit

73
00:06:21,330 --> 00:06:27,239
avaamassa HTTPS-yhteyttä, selaimesi

74
00:06:27,239 --> 00:06:32,769
ei tarvitse odottaa nelinkertaista viivettä, 
nelinkertaista pingiä. Sen täytyy

75
00:06:32,769 --> 00:06:38,929
odottaa vain kaksinkertainen, ja tämä
tietysti säästää satoja millisekunteja

76
00:06:38,929 --> 00:06:46,199
viivettä kun avataan uusia yhteyksiä.
Tämä oli onnellinen tapaus.

77
00:06:46,199 --> 00:06:52,299
Näin käy, kun ennustus osuu oikeaan
ja palvelin tykkää asiakkaan

78
00:06:52,299 --> 00:06:58,449
avainosuudesta. Jos palvelin
ei tue avainosuutta, jonka

79
00:06:58,449 --> 00:07:05,169
asiakas lähetti, se lähettää kohteliaan
pyynnön käyttää jotain toista algoritmia,

80
00:07:05,169 --> 00:07:10,530
jota asiakas sanoi tukevansa. Tätä viestiä
kutsutaan nimellä "Hello Retry Request".

81
00:07:10,530 --> 00:07:16,469
Siinä on eväste, joten se voi olla tilaton
mutta periaatteessa se on varakeino,

82
00:07:16,469 --> 00:07:21,970
jolla palataan käytännössä TLS 1.2-
kaltaiseen kättelyyn. Eikä se ole kovin

83
00:07:21,970 --> 00:07:26,939
vaikea toteuttaa, koska asiakas jatkaa
uudella "Client Hello":lla, joka näyttää

84
00:07:26,939 --> 00:07:34,489
periaattessa täysin samalta kuin
täysin tuorekin. Nyt...

85
00:07:34,489 --> 00:07:42,179
Tässä kohtaa olen valehdellut. TLS 1.2
ei aina ole 2 edestakaista matkaa.

86
00:07:42,179 --> 00:07:47,779
Suurin osa yhteyksistä, joita näemme 
esimerkiksi Cloudflaren reunalta ovat

87
00:07:47,779 --> 00:07:53,299
istunnon jatkamisia. Eli asiakas on ollut
yhteydessä k.o. sivustolle aiemmin.

88
00:07:53,299 --> 00:07:59,079
Ja voimme käyttää tätä, voimme hyödyntää
tätä ja tehdä kättelystä nopeamman.

89
00:07:59,079 --> 00:08:06,290
Tämä tarkoittaa, että asiakas muistaa
jotain avainmateriaalista, jotta pystyy

90
00:08:06,290 --> 00:08:10,959
avaamaan seuraavan yhteyden vain yhdellä
edestakaisella matkalla myös TLS 1.2:ssa.

91
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

92
00:08:16,019 --> 00:08:22,479
matkan yhteys. Ja tässä palvelin lähettää
lipun uutta istuntoa varten. Istuntolippu

93
00:08:22,479 --> 00:08:30,029
ei ole sen kummempi kuin salattu
kapseloitu blob sisältäen avainmateriaalia,

94
00:08:30,029 --> 00:08:35,100
jonka asiakas säilyttää. Istuntolippu on
salattu ja allekirjoitettu avaimella,

95
00:08:35,100 --> 00:08:40,039
jonka vain palvelin tietää. Eli se on
täysin läpinäkymätön asiakkaalle.

96
00:08:40,039 --> 00:08:45,040
Mutta asiakas säilyttää sen sekä
yhteyden avainmateriaalin,

97
00:08:45,040 --> 00:08:49,340
jotta seuraavan kerran kun se avaa
yhteyttä samalle sivustolle

98
00:08:49,340 --> 00:08:54,439
se lähettää "Client Hello":n
ja istuntolipun.

99
00:08:54,439 --> 00:08:59,180
Jos palvelin tunnistaa istuntolipun, se
purkaa sen salauksen ja löytää sisältä

100
00:08:59,180 --> 00:09:04,090
avainmateriaalin. Ja nyt, vain yhden edes-
takaisen matkan jälkeen, palvelimella on

101
00:09:04,090 --> 00:09:09,820
yhteistä avainmateriaalia asiakkaan kanssa
koska asiakas säilytti sen viime kerrasta

102
00:09:09,820 --> 00:09:15,460
ja palvelin juuri purki sen 
salatusta istuntolipusta.

103
00:09:15,460 --> 00:09:20,890
Ok? Eli nyt palvelimella on jo käytet-
tävissä yhteisiä jaettuja avaimia ja se

104
00:09:20,890 --> 00:09:26,150
lähettää "Finished"-viestin ja asiakas 
vastaa "Finished"-viestillä ja pyynnöllä.

105
00:09:26,150 --> 00:09:31,550
Eli tämä on TLS 1.2. Tätä tapahtuu
jo nyt joka päivä useimpien

106
00:09:31,550 --> 00:09:37,380
modernien TLS-yhteyksien kanssa.

107
00:09:37,380 --> 00:09:43,530
TLS 1.3-istunnon jatkaminen ei ole kovin
erilainen. Siinäkin on istuntolipun käsite

108
00:09:43,530 --> 00:09:48,300
Istuntolipun sisällön nimi on muutettu
"PSK":ksi, mutta se tulee vain sanoista

109
00:09:48,300 --> 00:09:53,220
"Pre-shared Key", koska sitähän se on:
pelkkää avainmateriaalia, josta

110
00:09:53,220 --> 00:09:58,480
oli sovittu aiemmin.
Ja se toimii samalla tavalla:

111
00:09:58,480 --> 00:10:02,830
palvelin vastaanottaa istuntolipun,
purkaa salauksen ja hyppää

112
00:10:02,830 --> 00:10:07,450
"Finished"-viestiin. Nyt...

113
00:10:07,450 --> 00:10:13,070
Ongelma istunnon jatkamisessa on se,
että jos hyökkääjällä on hallussaan

114
00:10:13,070 --> 00:10:17,130
istuntolipun avain - eli avain, jota 
palvelin käyttää salamaan istuntolipun,

115
00:10:17,130 --> 00:10:21,540
jonka sisällä avainmateriaali on -

116
00:10:21,540 --> 00:10:27,050
hyökkääjä voi passiivisesti, tai jopa
tulevaisuudessa kaapatun yhteyden

117
00:10:27,050 --> 00:10:33,460
tapauksessa, purkaa istuntolipun
"Client Hello":sta, löytää sieltä PSK:n

118
00:10:33,460 --> 00:10:38,320
ja käyttää sitä purkamaan koko loppu-
yhteyden salauksen. Tämä ei ole hyvä.

119
00:10:38,320 --> 00:10:42,519
Tämä tarkoittaa, että joku voi
passiivisesti purkaa salauksen

120
00:10:42,519 --> 00:10:47,819
hallinnoimalla istuntolipun avainta.
Tähän vastataan yleensä sanomalla, että

121
00:10:47,819 --> 00:10:52,540
Lippujen avaimet vanhenevat nopeasti.
Mutta eikö olisi mukavaa, jos meidän ei

122
00:10:52,540 --> 00:10:56,270
tarvitsisi luottaa siihen. Ja on itse
asiassa julkaisuja, jotka kertovat meille

123
00:10:56,270 --> 00:11:01,310
että toteutukset eivät aina
tee tuota oikein. Siispä,

124
00:11:01,310 --> 00:11:07,050
TLS 1.3 sen sijaan mahdollistaa
Diffie-Hellmanin käytön

125
00:11:07,050 --> 00:11:11,760
istunnon jatkamisessa. 1.2:ssa
ei ollut keinoja suojautua istunto-

126
00:11:11,760 --> 00:11:16,720
lipun avaimen murtamisen
seurauksilta. 1.3:ssa voi sen sijaan

127
00:11:16,720 --> 00:11:21,409
lähettää avainosuuden
osana "Client Hello":ta

128
00:11:21,409 --> 00:11:25,499
ja palvelin lähettää avainosuuden 
"Server Hello":n yhteydessä,

129
00:11:25,499 --> 00:11:31,710
ja osapuolet suorittavat Diffie-Hellmanin.
Diffie-Hellmania käytettiin

130
00:11:31,710 --> 00:11:36,009
jatkosuojauksen toteuttamiseen esimerkiksi
sen varalta, että varmenteen yksityinen

131
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

132
00:11:41,339 --> 00:11:46,290
toteuttamiseen istunnon jatkamisessa.
Nyt, saatatte miettiä:

133
00:11:46,290 --> 00:11:51,240
"Tämä näyttää periaatteessa
normaalilta 1.3 kättelyltä,

134
00:11:51,240 --> 00:11:55,770
mikä virka PSK:lla on ylipäätään?"
Tästäpä puuttuukin jotakin.

135
00:11:55,770 --> 00:11:59,510
Varmennetta ei ole. Koska ei ole 
tarvetta autentikoida uudelleen

136
00:11:59,510 --> 00:12:04,620
varmenteen avulla, koska asiakas ja 
palvelin juttelivat aiemmin, joten

137
00:12:04,620 --> 00:12:09,099
asiakas tietää tarkistaneensa jo
palvelimen varmenteen,

138
00:12:09,099 --> 00:12:12,819
ja mikäli palvelin pystyy purkamaan
istuntolipun salauksen, se tarkoittaa,

139
00:12:12,819 --> 00:12:17,879
että palvelin on se joksi itseään väittää.
Joten kaksi avainosuutta yhdistetään.

140
00:12:17,879 --> 00:12:22,860
Sitten ne yhdistetään PSK:n kanssa, jotta
saadaan avain, jolla salataan loput

141
00:12:22,860 --> 00:12:29,580
yhteydestä. On olemassa vielä 
yksi uusi ominaisuus, jonka

142
00:12:29,580 --> 00:12:34,701
TLS 1.3 istunnon jatkaminen tuo
mukanaan. Se on se seikka, että se

143
00:12:34,701 --> 00:12:40,830
mahdollistaa kättelyn ilman edestakaista
matkaa (0-RTT). Muistutuksena,

144
00:12:40,830 --> 00:12:47,280
kaikki kättelyt 1.3:ssa koostuvat enim-
mäkseen yhdestä edestakaisesta matkasta.

145
00:12:47,280 --> 00:12:52,140
TSL 1.2 istunnon jatkamiset voivat olla
minimissään yhden edestakaisen matkan.

146
00:12:52,140 --> 00:12:58,331
TLS 1.3 istunnon jatkamiset voivat toimia
ilman edestakaista matkaa. Kuinka 0-RTT

147
00:12:58,331 --> 00:13:04,210
kättely toimii? Ajatellaanpa. 
Alkuun on PSK.

148
00:13:04,210 --> 00:13:10,119
Pre-shared Key.
Asiakas voi käyttää sitä salaamaan

149
00:13:10,119 --> 00:13:15,680
tämän alkudatan, jonka haluaa lähettää
palvelimelle. Joten asiakas avaa

150
00:13:15,680 --> 00:13:20,439
yhteyden palvelimeen, johon
on jo aiemmin ollut yhteydessä,

151
00:13:20,439 --> 00:13:25,349
ja lähettää "Client Hello":n, 
istuntolipun,

152
00:13:25,349 --> 00:13:29,920
avainosuuden Diffie-Hellmaniin ja 
alkudatan. Alkudata on

153
00:13:29,920 --> 00:13:34,410
blob sovellusdataa - se voi olla
esimerkiksi HTTP-pyyntö -

154
00:13:34,410 --> 00:13:39,409
salattuna PSK:lla.
Palvelin vastaanottaa tämän,

155
00:13:39,409 --> 00:13:45,369
purkaa istuntolipun, löytää PSK:n,
käyttää PSK:ta purkamaan

156
00:13:45,369 --> 00:13:50,770
alkudatan ja jatkaa sitten normaalisti:
yhdistää avainosuudet, lisää PSK:n,

157
00:13:50,770 --> 00:13:55,270
luo uuden avaimen lopulle
yhteydelle ja jatkaa yhteyttä.

158
00:13:55,270 --> 00:14:00,289
Eli mitä tässä tapahtui? Voimme lähettää
sovellusdataa välittömästi yhteyden

159
00:14:00,289 --> 00:14:05,339
avaamisen yhteydessä. Tämä tarkoittaa,
että poistimme suorituskyvyn

160
00:14:05,339 --> 00:14:11,320
yleiskustannukset TLS:ssä.

161
00:14:11,320 --> 00:14:16,460
0-RTT kättelyissä on kuitenkin kaksi
vaaran paikkaa, jotka ovat teoriassa

162
00:14:16,460 --> 00:14:22,540
mahdoton poistaa. Yksi on se, että 
se kiva asia joka tuli PSK ECDHE moodin

163
00:14:22,540 --> 00:14:27,829
mukana, se jossa käytetään Diffie-
Hellmania istunnon jatkamiseen

164
00:14:27,829 --> 00:14:33,040
1.3:ssa, ei auta 0-RTT datan kanssa.

165
00:14:33,040 --> 00:14:38,620
Käytämme Diffie-Hellmania kun
saavumme dian vihreään laatikkoon.

166
00:14:38,620 --> 00:14:44,000
Tietysti alkudata on salattu vain 
PSK:lla. Mietitäänpä taas

167
00:14:44,000 --> 00:14:49,150
hyökkääjää. Hyökkääjä jollain keinolla
varasti istuntolippumme salausavaimet.

168
00:14:49,150 --> 00:14:54,969
Se voi katsoa "Client Hello":a, purkaa 
istuntolipun, saada PSK:n,

169
00:14:54,969 --> 00:15:00,029
käyttää PSK:ta purkamaan
alkudatan salauksen.

170
00:15:00,029 --> 00:15:05,350
Se voi tehdä tämän kaapatustakin liiken-
teestä, jos saa istuntolipun myöhemmin.

171
00:15:05,350 --> 00:15:11,519
Siispä alkudata ei ole jatkosuojattu
istuntolipun avainten suhteen.

172
00:15:11,519 --> 00:15:16,679
Pelkkä PSK on kuitenkin hyödytön, jos 
käytämme Diffie-Hellmania palvelimen

173
00:15:16,679 --> 00:15:23,020
vastauksessa. Se on hyödyllinen ainoastaan
asiakkaan ensimmäisen viestin kohdalla.

174
00:15:23,020 --> 00:15:28,340
Kerrataanpa. Tässä on
paljon asiaa. TLS 1.2 toi

175
00:15:28,340 --> 00:15:33,379
jatkosuojauksen sen varalle, että
varmenteen yksityinen avain

176
00:15:33,379 --> 00:15:39,119
joutuisi vääriin käsiin, jo kauan sitten
käyttämällä ECDHE moodeja.

177
00:15:39,119 --> 00:15:45,030
Siis 1.2 yhteydet voivat olla aina jatko-
suojattuja varmenteen murtamisen

178
00:15:45,030 --> 00:15:50,300
varalta. TLS 1.3 toimii samoin.

179
00:15:50,300 --> 00:15:55,090
Ei ole moodia, joka olisi jatkosuojaamaton
varmenteen murtamisen varalta.

180
00:15:55,090 --> 00:16:01,279
Mutta, jos ajatellaan mitä
istuntolipun avaimelle voi käydä:

181
00:16:01,279 --> 00:16:06,000
TLS 1.2 ei koskaan tarjoa jatkosuojausta.

182
00:16:06,000 --> 00:16:11,149
TLS 1.2:ssa istuntolipun avaimen
murtaminen johtaa aina kykyyn passiivisesti

183
00:16:11,149 --> 00:16:15,819
murtaa tulevien jatkettujen
istuntojen salaus.

184
00:16:15,819 --> 00:16:22,689
1.3:ssa sen sijaan, jos käytämme
PSK ECDHE:tä, ainoastaan alkudatan salaus

185
00:16:22,689 --> 00:16:28,270
voidaan purkaa käyttämällä
pelkästään istuntolipun avainta.

186
00:16:28,270 --> 00:16:33,199
Kuten sanoin, vaaran paikkoja on kaksi.

187
00:16:33,199 --> 00:16:39,329
Toinen se, että 0-RTT dataa voidaan
käyttää toistohyökkäyksessä.

188
00:16:39,329 --> 00:16:45,449
Olkoon tilanne tämä: alkudata
sisältää dataa, joka on jollain tapaa

189
00:16:45,449 --> 00:16:51,709
autentikoitu. Se voi olla HTTP-
pyyntö, joka sisältää evästeitä.

190
00:16:51,709 --> 00:16:58,070
Tuo HTTP-pyyntö jollain
tapaa suorittaa transaktion,

191
00:16:58,070 --> 00:17:03,150
okei? Ehkä se on tilisiirto. Ohjeistaa
palvelinta tekemään jotain. Hyökkääjä

192
00:17:03,150 --> 00:17:07,580
haluaa toistaa tuota tapahtumaa. Se ei
tietenkään voi purkaa sen salausta

193
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

194
00:17:13,149 --> 00:17:17,689
muokata sitä, koska se on TLS-suojattu.
Mutta se voi kaapata salatun

195
00:17:17,689 --> 00:17:23,069
viestin ja lähettää sen uudelleen

196
00:17:23,069 --> 00:17:27,900
palvelimelle. Jos palvelimia on yksi,
tähän on helppo ratkaisu.

197
00:17:27,900 --> 00:17:32,520
Pidä kirjaa nähdyistä viesteistä
ja ajattele kutakuinkin näin:

198
00:17:32,520 --> 00:17:37,500
"Ei. Tämä näyttää täsmälleen samalta kuin
mitä sain aiemmin." Mutta jos esimerkiksi,

199
00:17:37,500 --> 00:17:42,270
kuten Cloudflare, pyörität useita data-
keskuksia ympäri maailmaa, et voi pitää

200
00:17:42,270 --> 00:17:47,650
yhdenmukaisia tiloja jatkuvasti, reaali-
ajassa, kaikkien koneiden välillä. Olisi

201
00:17:47,650 --> 00:17:52,370
eri koneita, jotka tämän viestin
saatuaan ajattelisivat näin:

202
00:17:52,370 --> 00:17:57,530
"Toki, minulla on istuntolipun avain,
dekryptaan PSK:n, käytän PSK:ta,

203
00:17:57,530 --> 00:18:02,080
dekryptaan alkudatan, löydän sieltä jotain
ja suoritan sen mitä se käskee minun

204
00:18:02,080 --> 00:18:07,510
tehdä." Tämä ei tietenkään ole suotavaa.

205
00:18:07,510 --> 00:18:13,010
Yksi TLS.n tarjoama vastatoimi on,
että asiakas lähettää samassa

206
00:18:13,010 --> 00:18:18,689
paketissa arvon, joka kertoo
millisekunteina, kuinka kauan sitten sain

207
00:18:18,689 --> 00:18:23,790
haltuuni istuntolipun. Palvelin katsoo
sitä arvoa, ja jos se ei täsmää

208
00:18:23,790 --> 00:18:29,080
sen omaan näkemykseen tästä 
tiedosta, se hylkää viestin.

209
00:18:29,080 --> 00:18:34,020
Tämä tarkoittaa, että jos hyökkääjä
kaappaa viestin ja 10 s myöhemmin

210
00:18:34,020 --> 00:18:40,000
yrittää toistohyökkäystä, ajat eivät
täsmää ja palvelin hylkää viestin.

211
00:18:40,000 --> 00:18:44,510
Tämä ei kuitenkaan ole täysi ratkaisu,
sillä tarpeeksi nopea hyökkääjä voi

212
00:18:44,510 --> 00:18:50,369
silti tehdä toistohyökkäyksiä.
Eli, palvelin voi ainoastaan joko

213
00:18:50,369 --> 00:18:55,970
hyväksyä 0-RTT datan
tai hylätä sen.

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

215
00:19:00,570 --> 00:19:05,540
"Server Hello"-viesti kertoo (asiakkaalle)
hyväksyttiinkö vai hylättiinkö se.

216
00:19:05,540 --> 00:19:09,759
Ja asiakas jatkaa alkudatan lähettämistä
kunnes se saa "Server Hello"-viestin.

217
00:19:09,759 --> 00:19:15,960
Tässä on kilpailu. Joten palvelimen täytyy
sokkona päättää "Otanko 0-RTT dataa vastaan

218
00:19:15,960 --> 00:19:20,990
vai hylkäänkö sen kaiken?" Jos se ottaa
sen, ja sitten huomaa sen olevan jotain

219
00:19:20,990 --> 00:19:26,750
mitä se ei voi prosessoida koska "Herran-
jestas, täällä on HTTP POST, joka käskee

220
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."

221
00:19:32,470 --> 00:19:37,060
Palvelimen täytyy saada jonkinlainen
vahvistus. Hyvä uutinen on se, että jos

222
00:19:37,060 --> 00:19:40,600
palvelin odottaa "Finished" 
viestiä... Palvelin lähettää

223
00:19:40,600 --> 00:19:45,280
"Server Hello":n, "Finished":n ja 
odottaa asiakkaan vastaavaa.

224
00:19:45,280 --> 00:19:51,050
Kun asiakkaan oma saapuu, se tarkoittaa,
ettei kyseessä ollut toistohyökkäys,

225
00:19:51,050 --> 00:19:54,950
sillä tuo "Finished" viesti 
viimeistelee koko kättelyn

226
00:19:54,950 --> 00:19:59,769
yhdessä tietyn satunnaisarvon kanssa,
jonka palvelin lähetti. Kyseessä ei siis

227
00:19:59,769 --> 00:20:04,380
voi olla toistohyökkäys. Eli nämä ovat
palvelimen vaihtoehdot: se voi hyväksyä

228
00:20:04,380 --> 00:20:08,780
alkudatan ja jos se on jotain mikä
ei ole idempotenttia, jotain mikä on

229
00:20:08,780 --> 00:20:14,610
vaarallista jos se toistetaan, se voi
yksinkertaisesti odottaa vahvistusta.

230
00:20:14,610 --> 00:20:18,850
Mutta se tarkoittaa, että se on laitettava
välimuistiin, ja tässä on riski, mikäli

231
00:20:18,850 --> 00:20:25,580
hyökkääjä lähettää HTTP POST:n valtavalla 
rungolla tarkoituksenaan täyttää muisti.

232
00:20:25,580 --> 00:20:31,840
Tajusimme voivamme auttaa tässä,
jos kirjoitamme istuntolippuihin,

233
00:20:31,840 --> 00:20:37,240
mikä on maksimimäärä alkudataa,
jonka asiakas voi lähettää.

234
00:20:37,240 --> 00:20:41,500
Jos huomaamme jonkun lähettävän
enemmän, kyseessä on hyökkääjä ja

235
00:20:41,500 --> 00:20:47,499
katkaisemme yhteyden, tyhjennämme
välimuistin vapauttaaksemme muistia.

236
00:20:47,499 --> 00:20:52,969
Mutta. Joka tapauksessa. Vastatoimista 
huolimatta, ellemme pysty pitämään

237
00:20:52,969 --> 00:20:58,780
yhtenäistä maailmanlaajuista tilaa 
palvelimien välillä, meidän täytyy kertoa

238
00:20:58,780 --> 00:21:03,429
sovellukselle toistohyökkäyksen mahdol-
lisuudesta. Spesifikaatio tietää tämän.

239
00:21:03,429 --> 00:21:08,150
TLS 1.3 spesifikaatio YKSISELITTEISESTI toteaa

240
00:21:08,150 --> 00:21:14,420
protokollien EI tule käyttää 
0-RTT:tä ilman profiilia, joka

241
00:21:14,420 --> 00:21:19,159
määrittelee sen käytön. Eli tarkoittaa
"tietämättä mitä ne ovat tekemässä".

242
00:21:19,159 --> 00:21:24,419
Tämä tarkoittaa, että TLS-pinon APIen
täytyy tehdä oletuksena 1-RTT,

243
00:21:24,419 --> 00:21:30,360
johon toistohyökkäykset eivät
toimi, ja sitten antaa palvelimen

244
00:21:30,360 --> 00:21:35,571
kutsua joitakin API:a hylätäkseen 
tai odottaakseen vahvistusta,

245
00:21:35,571 --> 00:21:41,470
ja antaa asiakkaan päättää, mitä tähän
vaaralliseen toistohyökkäysalttiiseen

246
00:21:41,470 --> 00:21:46,040
dataan tulee. Tämä riippuu

247
00:21:46,040 --> 00:21:49,840
protokollasta, mutta entäpä 
lempiprotokollamme? Entäpä

248
00:21:49,840 --> 00:21:55,329
HTTP? HTTP:n pitäisi olla
helppo. HTTP-spesifikaatio,

249
00:21:55,329 --> 00:22:00,759
käykää vaikka lukemassa, sanoo:
"GET-pyynnöt ovat idempotentteja,

250
00:22:00,759 --> 00:22:06,149
niiden ei tule muuttaa mitään palveli-
mella". Selvä! Sallimme nyt ainoastaan

251
00:22:06,149 --> 00:22:10,670
GET-pyynnöt alkudatassa, koska niitä ei
voi hyödyntää toistohyökkäyksissä!

252
00:22:10,670 --> 00:22:16,640
Jes! Ei. (huokaus) Internetissä on 
takuuvarmasti palvelin,

253
00:22:16,640 --> 00:22:23,020
jossa on jotain sen kaltaista kuin
“send-money.php?to=filippo&amount=this”

254
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,

255
00:22:28,870 --> 00:22:33,510
ja sitten käyttää tätä toistohyök-
käyksessä toista palvelinta vastaan, se

256
00:22:33,510 --> 00:22:38,780
suoritetaan kahdesti.
Ja se ei käy päinsä.

257
00:22:38,780 --> 00:22:43,300
Mitä siis voidaan tehdä?

258
00:22:43,300 --> 00:22:46,890
Teemme kompromisseja!

259
00:22:46,890 --> 00:22:51,779
Jos tunntet sovelluksesi, voit tehdä hyvin
spesifejä kompromisseja. Esimerkiksi

260
00:22:51,779 --> 00:22:57,020
Google on ajanut QUIC:iä
0-RTT:llä hyvinkin pitkään.

261
00:22:57,020 --> 00:23:02,200
Uskoakseni 3 vuotta? Se tarkoittaa, että
he tuntevat sovelluksensa oikein hyvin.

262
00:23:02,200 --> 00:23:07,419
Ja he tietävät, ettei heillä ole
"send-money.php" päätepisteitä.

263
00:23:07,419 --> 00:23:12,710
Mutta jos olet kuin Cloudflare, joka
hallinnnoi suurta määrää sovelluksia,

264
00:23:12,710 --> 00:23:17,720
et voi tehdä noin laajoja olettamuksia,
ja täytyy sen sijaan yrittää

265
00:23:17,720 --> 00:23:22,570
löytää kultainen keskitie. Me 
saattaisimme esimerkiksi päättää

266
00:23:22,570 --> 00:23:28,730
sallia GET-pyynnöt ainoastaan
juurihakemistoon. Eli "GET /",

267
00:23:28,730 --> 00:23:33,200
mikä saattaisi tuoda eniten hyötyä, sillä
ehkä suurin osa yhteyksistä alkaa noin,

268
00:23:33,200 --> 00:23:38,710
ja se on vähiten todennäköinen
aiheuttamaan hankaluuksia.

269
00:23:38,710 --> 00:23:43,140
Mietimme edelleen kuinka sovellamme
tätä sovelluksiin. Eli jos tiedossasi

270
00:23:43,140 --> 00:23:48,199
on sovellus, joka tulisi kärsimään 
jostain noin yksinkertaisesta,

271
00:23:48,199 --> 00:23:53,840
lähetä meille sähköpostia. Mutta 
itse asiassa, jos sinulla on noin

272
00:23:53,840 --> 00:23:59,160
haavoittuvainen sovellus, minulla
on huonoja uutisia. Thai Duong et. al.

273
00:23:59,160 --> 00:24:04,150
osoittivat, että tämän päivän selaimet,
ilman TLS 1.3:a tai muutakaan,

274
00:24:04,150 --> 00:24:09,740
toistavat HTTP-pyyntöjä
verkkovirheiden sattuessa.

275
00:24:09,740 --> 00:24:15,670
Ja ne toistavat ne hiljaisesti.
Eli lopputulema ei välttämättä ole

276
00:24:15,670 --> 00:24:21,990
huonompi kuin nykytila. Selvä.
Näen, että kaikki alkavat olla

277
00:24:21,990 --> 00:24:27,959
levottomia ja ajattelevat
"Kryptografit ovat taas asialla!

278
00:24:27,959 --> 00:24:32,740
He tekevät tarvitsemastamme turvallisuus-
protokollasta tarpeettoman monimutkaisen

279
00:24:32,740 --> 00:24:38,889
turvatakseen työpaikkansa
seuraavaksi 15 vuodeksi!" Eikö?

280
00:24:38,889 --> 00:24:44,479
Ei. Ei. Voin itseasiassa taata, että

281
00:24:44,479 --> 00:24:49,709
yksi suurista muutoksista, mielestäni
suurempi kuin edestakaiset matkat 1.3:ssa,

282
00:24:49,709 --> 00:24:54,770
on, että kaikkea punnitaan saadun hyödyn
ja sen aiheuttaman monimutkaisuuden

283
00:24:54,770 --> 00:24:59,180
kannalta. Ja vaikka 0-RTT pääsi jatkoon

284
00:24:59,180 --> 00:25:02,630
valtaosa ei päässyt.

285
00:25:02,630 --> 00:25:07,890
Nick: Selvä. Kiitos Filippo. Toimiiko
mikrofonini? Kuuletteko minut? Selvä.

286
00:25:07,890 --> 00:25:13,640
TLS 1.3:n ollessa iteraatio TLS:stä
mekin katsoimme taaksepäin, tai,

287
00:25:13,640 --> 00:25:18,120
"me", jotka olemme ihmiset jotka tutkivat
TLS:ää, katsoimme taaksepäin ja

288
00:25:18,120 --> 00:25:22,770
kertasimme olemassa olevia TLS 1.2:n omi-
naisuuksia, jotka vaikuttivat järkeviltä

289
00:25:22,770 --> 00:25:27,439
aikanaan ja päätimme, oliko kompleksisuus
tai vaara, jonka nämä TLS:n ominaisuudet tai

290
00:25:27,439 --> 00:25:32,349
protokollat tai primitiivit toivat mukanaan

291
00:25:32,349 --> 00:25:37,739
järkeviä säilyttää. Ja yksi iso,
joka sattui prosessin alussa on

292
00:25:37,739 --> 00:25:43,790
"staattinen RSA" moodi. Näin TLS on
toiminut SSL:n ajoista lähtien.

293
00:25:43,790 --> 00:25:48,179
Sen sijaan, että käytettäisiin Diffie-
Hellmania yhteisen avaimen luontiin,

294
00:25:48,179 --> 00:25:52,320
asiakas luo oman jaetun avaimensa, ja 
salaa sen palvelimen varmenteen

295
00:25:52,320 --> 00:25:56,570
julkisella avaimella, joka on
RSA-avain, ja lähettää sen sitten

296
00:25:56,570 --> 00:26:00,770
sellaisenaan palvelimelle. Ja
palvelin sitten käyttää omaa

297
00:26:00,770 --> 00:26:04,650
yksityistä avaintaan purkamaan salauksen
ja löytää yhteisen avaimen. Eli asiakas

298
00:26:04,650 --> 00:26:09,710
luo kaiken avainmateriaalin tässä
tapauksessa. Yksi asia on melko selvä

299
00:26:09,710 --> 00:26:13,650
tässä on, että jos varmenteen
yksityinen avain murretaan,

300
00:26:13,650 --> 00:26:18,149
vaikka vuosiakin myöhemmin, joku
jolla on tallenteet tapahtumista voi

301
00:26:18,149 --> 00:26:23,480
mennä taaksepäin ja purkaa tämän avain-
materiaalin ja siten koko keskustelun.

302
00:26:23,480 --> 00:26:28,419
Tämä poistettiin ihan TLS 1.3-prosessin
alkuvaiheessa, noin kaksi vuotta sitten.

303
00:26:28,419 --> 00:26:33,919
Joten suureksi yllätykseksemme,
ja kaikkien, jotka kuuluvat

304
00:26:33,919 --> 00:26:39,680
TLS:ää koskevaan sähköpostitus-
listaan, ihan vasta äskettäin,

305
00:26:39,680 --> 00:26:44,610
standardointiprosessin loppuvaiheessa,
kun TLS 1.3 oli melkein valmis,

306
00:26:44,610 --> 00:26:50,800
tämä sähköposti ilmestyi. Ja tämä on
Andrew Kennedyltä, joka työskentelee

307
00:26:50,800 --> 00:26:56,550
BITS:lle, mikä tarkoittaa pääpiirteittäin,
että hän työskentelee pankeille. Hän sanoo

308
00:26:56,550 --> 00:27:01,670
"RSA-avaintenvaihdon tuen lopettaminen
TLS 1.3:ssa aiheuttaa suuria ongelmia

309
00:27:01,670 --> 00:27:06,760
finanssilaitoksille, joista melkein kaikki
käyttävät TLS:ää sisäisesti ja joilla on

310
00:27:06,760 --> 00:27:12,510
suuria, turvallisuuskriittisiä investoin-
teja ulkopuoliseen TLS-dekryptaamiseen.

311
00:27:12,510 --> 00:27:17,810
"Ulkopuoliseen (3. osapuolen) TLS-dekryp-
taamiseen" hmm.. (naurua - aplodeja)

312
00:27:17,810 --> 00:27:23,490
Se todella kuulostaa kriittiseltä...
kriittiseltä jollekin, eikö?

313
00:27:23,490 --> 00:27:26,140
(naurua - aplodeja)
Eli...

314
00:27:26,140 --> 00:27:32,200
(naurua)
(aplodeja)

315
00:27:32,200 --> 00:27:37,039
Yksi valonpilkahduksista oli Kenny 
Patersonin vastaus tähän,

316
00:27:37,039 --> 00:27:41,680
joka kuului näin: "Minun näkemykseni
pyyntöäsi koskien: ei.

317
00:27:41,680 --> 00:27:44,920
Perustelu: Yritämme rakentaa TURVALLISEM-
PAA internetiä." Korostus

318
00:27:44,920 --> 00:27:47,350
on oma lisäykseni, mutta
hän varmasti tarkoitti sitä.

319
00:27:47,350 --> 00:27:54,100
(aplodeja)

320
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

321
00:27:58,840 --> 00:28:04,460
vaikeaa heidän järjestelmänsä
debuggaaminen on. Tämä on yksinkertaista..

322
00:28:04,460 --> 00:28:09,270
Ilmeisesti pankkiympäristössä. Nuo
ovat eri kytkimiä, reitittimiä,

323
00:28:09,270 --> 00:28:14,480
väliohjelmistoja, web-sovelluksia
ja kaikki keskustelevat TLS:llä.

324
00:28:14,480 --> 00:28:19,730
Tämän keskustelun jälkeen
päädyimme kompromissiin.

325
00:28:19,730 --> 00:28:24,160
Protokollan vaarantamisen
sijaan Matthew Green

326
00:28:24,160 --> 00:28:28,900
opetti heille, kuinka käyttää Diffie-
Hellmania väärin. Lopulta he kykenivät

327
00:28:28,900 --> 00:28:33,110
siihen, mitä halusivat ilman,
että me - tai kukaan muu

328
00:28:33,110 --> 00:28:36,780
akateemisessa yhteisössä tai 
TLS-yhteisössä - palautti

329
00:28:36,780 --> 00:28:41,720
TLS:ään tämän turvattoman osan.

330
00:28:41,720 --> 00:28:45,580
Jos haluat lukea tämän, se kertoo
kuinka tähän pystytään. Joka tapauksessa

331
00:28:45,580 --> 00:28:49,970
- emme laittaneet sitä takaisin.
Kiteytettynä, älkää tehkö näin!

332
00:28:49,970 --> 00:28:54,300
(aplodeja)

333
00:28:54,300 --> 00:29:00,100
Eli tapoimme staattisen RSA:n, ja mitä
muuta tapoimme? No, kun katsotaan

334
00:29:00,100 --> 00:29:03,769
taaksepäin hyötyihin ja haittoihin,
TLS 1.2 käyttää tiettyjä primitiivejä,

335
00:29:03,769 --> 00:29:08,519
jotka vain eivät ole
kestäneet ajan hammasta.

336
00:29:08,519 --> 00:29:12,130
RC4 jonosalain. Poissa!
(aplodeja)

337
00:29:12,130 --> 00:29:14,790
3DES (Triple DES) lohkosalain. Poissa!
(aplodeja)

338
00:29:14,790 --> 00:29:21,529
MD5, SHA1... molemmat poissa. Yo!
(jatkuvia aplodeja)

339
00:29:21,529 --> 00:29:26,480
On vielä rakennelmia, jotka...
peruslohkosalainrakennelmia,

340
00:29:26,480 --> 00:29:31,640
jotka ovat poissa: AES-CBC.
Poissa. RSA-PKCS1-1.5,

341
00:29:31,640 --> 00:29:36,810
tämä on tiedetty ongelmalliseksi
jo vuodesta 1998, myöskin poissa!

342
00:29:36,810 --> 00:29:41,770
Myös muita ominaisuuksia, kuten kompressio
ja uudellenneuvottelu, on poistettu.

343
00:29:41,770 --> 00:29:47,130
Jälkimmäisen korvasi hyvin kevyt "avaimen
päivitys"-mekanismi. Siis TLS 1.3:ssa

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

345
00:29:52,490 --> 00:29:58,030
haavoittuvuksista, joita saatatte
tunnistaa, ovat mahdottomia TLS 1.3:ssa.

346
00:29:58,030 --> 00:30:04,010
(aplodeja)

347
00:30:04,010 --> 00:30:09,149
TLS 1.3:n filosofia monessa kohtaa
on yksinkertaistaa ja lujittaa

348
00:30:09,149 --> 00:30:14,549
mahdollisimman paljon. Tästä on 
useita pieniä esimerkkitapauksia.

349
00:30:14,549 --> 00:30:18,680
Osa tämän julkaisun kirjoittajista
saattaa löytyä yleisöstä. Oli tapa

350
00:30:18,680 --> 00:30:24,030
käytää lohkosalaimia itse 
tallennekerroksella tavalla,

351
00:30:24,030 --> 00:30:27,640
joka ei ollut niin kestävä kuin se
voisi olla. Se on korvattu paljon

352
00:30:27,640 --> 00:30:32,340
yksinkertaisemmalla tavalla.
TLS 1.2:ssa oli tällainen

353
00:30:32,340 --> 00:30:37,520
erikoinen "Catch 22", jossa
salaimen neuvottelua suojaa

354
00:30:37,520 --> 00:30:41,810
"Finished"-viesti, joka on viestin
autentikointikoodi, mutta

355
00:30:41,810 --> 00:30:47,020
tuon koodin algoritmi päätettiin
salainneuvottelussa, joten

356
00:30:47,020 --> 00:30:53,090
siinä oli tällainen takaisinsyöttö-
efekti. Hyökkäykset kuten FREAK, LogJam ja

357
00:30:53,090 --> 00:30:59,300
CurveSwap onnistuivat hyödyntämään näitä
alentaakseen yhteyksien turvallisuuksia.

358
00:30:59,300 --> 00:31:02,669
Tätä tapahtui ihan käytännössä.
Syy on, että näitä salausalgoritmien

359
00:31:02,669 --> 00:31:06,980
joukkoja kättelyssä ei ole
digitaalisesti allekirjoitettu

360
00:31:06,980 --> 00:31:11,649
yksityisellä vaimella. Tämä muutettiin
TLS 1.3:ssa. Kaikki allekirjoituksen

361
00:31:11,649 --> 00:31:16,129
yläpuolella oleva on
allekirjoitettu. Tämä on hienoa!

362
00:31:16,129 --> 00:31:21,290
Mitä muuta muutimme? Tai, mitä
muuta TLS 1.3 muutti verrattuna

363
00:31:21,290 --> 00:31:27,860
TLS 1.2:een? Vähemmän, mutta parempia
valintoja. Kryptografiassa paremmat

364
00:31:27,860 --> 00:31:33,410
valinnat tarkoittavat aina vähemmän
valintoja. Nyt on tietyt ehdokkaat

365
00:31:33,410 --> 00:31:36,920
käyrille ja äärellisille kunnille, joita
voi käyttää. Ei mielivaltaisia palvelimen

366
00:31:36,920 --> 00:31:41,949
keksimiä DH-ryhmiä, ei mielivaltaisia
käyriä. Ja tämä sopivien parametrien listan

367
00:31:41,949 --> 00:31:47,940
karsiminen, johtaa siihen
että 1-RTT toimii niin usein.

368
00:31:47,940 --> 00:31:51,960
Kuten Filippo sanoi,
asiakkaan täytyy arvata

369
00:31:51,960 --> 00:31:56,540
mitä avaimenmuodostus-
metodeja palvelin tukee,

370
00:31:56,540 --> 00:32:01,199
ja lähettää sopiva avainosuus. Jos on
olemassa lyhyt lista pelkästään turvallisia

371
00:32:01,199 --> 00:32:05,599
vaihtoehtoja, tätä tapahtuu
useammin. Eli, kun konfiguroit

372
00:32:05,599 --> 00:32:10,760
TLS-palvelintasi, se ei enää näytä
monimutkaiselta pikaruokalistalta,

373
00:32:10,760 --> 00:32:15,690
vaan enemmänkin häämenulta. Ota yksi
jokaisesta kategoriasta ja lopputulos on

374
00:32:15,690 --> 00:32:21,970
herkullisempikin. Voit tutkia tätä
Wiresharkissakin, sekin on yksinkertaista.

375
00:32:21,970 --> 00:32:27,800
Salausalgoritmit, laajennukset,
käyrät ja voit jatkaa siitä.

376
00:32:27,800 --> 00:32:33,301
Filippo: TLS 1.3 korjasi myös
sen, mikä mielestäni oli yksi

377
00:32:33,301 --> 00:32:37,441
suurimpia suunnitteluvirheitä
TLS 1.2:ssa. Puhuimme siitä,

378
00:32:37,441 --> 00:32:43,410
miten jatkosuojaus toimii istuntojen
jatkamisessa 1.2:ssa ja 1.3:ssa.

379
00:32:43,410 --> 00:32:49,199
Mutta TLS 1.2 on vieläkin ongelmallisempi.
TLS 1.2 käärii istuntolippujen

380
00:32:49,199 --> 00:32:55,679
sisään vanhan yhteyden
varsinaisen pääsalaisuuden.

381
00:32:55,679 --> 00:33:02,509
Eli se ottaa varsinaiset alkuperäisen yhteyden 
liikenteen salaamiseen käytetyt avaimet,

382
00:33:02,509 --> 00:33:07,860
salaa ne istuntolipun avaimella, ja
lähettää ne asiakkaalle, jotta se voi

383
00:33:07,860 --> 00:33:13,619
lähettää ne takaisin ensi kerralla.
Puhuimme riskistä, että hyökkääjä saa

384
00:33:13,619 --> 00:33:18,139
istuntolipun avaimet haltuunsa,
dekryptaa instuntoliput ja murtaa

385
00:33:18,139 --> 00:33:23,859
jatkosuojauksen ja
dekryptaa jatketut istunnot.

386
00:33:23,859 --> 00:33:29,780
TLS 1.2:ssa asiat ovat vielä huonommin.
Jos hyökkääjä dekryptaa istuntoliput, se

387
00:33:29,780 --> 00:33:35,950
voi takaperoisesti dekryptata
koko alkuperäisen

388
00:33:35,950 --> 00:33:42,090
jatkamattoman istunnon. Ja
tämä on täysin tarpeetonta.

389
00:33:42,090 --> 00:33:46,770
Meillä on tiivistefunktioita, yksisuun-
taisia funktioita, joihin laitetaan syöte

390
00:33:46,770 --> 00:33:52,990
ja saadaan jotain, josta ei päästä
takaisin alkuperäiseen. Näin 1.3 tekee.

391
00:33:52,990 --> 00:33:58,579
1.3. johtaa uusia, tuoreita avaimia
seuraavaa istuntoa varten

392
00:33:58,579 --> 00:34:04,090
ja käärii ne istuntolipun sisään, jotta
niistä saadaan PSK. Eli vaikka

393
00:34:04,090 --> 00:34:09,439
dekryptaisit 1.3 istuntolipun,
voit yrittää murtaa

394
00:34:09,439 --> 00:34:13,619
seuraavaa yhteyttä ja olemme nähneet,
että saatat pystyä dekryptaamaan

395
00:34:13,619 --> 00:34:18,949
ainoastaan alkudatan, tai koko yhteyden,
käytetystä moodista riippuen. Mutta

396
00:34:18,949 --> 00:34:25,959
et mitenkään voi dekryptata alkuperäistä
jatkamattoman istunnon yhteyttä.

397
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

398
00:34:31,729 --> 00:34:36,760
ihmetytti minua. Koko "käytetään pää-
salaisuutta" saataa johtua siitä, että

399
00:34:36,760 --> 00:34:41,779
istuntoliput olivat pelkkä laajennus 
1.2:ssa, mitä ne eivät ole 1.3:ssa.

400
00:34:41,779 --> 00:34:47,990
Mutta 1.2 lähettää "New Session
Ticket"-viestin alkuperäisen

401
00:34:47,990 --> 00:34:53,490
kättelyn alussa
- salaamattomana! Tarkoitan siis,

402
00:34:53,490 --> 00:34:58,670
salattuna istuntolipun avaimilla, mutta
ei nykyisen istunnon avaimilla.

403
00:34:58,670 --> 00:35:04,040
Eli mikä tahansa palvelin, joka tukee

404
00:35:04,040 --> 00:35:10,130
istuntolippuja, tulee kaikkien
yhteyksien alussa - vaikka

405
00:35:10,130 --> 00:35:14,670
istunnon jatkamista ei ikinä tapahtuisi -
lähettämään istuntolipun, joka ei ole

406
00:35:14,670 --> 00:35:18,820
muuta kuin sen yhteyden 
hetkelliset (katoavat) avaimet

407
00:35:18,820 --> 00:35:23,400
käärittynä istuntolipun 
avaimilla. Nyt, jos olet

408
00:35:23,400 --> 00:35:28,620
Maailmanlaajuinen pahantekijä,
joka haluaa suorittaa

409
00:35:28,620 --> 00:35:33,060
joukkovalvontaa ja haluaisit 
dekryptata jälkikäteen

410
00:35:33,060 --> 00:35:38,720
kaikki yhteydet, ja jotenkin saisit
käsiisi istuntolippujen avaimet,

411
00:35:38,720 --> 00:35:44,350
se mitä löytäisit kaikkien
TLS 1.2-yhteyksien alusta, on

412
00:35:44,350 --> 00:35:49,830
istuntoavaimet salattuna
istuntolipun avaimilla.

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

414
00:35:55,580 --> 00:35:59,420
Ainoa asia, jonka voisit passivisesti,
siis jälkikäteen, dekryptata

415
00:35:59,420 --> 00:36:04,230
on alkudata. Et mitenkään voisi
dekryptata jatkamattomia yhteyksiä ja

416
00:36:04,230 --> 00:36:10,920
mitään mikä tulee 0-RTT:n jälkeen.

417
00:36:10,920 --> 00:36:12,840
Nick: Eli se on turvallisempi.
Lyhyesti sanottuna.

418
00:36:12,840 --> 00:36:15,710
Filippo: Toivon mukaan!
Nick: ...toivottavasti.

419
00:36:15,710 --> 00:36:20,670
Ja mistä tiedämme sen olevan turvallisempi?
Nämä turvallisuusparametrit ja turvallisuus-

420
00:36:20,670 --> 00:36:25,840
vaatimukset koskien TLS:ää on 
formalisoitu ja, toisin kuin aiemmissa

421
00:36:25,840 --> 00:36:30,310
TLS-versioissa, formalisointia 
harjoittavat akateemikot otettiin

422
00:36:30,310 --> 00:36:34,170
mukaan aiemmin. Useat julkaisut
ovat analysoineet tilakonetta

423
00:36:34,170 --> 00:36:40,120
ja TLS 1.3:n eri moodeja, ja
nämä ovat auttaneet paljon

424
00:36:40,120 --> 00:36:45,360
protokollan kehityksessä.

425
00:36:45,360 --> 00:36:50,570
Kuka siis oikeastaan kehittää
TLS 1.3:a? No, kyseessä

426
00:36:50,570 --> 00:36:54,730
on järjestö nimeltä IETF, joka tulee 
sanoista Internet Engineering Taskforce.

427
00:36:54,730 --> 00:36:59,760
Se on ryhmä vapaaehtoisia, jotka tapaavat
kolmesti vuodessa, joilla on postituslistoja

428
00:36:59,760 --> 00:37:03,461
ja he väittelevät loputtomasti näistä
protokollista. He määrittelevät internetissä

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

430
00:37:07,910 --> 00:37:13,250
on twiittini syyskuulta 2013 - oli
toivomuslista koskien TLS 1.3:a.

431
00:37:13,250 --> 00:37:19,920
Ja sen jälkeen IETF julkaisi
ensimmäisen version...

432
00:37:19,920 --> 00:37:24,630
Dokumentit, jotka määrittelevät proto-
kollia tunnetaan nimellä RFC, ja

433
00:37:24,630 --> 00:37:29,200
ennen kuin jostakin tulee RFC, siitä käy-
tetään nimeä "Internet Draft". Eli

434
00:37:29,200 --> 00:37:34,330
aloitetaan Internet Draft 0:sta, ja sitä
iteroidaan, kunnes lopulta se joko

435
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

436
00:37:39,980 --> 00:37:46,080
huhtikuussa 2014, ja nykyinen
luonnos (18), jonka ajatellaan olevan

437
00:37:46,080 --> 00:37:51,590
melkein valmis, on vaiheessa jota
kutsutaan "Last Call":ksi IETF:ssä,

438
00:37:51,590 --> 00:37:57,330
julkaistiin vastikään lokakuussa.
Tietoturvallisuusympäristössä tällä

439
00:37:57,330 --> 00:38:02,400
aikavälillä on nähty todella monia
erilaisia hyökkäyksiä TLS:ää vastaan.

440
00:38:02,400 --> 00:38:07,860
Esim: Triple Handshake, POODLE, FREAK,
LogJam, DROWN (josta oli esitys aiemmin

441
00:38:07,860 --> 00:38:12,220
tänään), Lucky Microseconds, SLOTH.
Kaikki nämä eri akronyymit - joista

442
00:38:12,220 --> 00:38:15,550
ehkä olette tai ette ole kuullut -
ovat tapahtuneet kehitystyön aikana.

443
00:38:15,550 --> 00:38:21,380
Eli TLS 1.3 on kehittyvä
dokumentti, ja toivottavasti

444
00:38:21,380 --> 00:38:27,561
siitä tulee lyhyt. Tarkoitan
siis, että TLS 1.2 oli 79 sivua.

445
00:38:27,561 --> 00:38:32,521
Se on vähän vaikeaselkoinen, mutta lukekaa
toki jos kiinnostaa. TLS 1.3 sen sijaan,

446
00:38:32,521 --> 00:38:36,330
jos lopusta karsii ylimääräistä tavaraa
pois, tulee aika lähelle. Ja se on

447
00:38:36,330 --> 00:38:40,980
helppolukuisempi. Se on paljon tarkempi,
vaikka sieltä löytyykin kiinnostavia

448
00:38:40,980 --> 00:38:46,910
ominaisuuksia kuten 0-RTT istunnon jatka-
minen. Kuinka se käytännössä kirjoitetaan?

449
00:38:46,910 --> 00:38:52,810
Vastaus on... Github! Ja postituslista!
Eli, jos haluat lähettää pull pyynnön

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

451
00:38:59,020 --> 00:39:04,190
Ja kannattanee lähettää viesti
postituslistaan, jossa kuvailet

452
00:39:04,190 --> 00:39:09,300
muutoksiasi, jos haluat. Ehdottaisin,
jos joku haluaa osallistua - nyt on aika

453
00:39:09,300 --> 00:39:14,190
myöhäistä - onhan se "Last Call"-vaiheessa,
mutta postituslista on vielä avoinna.

454
00:39:14,190 --> 00:39:18,370
Olen työstänyt tätä useiden muiden
kanssa, Filippo mukaan lukien. Olimme

455
00:39:18,370 --> 00:39:23,230
osallisina luonnoksessa, työskennelleet
yli vuoden tämän parissa. Voitte käydä

456
00:39:23,230 --> 00:39:29,230
katsomassa Githubista ongelmat ja
näette, kuinka paljon työtä se on vaatinut.

457
00:39:29,230 --> 00:39:34,130
Luonnos on muuttunut
vuosien ja kuukausien varrella.

458
00:39:34,130 --> 00:39:38,620
Esim. luonnos 9:ssä oli tämä
monimutkainen puumalli

459
00:39:38,620 --> 00:39:43,550
kierrosavaimen laskennalle, tässä
näette "htk"... kaikki nämä eri asiat

460
00:39:43,550 --> 00:39:49,980
liittyivät TLS-kättelyn eri avaimiin.
Tämän inspiraation lähteenä oli QUIC,

461
00:39:49,980 --> 00:39:55,650
Googlen protokolla, jonka Filippo mainitsi
aiemmin, sekä julkaisu nimeltä "OPTLS".

462
00:39:55,650 --> 00:40:00,610
Ja siinä oli useita eri moodeja:
semistaattinen Diffie-Hellman ja tämä

463
00:40:00,610 --> 00:40:04,950
puumallinen avaintenlaskenta. Ajan 
mittaan tätä pelkistettiin tästä

464
00:40:04,950 --> 00:40:10,510
monimutkaisesta kaaviosta siihen, mitä
nyt käytämme TLS 1.3:ssa. Joka on hyvin

465
00:40:10,510 --> 00:40:16,330
yksinkertainen avaimenjohtamisalgoritmi.
Vaati paljon työtä päästä jostain suuresta

466
00:40:16,330 --> 00:40:21,670
johonkin näin pieneen. Mutta se onnistui!
Muita TLS 1.3:n kanssa sattuneita,

467
00:40:21,670 --> 00:40:27,230
kryptografisesti vähemmän
merkittäviä asioita, on

468
00:40:27,230 --> 00:40:32,550
nimeäminen! Jos joku on seurannut
kehitystä, TLS 1.3 ei välttämättä ole

469
00:40:32,550 --> 00:40:38,180
yksimielinen valinta tämän protokollan
nimeksi. Kuten Filippo mainitsi, 1.0,

470
00:40:38,180 --> 00:40:44,000
1.1, 1.2 ovat melko pieniä iteraatioita
jopa SSLv3:een verrattuna, kun taas

471
00:40:44,000 --> 00:40:49,071
TLS 1.3 on aika iso muutos.
Siispä nimelle on paljon

472
00:40:49,071 --> 00:40:54,950
vaihtoehtoja! Otetaanpa äänestys
kättä nostamalla. Kenen

473
00:40:54,950 --> 00:40:59,860
mielestä nimen pitäisi olla 1.3?
(nauraa)

474
00:40:59,860 --> 00:41:02,030
Kiitos Filippo! (Filippo nauraa)
Jep, eli aika suuri osa.

475
00:41:02,030 --> 00:41:07,840
Entäpä TLS 2? Ketään? Oho. Tämä
näyttää itse asiassa enemmältä kuin...

476
00:41:07,840 --> 00:41:12,940
Filippo: Muistakaa että SSLv2
on juttu! Ja se on kamala juttu!

477
00:41:12,940 --> 00:41:18,040
Nick: Ette halua sekoittaa sitä
meihin! No entä sitten TLS 4?

478
00:41:18,040 --> 00:41:22,520
Edelleen merkittävä osa ihmisiä...
Entäs TLS 2017? Noniin...

479
00:41:22,520 --> 00:41:25,780
Selvä. TLS 7 ketään? Okei...

480
00:41:25,780 --> 00:41:30,400
Filippo: TLS Millenium 2019 X?

481
00:41:30,400 --> 00:41:35,410
Kyllä! Myyty!
Nick: TLS Vista?

482
00:41:35,410 --> 00:41:38,860
(naurua) - (Nick ja Filippo nauravat)
(aplodeja)

483
00:41:38,860 --> 00:41:44,800
Nick: Paljon vaihtoehtoja! Mutta ihan
vain muistutuksena, muu maailma ei

484
00:41:44,800 --> 00:41:50,040
oikeastaan käytä nimeä TLS. Tässä on
Google trends, kiinnostus aikajanalla,

485
00:41:50,040 --> 00:41:55,300
kun vertaillaan "SSL vs. TLS". SSL on nimi,
jota suuri osa maailmasta käyttää. SSL:n

486
00:41:55,300 --> 00:42:00,240
korkein versio on versio 3, ja siinä on
syy miksi ihmiset ajattelivat, että

487
00:42:00,240 --> 00:42:05,210
"TLS 4" on hyvä ajatus. Koska: "Ihmiset
ovat hämillään: 3 on enemmän

488
00:42:05,210 --> 00:42:10,720
kuin 1.2 jne. jne."

489
00:42:10,720 --> 00:42:14,870
Tämä äänestys ei ollut ainoa. Tässä
on epävirallisia Twitter-äänestyksiä.

490
00:42:14,870 --> 00:42:20,030
"Mmm, pekonia!" oli hyvä.
52 % Ryan Hurstin äänestykessä.

491
00:42:20,030 --> 00:42:23,870
(naurua)

492
00:42:23,870 --> 00:42:28,130
Versionumerot TLS:ssä
ovat inhottava aihe.

493
00:42:28,130 --> 00:42:32,780
Esim. olemassa olevat versiot TLS:stä
- jos katsotaan verkon yli kulkevaa tietoa,

494
00:42:32,780 --> 00:42:37,640
ne eivät täsmää. Eli SSL 3
on 3.0, mikä täsmää.

495
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

496
00:42:43,720 --> 00:42:49,000
uskoakseni TLS 1.3:n 
luonnokseen 16 asti se oli 3.4

497
00:42:49,000 --> 00:42:53,761
Eli ikäänkuin pikkupäivitys
TLS 1.2:een, hyvin hämmentävää.

498
00:42:53,761 --> 00:42:58,511
Internetmittausten jälkeen pääteltiin,

499
00:42:58,511 --> 00:43:02,670
että moni palvelin, jos lähetät "Client
Hello":n arvolla "3.4", katkaisee yhteyden.

500
00:43:02,670 --> 00:43:07,960
Tämä on oikeasti todella huono juttu, se
estää selaimia alentamasta yhteyttä

501
00:43:07,960 --> 00:43:13,080
turvallisesti. Mitä palvelimen kuuluisi
tehdä, jos se näkee version joka on

502
00:43:13,080 --> 00:43:18,780
korkeampi kuin 3.3, on vain vastata "3.3"
sanoakseen: "Tämän parempaan en pysty".

503
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

504
00:43:24,880 --> 00:43:30,680
ja 3.4 neuvotellaan aliprotokollana.
Eli tämä on sotkuista.

505
00:43:30,680 --> 00:43:35,610
Eikö? Mutta punnitsemme hyötyjä moni-
mutkaisuutta vastaan, ja tämä on niitä

506
00:43:35,610 --> 00:43:39,640
missä palvelimien toimivuus painaa
enemmän kuin lisääntynyt monimutkaisuus,

507
00:43:39,640 --> 00:43:44,340
jonka tuo uuden asian lisääminen. Ja tämän
estämiseksi tulevaisuudessa

508
00:43:44,340 --> 00:43:48,820
David Benjamin ehdotti jotain nimeltä
GREASE, missä jokaiseen TLS-neuvottelun

509
00:43:48,820 --> 00:43:53,920
osaan tulee, asiakkaana, lisätä
jotain satunnaista tavaraa,

510
00:43:53,920 --> 00:43:56,980
jotta palvelimet tottuvat
näkemään asioita, jotka eivät ole

511
00:43:56,980 --> 00:44:01,050
versioita, joihin ne ovat tottuneet.
Eli, 0x8a8a. Se on GREASE-d!

512
00:44:01,050 --> 00:44:06,320
Filippo: Se on ihan todellinen asia!
Se on todellinen hyvin hyödyllinen asia!

513
00:44:06,320 --> 00:44:08,760
Nick: Tämä tulee olemaan hyvin
hyödyllinen, tulevaisuutta ajatellen,

514
00:44:08,760 --> 00:44:13,850
estämään tällaisia asioita tapahtumasta.
Mutta on ikävää, että sen täytyi tapahtua.

515
00:44:13,850 --> 00:44:18,830
Aikamme on käymässä vähiin, mutta
me halusimme todella päästä mukaan

516
00:44:18,830 --> 00:44:23,430
ja sotkemaan kätemme. Ja yksi asia
mitä IETF rakastaa, kun kehittelee näitä

517
00:44:23,430 --> 00:44:28,680
standardeja on koodin ajaminen. Joten 
aloitimme IETF 95 Hackathonilla,

518
00:44:28,680 --> 00:44:32,950
joka pidettiin huhtikuussa ja
onnistuimme lopulta saamaan Firefoxin

519
00:44:32,950 --> 00:44:37,740
lataamaan Cloudflaren isännöimän
palvelimen TLS 1.3:lla. Tämä oli suuri

520
00:44:37,740 --> 00:44:43,250
saavutus silloin. Käytimme NSS:ää,
joka on Firefoxin turvallisuuskirjasto ja

521
00:44:43,250 --> 00:44:48,850
"Mint":iä, joka oli uusi tyhjästä

522
00:44:48,850 --> 00:44:52,890
rakennettu versio TLS 1.3:sta Go-kielellä.

523
00:44:52,890 --> 00:44:57,640
Ja lopputulema oli, että se toimi! Mutta
tämä oli ainoastaan konseptitodistus (PoC).

524
00:44:57,640 --> 00:45:02,950
Filippo: Rakentaaksemme jotain tuotanto-
valmiimpaa, katsoimme TLS-kirjastoa,

525
00:45:02,950 --> 00:45:08,330
jonka muokkaaminen tuntui meistä 
helpoimmalta. Yllätyksettömästi se

526
00:45:08,330 --> 00:45:13,370
ei ollut OpenSSL. Joten päätimme

527
00:45:13,370 --> 00:45:17,990
rakentaa 1.3:n Go:n 
crypto/tls-kirjaston päälle,

528
00:45:17,990 --> 00:45:24,210
joka löytyy Go:n standardikirjastosta.
Lopputulos on "tls-tris", ja se on

529
00:45:24,210 --> 00:45:28,500
suora korvaaja crypto/tls:lle ja
se tulee tämän varoituksen

530
00:45:28,500 --> 00:45:33,970
saattelemana, joka sanoo: "Kaiken hyvän
ja oikeudenmukaisuuden nimessä,

531
00:45:33,970 --> 00:45:38,990
älä käytä tätä!". Varoitus koski alunperin
kaikkea, mutta nyt se ei enää niinkään

532
00:45:38,990 --> 00:45:45,190
koske tietoturvaa, auditoitutimme tämän,
mutta se koskee edelleen vakautta.

533
00:45:45,190 --> 00:45:50,510
Työstämme tämän saamista ylävirtaan,
mikä tulee vakiinnuttamaan API:n.

534
00:45:50,510 --> 00:45:56,000
Ja voitte seurata ylävirtaprosessia, 
Googlen väki oli ystävällinen ja

535
00:45:56,000 --> 00:46:00,830
avasi meille oman haaran kehitystyötä
varten, ja se ei varmasti tule osumaan

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

537
00:46:06,960 --> 00:46:12,010
Joka tapauksessa, vaikka käyttäisit
Go:ta, käyttöönotto on vaikeaa.

538
00:46:12,010 --> 00:46:17,800
Ensimmäisen kerran kun otimme Tris:n
käyttöön, luonnoksen numero oli 13.

539
00:46:17,800 --> 00:46:23,630
Ja tukeakseen selaimia tästä
eteenpäin, meidän täytyi tukea

540
00:46:23,630 --> 00:46:29,140
useita luonnosversioita saman
aikaisesti käyttämällä joskus

541
00:46:29,140 --> 00:46:34,590
erikoisia yksityiskohtia. Ja joskus meidän
täytyi tukea asioita, jotka eivät todellakaan

542
00:46:34,590 --> 00:46:40,030
olleet edes luonnoksia, koska selaimet
alkoivat... hajaantua eri suuntiin.

543
00:46:40,030 --> 00:46:44,970
No, joka tapauksessa meillä
oli testimatriisi, joka ajoi

544
00:46:44,970 --> 00:46:50,610
kaikki meidän commit:imme kaikkia
asiakaskirjastojen versioita vastaan,

545
00:46:50,610 --> 00:46:54,980
ja tämä varmisti, että olemme
aina yhteensopivia selainten kanssa.

546
00:46:54,980 --> 00:47:00,170
Ja nykyään asiakkaat ovat itse asiassa
paljon vakaampia, ja todellakin,

547
00:47:00,170 --> 00:47:05,050
saatat jopa jo tietämättäsi 
käyttää sitä. Esim. Chrome Beta,

548
00:47:05,050 --> 00:47:11,160
beta-kanavalla se on päällä noin 50 %:lla
instansseista kokeiluna Googlen puolelta.

549
00:47:11,160 --> 00:47:16,110
Ja tältä meidän kuvaajamme
näyttivät julkaisun aikaan,

550
00:47:16,110 --> 00:47:21,560
kun Firefox Nightly laittoi sen oletuksena
päälle ja kun Chrome Canary laittoi sen

551
00:47:21,560 --> 00:47:26,510
oletuksena päälle. Nykyään meno on
vakaata: noin 700 pyyntöä sekunnissa

552
00:47:26,510 --> 00:47:30,640
kulkee TLS 1.3:a käyttäen. Ja omalla
puolellamme laitoimme sen

553
00:47:30,640 --> 00:47:36,230
päälle miljoonille Cloudflaren 
isännöimille sivustoille.

554
00:47:36,230 --> 00:47:40,830
Ja, kuten sanottua, spesifikaatio
on muuttuva dokumentti

555
00:47:40,830 --> 00:47:46,080
ja se on kaikille avoin. Sen voi nähdä
Githubissa. Tris implementaatio on siellä

556
00:47:46,080 --> 00:47:50,860
myös, vaikkakin siinä on tämä pelottava
varoitus, ja tässä blogissa tulemme

557
00:47:50,860 --> 00:47:56,210
luultavasti julkaisemaan kaiken jatko-
tutkimuksen ja tulokset. Kiitos paljon ja

558
00:47:56,210 --> 00:47:59,990
jos teillä on kysymyksiä, astukaa esiin,
uskon että meillä on muutama minuutti.

559
00:47:59,990 --> 00:48:11,770
(aplodeja)

560
00:48:11,770 --> 00:48:15,690
Herald: Kiitos, meillä on reilusti 
aikaa kysymyksille. Ensimmäinen

561
00:48:15,690 --> 00:48:19,770
kysymys tulee internetistä.

562
00:48:19,770 --> 00:48:23,930
Signal Angel: Ensimmäisessä kysymyksessä 
ihmiset kysyvät onko viisasta, että

563
00:48:23,930 --> 00:48:28,160
päätös 0-RTT:n suhteen menee
sovellukselle, eli se jätetään

564
00:48:28,160 --> 00:48:32,450
sovelluksen kehittäjille?

565
00:48:32,450 --> 00:48:34,130
Filippo: (nauraa)
(aplodeja)

566
00:48:34,130 --> 00:48:40,230
Filippo: Hyvä kysymys. Kuten sanoimme,
tämä tosiaan rikkoo abstraktion.

567
00:48:40,230 --> 00:48:45,500
Eli se EI ole oletusarvoisesti rikki.
Jos ainoastaan päivität Go:n ja

568
00:48:45,500 --> 00:48:50,791
saat käyttöösi TLS 1.3:n, et tule
kohtaamaan yhtään 0-RTT:tä,

569
00:48:50,791 --> 00:48:54,800
koska tosiaan se vaatisi yhteistyötä
sovellukselta. Eli mikäli sovellus ei

570
00:48:54,800 --> 00:48:59,980
tiedä mitä tekee sen kanssa, se ei
yksinkertaisesti voi käyttää sitä, mutta

571
00:48:59,980 --> 00:49:06,920
saa kaikki turvallisuushyödyt sekä 1-RTT-
kättelyn hyödyt joka tapauksessa.

572
00:49:06,920 --> 00:49:09,570
Herald: Selvä, seuraava kysymys
tulee mikrofonista yksi.

573
00:49:09,570 --> 00:49:12,680
Kysyjä: Protokollan ensimmäisten
testien yhteydessä, oletteko

574
00:49:12,680 --> 00:49:17,610
saaneet konkreettisia arvoja sille, miltä
nuo suorituskyvyn parannukset näyttävät?

575
00:49:17,610 --> 00:49:21,170
(Filippo huokaisee)

576
00:49:21,170 --> 00:49:24,580
Nick: Yhdeltä edestakaiselta matkalta!
(nauraa) Riippuu siitä paljonko 1-RTT on.

577
00:49:24,580 --> 00:49:28,000
Filippo: Nimenomaan. Yksi edestakainen
matka on... en pysty sanomaan lukua

578
00:49:28,000 --> 00:49:33,250
koska tietysti, jos asut San Franciscossa,
jossa on nopea kuituyhteys, se on

579
00:49:33,250 --> 00:49:39,120
mitä? Ehkä 3 millisekuntia? 6...? 
Jos taas asut vaikka jossain maassa,

580
00:49:39,120 --> 00:49:43,260
missä EDGE on ainoa 
käytettävissä oleva yhteys,

581
00:49:43,260 --> 00:49:47,700
se on ehkä sekunti. Meillä taitaa
olla keskiarvo, joka on noin... 100

582
00:49:47,700 --> 00:49:55,100
ja 200 millisekunnin välillä, mutta emme
ole virallisesti mitanneet näitä lukuja.

583
00:49:55,100 --> 00:49:57,630
Herald: Ok, seuraava kysymys
tulee mikrofonista 3.

584
00:49:57,630 --> 00:50:01,720
Kysyjä: Yksi huomautus, jonka haluan sanoa
on, että yksi parannus joka saavutettiin

585
00:50:01,720 --> 00:50:07,350
TLS 1.3:ssa on että asiakas-
varmenteisiin lisättiin salaus.

586
00:50:07,350 --> 00:50:11,330
Joten asiakasvarmenteet lähetetään
salattuina, mikä on tärkeää, jos

587
00:50:11,330 --> 00:50:17,670
ajattelee asiakasta, joka liikkuu sekä 
joukkovalvovaa elintä, joka voisi

588
00:50:17,670 --> 00:50:23,120
jäljittää asiakkaita tällä. Ja toinen
huomio/kysymys, joka saattaisi...

589
00:50:23,120 --> 00:50:27,080
Herald: Kysymykset päättyvät kysymys-
merkkiin. Joten yritäthän pitää lyhyenä?

590
00:50:27,080 --> 00:50:31,820
Kysyjä: Kyllä... Tämä saattaa
olla tyhmä kysymys...

591
00:50:31,820 --> 00:50:36,400
Vakio Diffie-Hellman-ryhmät...
eivätkö ne olleet ongelma LogJam-

592
00:50:36,400 --> 00:50:42,890
hyökkäyksessä, joten... auttaako
tämä LogJam-hyökkäyksiä vastaan?

593
00:50:42,890 --> 00:50:46,660
Nick: Viittaatko siihen pankeille
suunnattuun ehdotukseen?

594
00:50:46,660 --> 00:50:49,590
Kysyjä: Ei ei, yleisesti siihen, 
että voidaan laskea ennakkoon...

595
00:50:49,590 --> 00:50:54,430
Nick: Aivan, kyllä, eli LogJamin kohdalla
oli ongelma, missä oli DH-ryhmä, joka

596
00:50:54,430 --> 00:50:57,940
oli oletuksena käytössä monella
eri palvelimella. Apachen käyttämä,

597
00:50:57,940 --> 00:51:03,800
joka oli 1024 (bittiä).
TLS 1.3:ssa tämä rajoitettiin

598
00:51:03,800 --> 00:51:09,190
ennalta laskettuun DH-ryhmään,
joka on yli 2000 bittiä pienimmilläänkin,

599
00:51:09,190 --> 00:51:14,600
ja valtavallakin laskentateholla varustettuna,
jos on 2000 bitin DH ryhmä, ei ole

600
00:51:14,600 --> 00:51:20,140
käytännössä mahdollista tehdä esilasken-
taa minkäänlaista hyökkäystä varten.

601
00:51:20,140 --> 00:51:21,990
Mutta kyllä, tuo on hyvä pointti.

602
00:51:21,990 --> 00:51:24,950
Filippo: ...ja koska ne ovat kiinteitä, ei
ole keinoa pakottaa protokollaa käyttämään

603
00:51:24,950 --> 00:51:28,940
mitään muuta, joka ei olisi niin vahva.
Kysyjä: Selvä, kiitos!

604
00:51:28,940 --> 00:51:32,720
Herald: Seuraava kysymys mikrofonista 4.

605
00:51:32,720 --> 00:51:37,120
Kysyjä: Kiitos esityksestä! 
Tiivistelmässä mainitsitte, että eräs

606
00:51:37,120 --> 00:51:41,550
toinen lopetettava ominaisuus oli SNI,

607
00:51:41,550 --> 00:51:45,920
yhdessä 0-RTT:n kanssa, mutta on edelleen
tapoja implementoida se. Voitteko selventää?

608
00:51:45,920 --> 00:51:49,670
Filippo: Pidimme siis tämän esitelmän
kahdesti sisäisesti, ja tämä kysymys

609
00:51:49,670 --> 00:51:55,590
esitettiin molemmilla
kerroilla. Joten... (nauraa)

610
00:51:55,590 --> 00:52:01,790
Eli, SNI on pieni parametri, jonka asiakas
lähettää palvelimelle kertoakseen,

611
00:52:01,790 --> 00:52:06,210
mille sivustolle se yrittää
yhdistää. Esim. Cloudflarella on

612
00:52:06,210 --> 00:52:11,250
useita sivustoja koneidemme takana, joten
sinun täytyy kertoa meille "Haluan siis

613
00:52:11,250 --> 00:52:17,230
oikeasti yhdistää "blog.filippo.io":n. Tämä
on yksityisyyden kannalta ongelmallista,

614
00:52:17,230 --> 00:52:22,550
koska joku voi pelkästään verkon yli
kulkevista tavuista nähdä, mihin

615
00:52:22,550 --> 00:52:29,450
nimenomaiseen sivuun yhdistät. Epäonninen
seikka on se, että tässä on sama onglema

616
00:52:29,450 --> 00:52:35,270
kuin alkudatan jatkosuojauksessa.
SNI lähetetään "Client Hello":ssa, ja

617
00:52:35,270 --> 00:52:39,620
tässä kohtaa ei ole vielä neuvoteltu
yhtään avainta, joten ei ole mitään millä

618
00:52:39,620 --> 00:52:44,960
sen voisi salata. Mutta jos ei lähetä
SNI:tä ensimmäisessä viestissä,

619
00:52:44,960 --> 00:52:49,140
palvelin ei tiedä minkä sertifikaatin
se lähettää, joten se ei voi lähettää

620
00:52:49,140 --> 00:52:53,050
allekirjoitusta ensimäisessä viestissä,
joten ei ole avaimia. Eli täytyisi tehdä

621
00:52:53,050 --> 00:52:59,030
2-RTT, ja nyt olisimme taas samassa
pisteessä kuin TLS 1.2. Joten,

622
00:52:59,030 --> 00:53:03,180
valitettavasti, se ei
toimi 1-RTT kättelyissä.

623
00:53:03,180 --> 00:53:08,820
Nick: HTTP2:n spesifikaatiossa on kuitenkin
ehdotuksia, jotka mahdollistaisivat multi-

624
00:53:08,820 --> 00:53:14,210
pleksaamisen. Tämä on vielä työn alla. 
Voisi olla mahdollista yhdistää ensin

625
00:53:14,210 --> 00:53:19,700
yhteen verkkotunnukseen ja sitten luoda
toinen yhteys olemassa olevan sisällä.

626
00:53:19,700 --> 00:53:21,950
Ja tämä voisi mahdollisesti
suojata SNI:tä.

627
00:53:21,950 --> 00:53:25,520
Filippo: Eli joku tarkkailija ajattelisi,
että menet sivulle blog.filippo.io mutta

628
00:53:25,520 --> 00:53:29,480
kun avaat yhteyden, voisit pyytää
HTTP2:ta näyttämään myös

629
00:53:29,480 --> 00:53:33,200
"tämän toisen sivun". Kiitos!

630
00:53:33,200 --> 00:53:38,170
Herald: Selvä, seuraava
kysymys, mikrofoni 7,

631
00:53:38,170 --> 00:53:41,240
tai itse asiassa 5, pahoittelut.

632
00:53:41,240 --> 00:53:47,440
Kysyjä: Mainitsitte, että TLS 1.3:sta
on olemassa formaali verifikaatio.

633
00:53:47,440 --> 00:53:54,350
Millä ohjelmistolla tämä
formaali verifikaatio on tehty?

634
00:53:54,350 --> 00:53:59,030
Nick: Oli useita ohjelmisto-
implementaatioita ja protokollia...

635
00:53:59,030 --> 00:54:02,650
Katsotaanpa, jos pääsen
takaisinpäin... tässä.

636
00:54:02,650 --> 00:54:06,600
Tamarin on ohjelmisto, jonka on
kehittänyt muun muassa Cas Cremers

637
00:54:06,600 --> 00:54:11,810
Oxfordissa ja Royal Hollowayssa.
miTLS on uskoakseni kirjoitettu F#:lla

638
00:54:11,810 --> 00:54:18,430
INRIA:n toimesta. Ja nqsb-TLS
on kirjoitettu OCaml:lla.

639
00:54:18,430 --> 00:54:22,970
Joten useita eri kieliä käytettiin näiden
kehityksessä ja käsittääkseni nqsb-TLS:n

640
00:54:22,970 --> 00:54:27,490
kehittäjät ovat paikalla...

641
00:54:27,490 --> 00:54:30,960
Herald: Selvä, seuraava
kysymys mikrofoni 8.

642
00:54:30,960 --> 00:54:36,440
Kysyjä: Hei! Kiitos. Kiitos 
informatiivisesta esityksestä.

643
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ä,

644
00:54:42,690 --> 00:54:48,810
jotka lopulta kostautuivat. Joten
kysymykseni, kun otetaan huomioon,

645
00:54:48,810 --> 00:54:52,740
että on useita pienempiä organisaatioita
tai pienempiä hosting-yrityksiä jne.,

646
00:54:52,740 --> 00:54:59,600
jotka luultavasti implementoivat 0-RTT:n
väärin. Mikä on ensivaikutelmanne? Kuinka

647
00:54:59,600 --> 00:55:04,180
todennäköistä on, että tämä todella
tulee kostautumaan pian? Kiitos.

648
00:55:04,180 --> 00:55:09,990
Filippo: Kuten sanoin, olen itse asiassa
aavistuksen skeptinen vaikutusten suhteen

649
00:55:09,990 --> 00:55:16,460
koskien HTTP:tä, sillä selaimet saadaan
uudelleenlähettämään pyyntöjä jo nyt.

650
00:55:16,460 --> 00:55:21,610
Ja olemme nähneet tästä
julkaisuja ja blogipostauksia. Mutta

651
00:55:21,610 --> 00:55:25,830
kukaan ei kyennyt näyttämään
toteen, että se olisi rikkonut

652
00:55:25,830 --> 00:55:30,620
suuren osuuden internetistä. Ollakseni
rehellinen, en osaa vastata, kuinka

653
00:55:30,620 --> 00:55:35,990
pahasti se kostautuu. Mutta muistetaan,
että tasapainon toinen puoli

654
00:55:35,990 --> 00:55:41,650
on se määrä ihmisiä, jotka sanovat
etteivät aio ottaa TSL:ää käyttöön

655
00:55:41,650 --> 00:55:45,670
koska se on "hidas". Ei.

656
00:55:45,670 --> 00:55:51,620
Se on 0-RTT, TLS on nopea!
Menkää ja salatkaa kaikki!

657
00:55:51,620 --> 00:55:57,940
Siis nuo ovat ne kaksi huolenaihetta, 
jotka täytyy saada tasapainoon.

658
00:55:57,940 --> 00:56:01,910
Lisäksi, oma henkilökohtainen
mielipiteeni ei paina paljoa.

659
00:56:01,910 --> 00:56:07,310
Tämä oli päätös, jonka teki koko
postituslistasta koostuva yhteisö.

660
00:56:07,310 --> 00:56:12,900
Ja voin vakuuttaa, että jokainen on ollut
hyvin konservatiivinen kaiken suhteen,

661
00:56:12,900 --> 00:56:18,630
ottanut huomioon jopa... niin, senkin
olisiko nimi johtanut ihmisiä harhaan.

662
00:56:18,630 --> 00:56:23,910
En osaa ennustaa tulevaisuutta. Voin
vain sanoa toivovani, että teimme

663
00:56:23,910 --> 00:56:28,520
parhaan valinnan tehdäksemme suurimman
osan verkosta niin turvalliseksi kuin voimme.

664
00:56:28,520 --> 00:56:32,490
Herald: Seuraava kysymys
tulee internetistä.

665
00:56:32,490 --> 00:56:34,610
Signal Angel, onko meillä vielä
kysymys internetistä?

666
00:56:34,610 --> 00:56:37,760
Signal Angel: Kyllä meillä on.

667
00:56:37,760 --> 00:56:43,060
Mitkä ovat suurimmat implementoinnin
yhteensopimattomuudet, jotka on löydetty

668
00:56:43,060 --> 00:56:45,800
nyt kun lopullinen spesifikaatio
on melko valmis?

669
00:56:45,800 --> 00:56:47,910
Herald: Voitko toistaa kysymyksen?

670
00:56:47,910 --> 00:56:53,250
(Signal Angel toistaa kysymyksen)

671
00:56:53,250 --> 00:56:59,290
Filippo: Okei. Koskien
luonnosteluvaihetta?

672
00:56:59,290 --> 00:57:03,450
Osa niistä, jotka eivät olleet versio-
yhteensopivia oli, uskoakseni, enimmäkseen

673
00:57:03,450 --> 00:57:06,750
"middleboxeja" ja palomuureja.

674
00:57:06,750 --> 00:57:12,690
Nick: Oli joitain todella isoja 
sivustojakin. Paypal taisi olla yksi?

675
00:57:12,690 --> 00:57:18,310
Filippo: Vaikkakin, prosessin aikana
meillä oli yhteensopivuusongelmia monista

676
00:57:18,310 --> 00:57:23,540
syistä. Mukaanlukien se, missä
toinen kehittäjistä kirjoitti väärin

677
00:57:23,540 --> 00:57:28,110
muuttujan numeron.
(nauraa)

678
00:57:28,110 --> 00:57:32,420
Luonnosten aikana joskus yhteensopivuus
meni rikki, mutta oli myös paljon yhteis-

679
00:57:32,420 --> 00:57:37,970
työtä asiakasimplementaatioiden ja meidän
puolemme palvelinimplementaatioiden välillä.

680
00:57:37,970 --> 00:57:44,040
Voin onnekseni todeta, että varsinaisten
1.3 implementaatioiden kanssa tehtiin

681
00:57:44,040 --> 00:57:50,980
paljon yhteensopivuustestejä, ja kaikki
ongelmat saatiin melko nopeasti korjattua.

682
00:57:50,980 --> 00:57:54,050
Herald: Okei, seuraava kysymys
tulee mikrofonista numero 1.

683
00:57:54,050 --> 00:57:59,300
Kysyjä: Minulla on 2 nopeaa kysmystä
koskien istunnon jatkamista.

684
00:57:59,300 --> 00:58:02,951
Jos palvelimelle tallennetaan jotain
dataa istunnosta, eikö se olisi tavallaan

685
00:58:02,951 --> 00:58:08,010
jonkinlainen supereväste? Eikö se ole
yksityisyyden kannalta vaarallista?

686
00:58:08,010 --> 00:58:13,990
Ja toinen kysymys on: entä DNS-
kuormantasaajat tai jotkut muut

687
00:58:13,990 --> 00:58:21,070
valtavat määrät palvelimia, missä pyynnöt
menevät joka kerta eri palvelimelle?

688
00:58:21,070 --> 00:58:28,150
Filippo: Ok, eli nämä koskevat yksityiskohtia
istuntolippujen tehokkaasta jakelusta.

689
00:58:28,150 --> 00:58:32,950
TLS 1.3 ottaa huomioon yksityisyydensuojan
koskien istuntolippuja, ja tosiaan se

690
00:58:32,950 --> 00:58:37,650
mahdollistaa palvelimen lähettämään useita
istuntolippuja. Palvelin voi siis edelleen

691
00:58:37,650 --> 00:58:42,470
tietää mikä asiakas sen lähettää, jos niin
haluaa. Mutta kukaan ulkopuolelta yhteyttä

692
00:58:42,470 --> 00:58:47,460
tarkkaileva ei siihen kykene, koska ne 
lähetetään salattuina, toisin kuin TLS 1.2:ssa

693
00:58:47,460 --> 00:58:53,171
ja niitä voi olla useita. Kukaan ulko-
puolinen ei pysty yhdistämään sitä

694
00:58:53,171 --> 00:58:57,600
alkuperäiseen yhteyteen. Tämän parempaan
ei pysty, sillä jos palvelimen ja asiakkaan

695
00:58:57,600 --> 00:59:02,560
täytyy käyttää uudelleen jotain jaettua
tietoa, palvelimen täytyy saada tietää

696
00:59:02,560 --> 00:59:08,240
kuka oli kyseessä. Mutta istuntolippuja
ei voi 1.3:ssa jäljittää kolmannen

697
00:59:08,240 --> 00:59:13,010
osapuolen toimesta. Ja... kun tehdään
kuormantasausta... on eräs mielenkiintoinen

698
00:59:13,010 --> 00:59:18,750
julkaisu istuntolippujen jakelusta, mutta
olennaista on, että kannattaa varmaan

699
00:59:18,750 --> 00:59:24,960
selvittää miten asiakkaat liikkuvat
palvelimien välillä ja löytää tasapaino

700
00:59:24,960 --> 00:59:30,340
sen välillä kannattaako istuntolipun
avain jakaa, jolloin se on tehokkaampaa

701
00:59:30,340 --> 00:59:35,500
vai jättää istuntolipun avain jakamatta,
jolloin niitä on vaikeampi saada käsiinsä.

702
00:59:35,500 --> 00:59:41,610
Saattaisit tehdä maantieteellisen
sijainnin mukaan, tai yhden räkin...

703
00:59:41,610 --> 00:59:44,540
Se riippuu ihan toteutuksesta.

704
00:59:44,540 --> 00:59:47,480
Herald: Okei, viimeinen
kysymys menee mikrofonille 3.

705
00:59:47,480 --> 00:59:51,750
Kysyjä: Minulla on kysymys koskien
GREASE-mekanismia, joka toteutetaan

706
00:59:51,750 --> 00:59:57,110
asiakkaan puolella. Jos
ymmärsin oikein, siinä lisätään

707
00:59:57,110 --> 01:00:02,350
satunnaisia versionumeroita
olemattomista TLS- tai SSL-versioista

708
01:00:02,350 --> 01:00:08,640
ja siten koulutetaan
palvelimet mukautumaan

709
01:00:08,640 --> 01:00:14,480
spesifikaatioon. Mitkä ovat
tosielämän testien tulokset?

710
01:00:14,480 --> 01:00:18,490
Moniko palvelin menee
tästä oikeasti nurin?

711
01:00:18,490 --> 01:00:22,780
Filippo: Odotusarvoisesti ei yksikään,
koska ne kaikki ovat nyt ottamassa

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

713
01:00:28,070 --> 01:00:33,100
Kuitenkin, juuri kun Google otti GREASE:n
käyttöön luulen sen rikkoneen... En ole

714
01:00:33,100 --> 01:00:38,330
varma, joten en sano mikä palvelin-
implementaatio, mutta yhden pienemmistä

715
01:00:38,330 --> 01:00:41,860
tunnistettiin heti olevan... 
se Haskell-kielellä kirjoitettu!

716
01:00:41,860 --> 01:00:43,890
Nick: Aivan!
Filippo: En muista sen nimeä,

717
01:00:43,890 --> 01:00:47,450
en osaa lukea Haskellia, joten en
tarkalleen tiedä mitä ne tekivät, mutta

718
01:00:47,450 --> 01:00:49,590
ne katkaisivat yhteyksiä
GREASE:n takia.

719
01:00:49,590 --> 01:00:53,480
Nick: Ja huomautuksena, GREASE:a käytetään
myös salausneuvotteluissa ja kaikessa

720
01:00:53,480 --> 01:00:58,800
mikä on neuvottelu TLS 1.3:ssa.
Tämä tosiaan rikkoi

721
01:00:58,800 --> 01:01:03,020
pienen osan palvelimista, mutta
sen verran pienen osan,

722
01:01:03,020 --> 01:01:06,600
että ihmiset hyväksyivät sen.

723
01:01:06,600 --> 01:01:08,670
Kysyjä: Kiitos!
Nick: 2 % on liikaa!

724
01:01:08,670 --> 01:01:11,430
Herald: Kiitos oikein paljon.
Filippo: Kiitos!

725
01:01:11,430 --> 01:01:20,010
(aplodeja)

726
01:01:20,010 --> 01:01:39,080
(33C3 loppumusiikki)

727
01:01:39,080 --> 01:01:43,981
Translated by Roope Salminen
(ITKST56 course assignment at JYU.FI)