1
00:00:00,000 --> 00:00:14,820
33C3 intromusiikki

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

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

4
00:00:23,509 --> 00:00:26,989
jotka he 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. Puheenaiheenamme
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ä tutuin

10
00:00:52,960 --> 00:00:57,900
vihreästä lukon kuvasta selaimessa,
tai vanhasta nimestään: SSL,

11
00:00:57,900 --> 00:01:02,510
jota yritämme edeelleen 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äytetää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 sertifikaatti,

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 
sertifikaatista 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 vastaan ottaa 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ä maailmankolkissa
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 uudelleen järjestetty. 
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 sertifikaatin ja allekirjoituksen

66
00:05:47,089 --> 00:05:51,339
sertifikaatista, 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-pyyntösi.
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 algoritmiä,

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 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ää. Lippu 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 lipun, se purkaa
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 
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.

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
istuntolippu - 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 yhteyden
salauksen. Tämä ei ole hyvä.

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

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

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

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

123
00:10:56,270 --> 00:11:01,310
että toteutukset eivät aina tee tätä
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

126
00:11:11,760 --> 00:11:16,720
istuntolipun joutumiselta vääriin
käsiin. 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ä sertifikaatin 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
sertifikaattia ei ole. Koska ei ole 
tarvetta uudelleen autentikoida

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

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

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 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ä edestaikaisesta 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 se

147
00:12:58,331 --> 00:13:04,210
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 aiemmin
jo 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ä
sertifikaatin 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 sertifikaatin väärinkäyttöä

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

179
00:15:50,300 --> 00:15:55,090
Ei ole moodia joka olisi jatkosuojaamaton
sertifikaatin väärinkäytön 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 ole jatkosuojattu.

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

183
00:16:11,149 --> 00:16:15,819
ja jatkossa murtaa 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 istuntolippua.

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
ei 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 10s 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 
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 data vastaan

218
00:19:15,960 --> 00:19:20,990
vai hylkäänkö sen kaiken?" Jos se hyväksyy
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. Jokatapauksessa. 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ä 1-RTT oletuksena,

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

244
00:21:30,360 --> 00:21:35,571
kutsua joitakin API:ja 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. Internetissä on 
takuuvarmasti palvelin,

253
00:22:16,640 --> 00:22:23,020
jossa on 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ökkäykses-
sä 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 oman sovelluksena oiken 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
salli GET-pyynnöt 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 
itseasiassa, 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.

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

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

288
00:25:18,120 --> 00:25:22,770
kertasimme olemassaolevia TLS 1.2 ominai-
suuksia, jotka vaikuttivat järkeviltä

289
00:25:22,770 --> 00:25:27,439
aikanaan ja päätimme, oliko kompleksisuus
tai vaara, jotka 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 sertifikaatin

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
luomaan 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 sertifikaatin
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-
listaa, 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 internettiä." 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...
perus lohkosalain rakennelmia,

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 useita ominaisuuksia kuten kompressio
ja uudellenneuvottelu on poistettu, jonka

343
00:29:41,770 --> 00:29:47,130
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, on mahdottomia TLS 1.3:ssa.

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

347
00:30:04,010 --> 00:30:09,149


348
00:30:09,149 --> 00:30:14,549


349
00:30:14,549 --> 00:30:18,680


350
00:30:18,680 --> 00:30:24,030


351
00:30:24,030 --> 00:30:27,640


352
00:30:27,640 --> 00:30:32,340


353
00:30:32,340 --> 00:30:37,520


354
00:30:37,520 --> 00:30:41,810


355
00:30:41,810 --> 00:30:47,020


356
00:30:47,020 --> 00:30:53,090


357
00:30:53,090 --> 00:30:59,300


358
00:30:59,300 --> 00:31:02,669


359
00:31:02,669 --> 00:31:06,980


360
00:31:06,980 --> 00:31:11,649


361
00:31:11,649 --> 00:31:16,129


362
00:31:16,129 --> 00:31:21,290


363
00:31:21,290 --> 00:31:27,860


364
00:31:27,860 --> 00:31:33,410


365
00:31:33,410 --> 00:31:36,920


366
00:31:36,920 --> 00:31:41,949


367
00:31:41,949 --> 00:31:47,940


368
00:31:47,940 --> 00:31:51,960


369
00:31:51,960 --> 00:31:56,540


370
00:31:56,540 --> 00:32:01,199


371
00:32:01,199 --> 00:32:05,599


372
00:32:05,599 --> 00:32:10,760


373
00:32:10,760 --> 00:32:15,690


374
00:32:15,690 --> 00:32:21,970


375
00:32:21,970 --> 00:32:27,800


376
00:32:27,800 --> 00:32:33,301


377
00:32:33,301 --> 00:32:37,441


378
00:32:37,441 --> 00:32:43,410


379
00:32:43,410 --> 00:32:49,199


380
00:32:49,199 --> 00:32:55,679


381
00:32:55,679 --> 00:33:02,509


382
00:33:02,509 --> 00:33:07,860


383
00:33:07,860 --> 00:33:13,619


384
00:33:13,619 --> 00:33:18,139


385
00:33:18,139 --> 00:33:23,859


386
00:33:23,859 --> 00:33:29,780


387
00:33:29,780 --> 00:33:35,950


388
00:33:35,950 --> 00:33:42,090


389
00:33:42,090 --> 00:33:46,770


390
00:33:46,770 --> 00:33:52,990


391
00:33:52,990 --> 00:33:58,579


392
00:33:58,579 --> 00:34:04,090


393
00:34:04,090 --> 00:34:09,439


394
00:34:09,439 --> 00:34:13,619


395
00:34:13,619 --> 00:34:18,949


396
00:34:18,949 --> 00:34:25,959


397
00:34:25,959 --> 00:34:31,729


398
00:34:31,729 --> 00:34:36,760


399
00:34:36,760 --> 00:34:41,779


400
00:34:41,779 --> 00:34:47,990


401
00:34:47,990 --> 00:34:53,490


402
00:34:53,490 --> 00:34:58,670


403
00:34:58,670 --> 00:35:04,040


404
00:35:04,040 --> 00:35:10,130


405
00:35:10,130 --> 00:35:14,670


406
00:35:14,670 --> 00:35:18,820


407
00:35:18,820 --> 00:35:23,400


408
00:35:23,400 --> 00:35:28,620


409
00:35:28,620 --> 00:35:33,060


410
00:35:33,060 --> 00:35:38,720


411
00:35:38,720 --> 00:35:44,350


412
00:35:44,350 --> 00:35:49,830


413
00:35:49,830 --> 00:35:55,580


414
00:35:55,580 --> 00:35:59,420


415
00:35:59,420 --> 00:36:04,230


416
00:36:04,230 --> 00:36:10,920


417
00:36:10,920 --> 00:36:12,840


418
00:36:12,840 --> 00:36:15,710


419
00:36:15,710 --> 00:36:20,670


420
00:36:20,670 --> 00:36:25,840


421
00:36:25,840 --> 00:36:30,310


422
00:36:30,310 --> 00:36:34,170


423
00:36:34,170 --> 00:36:40,120


424
00:36:40,120 --> 00:36:45,360


425
00:36:45,360 --> 00:36:50,570


426
00:36:50,570 --> 00:36:54,730


427
00:36:54,730 --> 00:36:59,760


428
00:36:59,760 --> 00:37:03,461


429
00:37:03,461 --> 00:37:07,910


430
00:37:07,910 --> 00:37:13,250


431
00:37:13,250 --> 00:37:19,920


432
00:37:19,920 --> 00:37:24,630


433
00:37:24,630 --> 00:37:29,200


434
00:37:29,200 --> 00:37:34,330


435
00:37:34,330 --> 00:37:39,980


436
00:37:39,980 --> 00:37:46,080


437
00:37:46,080 --> 00:37:51,590


438
00:37:51,590 --> 00:37:57,330


439
00:37:57,330 --> 00:38:02,400


440
00:38:02,400 --> 00:38:07,860


441
00:38:07,860 --> 00:38:12,220


442
00:38:12,220 --> 00:38:15,550


443
00:38:15,550 --> 00:38:21,380


444
00:38:21,380 --> 00:38:27,561


445
00:38:27,561 --> 00:38:32,521


446
00:38:32,521 --> 00:38:36,330


447
00:38:36,330 --> 00:38:40,980


448
00:38:40,980 --> 00:38:46,910


449
00:38:46,910 --> 00:38:52,810


450
00:38:52,810 --> 00:38:59,020


451
00:38:59,020 --> 00:39:04,190


452
00:39:04,190 --> 00:39:09,300


453
00:39:09,300 --> 00:39:14,190


454
00:39:14,190 --> 00:39:18,370


455
00:39:18,370 --> 00:39:23,230


456
00:39:23,230 --> 00:39:29,230


457
00:39:29,230 --> 00:39:34,130


458
00:39:34,130 --> 00:39:38,620


459
00:39:38,620 --> 00:39:43,550


460
00:39:43,550 --> 00:39:49,980


461
00:39:49,980 --> 00:39:55,650


462
00:39:55,650 --> 00:40:00,610


463
00:40:00,610 --> 00:40:04,950


464
00:40:04,950 --> 00:40:10,510


465
00:40:10,510 --> 00:40:16,330


466
00:40:16,330 --> 00:40:21,670


467
00:40:21,670 --> 00:40:27,230


468
00:40:27,230 --> 00:40:32,550


469
00:40:32,550 --> 00:40:38,180


470
00:40:38,180 --> 00:40:44,000


471
00:40:44,000 --> 00:40:49,071


472
00:40:49,071 --> 00:40:54,950


473
00:40:54,950 --> 00:40:59,860


474
00:40:59,860 --> 00:41:02,030


475
00:41:02,030 --> 00:41:07,840


476
00:41:07,840 --> 00:41:12,940


477
00:41:12,940 --> 00:41:18,040


478
00:41:18,040 --> 00:41:22,520


479
00:41:22,520 --> 00:41:25,780


480
00:41:25,780 --> 00:41:30,400


481
00:41:30,400 --> 00:41:35,410


482
00:41:35,410 --> 00:41:38,860


483
00:41:38,860 --> 00:41:44,800


484
00:41:44,800 --> 00:41:50,040


485
00:41:50,040 --> 00:41:55,300


486
00:41:55,300 --> 00:42:00,240


487
00:42:00,240 --> 00:42:05,210


488
00:42:05,210 --> 00:42:10,720


489
00:42:10,720 --> 00:42:14,870


490
00:42:14,870 --> 00:42:20,030


491
00:42:20,030 --> 00:42:23,870


492
00:42:23,870 --> 00:42:28,130


493
00:42:28,130 --> 00:42:32,780


494
00:42:32,780 --> 00:42:37,640


495
00:42:37,640 --> 00:42:43,720


496
00:42:43,720 --> 00:42:49,000


497
00:42:49,000 --> 00:42:53,761


498
00:42:53,761 --> 00:42:58,511


499
00:42:58,511 --> 00:43:02,670


500
00:43:02,670 --> 00:43:07,960


501
00:43:07,960 --> 00:43:13,080


502
00:43:13,080 --> 00:43:18,780


503
00:43:18,780 --> 00:43:24,880


504
00:43:24,880 --> 00:43:30,680


505
00:43:30,680 --> 00:43:35,610


506
00:43:35,610 --> 00:43:39,640


507
00:43:39,640 --> 00:43:44,340


508
00:43:44,340 --> 00:43:48,820


509
00:43:48,820 --> 00:43:53,920


510
00:43:53,920 --> 00:43:56,980


511
00:43:56,980 --> 00:44:01,050


512
00:44:01,050 --> 00:44:06,320


513
00:44:06,320 --> 00:44:08,760


514
00:44:08,760 --> 00:44:13,850


515
00:44:13,850 --> 00:44:18,830


516
00:44:18,830 --> 00:44:23,430


517
00:44:23,430 --> 00:44:28,680


518
00:44:28,680 --> 00:44:32,950


519
00:44:32,950 --> 00:44:37,740


520
00:44:37,740 --> 00:44:43,250


521
00:44:43,250 --> 00:44:48,850


522
00:44:48,850 --> 00:44:52,890


523
00:44:52,890 --> 00:44:57,640


524
00:44:57,640 --> 00:45:02,950


525
00:45:02,950 --> 00:45:08,330


526
00:45:08,330 --> 00:45:13,370


527
00:45:13,370 --> 00:45:17,990


528
00:45:17,990 --> 00:45:24,210


529
00:45:24,210 --> 00:45:28,500


530
00:45:28,500 --> 00:45:33,970


531
00:45:33,970 --> 00:45:38,990


532
00:45:38,990 --> 00:45:45,190


533
00:45:45,190 --> 00:45:50,510


534
00:45:50,510 --> 00:45:56,000


535
00:45:56,000 --> 00:46:00,830


536
00:46:00,830 --> 00:46:06,960


537
00:46:06,960 --> 00:46:12,010


538
00:46:12,010 --> 00:46:17,800


539
00:46:17,800 --> 00:46:23,630


540
00:46:23,630 --> 00:46:29,140


541
00:46:29,140 --> 00:46:34,590


542
00:46:34,590 --> 00:46:40,030


543
00:46:40,030 --> 00:46:44,970


544
00:46:44,970 --> 00:46:50,610


545
00:46:50,610 --> 00:46:54,980


546
00:46:54,980 --> 00:47:00,170


547
00:47:00,170 --> 00:47:05,050


548
00:47:05,050 --> 00:47:11,160


549
00:47:11,160 --> 00:47:16,110


550
00:47:16,110 --> 00:47:21,560


551
00:47:21,560 --> 00:47:26,510


552
00:47:26,510 --> 00:47:30,640


553
00:47:30,640 --> 00:47:36,230


554
00:47:36,230 --> 00:47:40,830


555
00:47:40,830 --> 00:47:46,080


556
00:47:46,080 --> 00:47:50,860


557
00:47:50,860 --> 00:47:56,210


558
00:47:56,210 --> 00:47:59,990


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


560
00:48:11,770 --> 00:48:15,690


561
00:48:15,690 --> 00:48:19,770


562
00:48:19,770 --> 00:48:23,930


563
00:48:23,930 --> 00:48:28,160


564
00:48:28,160 --> 00:48:32,450


565
00:48:32,450 --> 00:48:34,130


566
00:48:34,130 --> 00:48:40,230


567
00:48:40,230 --> 00:48:45,500


568
00:48:45,500 --> 00:48:50,791


569
00:48:50,791 --> 00:48:54,800


570
00:48:54,800 --> 00:48:59,980


571
00:48:59,980 --> 00:49:06,920


572
00:49:06,920 --> 00:49:09,570


573
00:49:09,570 --> 00:49:12,680


574
00:49:12,680 --> 00:49:17,610


575
00:49:17,610 --> 00:49:21,170


576
00:49:21,170 --> 00:49:24,580


577
00:49:24,580 --> 00:49:28,000


578
00:49:28,000 --> 00:49:33,250


579
00:49:33,250 --> 00:49:39,120


580
00:49:39,120 --> 00:49:43,260


581
00:49:43,260 --> 00:49:47,700


582
00:49:47,700 --> 00:49:55,100


583
00:49:55,100 --> 00:49:57,630


584
00:49:57,630 --> 00:50:01,720


585
00:50:01,720 --> 00:50:07,350


586
00:50:07,350 --> 00:50:11,330


587
00:50:11,330 --> 00:50:17,670


588
00:50:17,670 --> 00:50:23,120


589
00:50:23,120 --> 00:50:27,080


590
00:50:27,080 --> 00:50:31,820


591
00:50:31,820 --> 00:50:36,400


592
00:50:36,400 --> 00:50:42,890


593
00:50:42,890 --> 00:50:46,660


594
00:50:46,660 --> 00:50:49,590


595
00:50:49,590 --> 00:50:54,430


596
00:50:54,430 --> 00:50:57,940


597
00:50:57,940 --> 00:51:03,800


598
00:51:03,800 --> 00:51:09,190


599
00:51:09,190 --> 00:51:14,600


600
00:51:14,600 --> 00:51:20,140


601
00:51:20,140 --> 00:51:21,990


602
00:51:21,990 --> 00:51:24,950


603
00:51:24,950 --> 00:51:28,940


604
00:51:28,940 --> 00:51:32,720


605
00:51:32,720 --> 00:51:37,120


606
00:51:37,120 --> 00:51:41,550


607
00:51:41,550 --> 00:51:45,920


608
00:51:45,920 --> 00:51:49,670


609
00:51:49,670 --> 00:51:55,590


610
00:51:55,590 --> 00:52:01,790


611
00:52:01,790 --> 00:52:06,210


612
00:52:06,210 --> 00:52:11,250


613
00:52:11,250 --> 00:52:17,230


614
00:52:17,230 --> 00:52:22,550


615
00:52:22,550 --> 00:52:29,450


616
00:52:29,450 --> 00:52:35,270


617
00:52:35,270 --> 00:52:39,620


618
00:52:39,620 --> 00:52:44,960


619
00:52:44,960 --> 00:52:49,140


620
00:52:49,140 --> 00:52:53,050


621
00:52:53,050 --> 00:52:59,030


622
00:52:59,030 --> 00:53:03,180


623
00:53:03,180 --> 00:53:08,820


624
00:53:08,820 --> 00:53:14,210


625
00:53:14,210 --> 00:53:19,700


626
00:53:19,700 --> 00:53:21,950


627
00:53:21,950 --> 00:53:25,520


628
00:53:25,520 --> 00:53:29,480


629
00:53:29,480 --> 00:53:33,200


630
00:53:33,200 --> 00:53:38,170


631
00:53:38,170 --> 00:53:41,240


632
00:53:41,240 --> 00:53:47,440


633
00:53:47,440 --> 00:53:54,350


634
00:53:54,350 --> 00:53:59,030


635
00:53:59,030 --> 00:54:02,650


636
00:54:02,650 --> 00:54:06,600


637
00:54:06,600 --> 00:54:11,810


638
00:54:11,810 --> 00:54:18,430


639
00:54:18,430 --> 00:54:22,970


640
00:54:22,970 --> 00:54:27,490


641
00:54:27,490 --> 00:54:30,960


642
00:54:30,960 --> 00:54:36,440


643
00:54:36,440 --> 00:54:42,690


644
00:54:42,690 --> 00:54:48,810


645
00:54:48,810 --> 00:54:52,740


646
00:54:52,740 --> 00:54:59,600


647
00:54:59,600 --> 00:55:04,180


648
00:55:04,180 --> 00:55:09,990


649
00:55:09,990 --> 00:55:16,460


650
00:55:16,460 --> 00:55:21,610


651
00:55:21,610 --> 00:55:25,830


652
00:55:25,830 --> 00:55:30,620


653
00:55:30,620 --> 00:55:35,990


654
00:55:35,990 --> 00:55:41,650


655
00:55:41,650 --> 00:55:45,670


656
00:55:45,670 --> 00:55:51,620


657
00:55:51,620 --> 00:55:57,940


658
00:55:57,940 --> 00:56:01,910


659
00:56:01,910 --> 00:56:07,310


660
00:56:07,310 --> 00:56:12,900


661
00:56:12,900 --> 00:56:18,630


662
00:56:18,630 --> 00:56:23,910


663
00:56:23,910 --> 00:56:28,520


664
00:56:28,520 --> 00:56:32,490


665
00:56:32,490 --> 00:56:34,610


666
00:56:34,610 --> 00:56:37,760


667
00:56:37,760 --> 00:56:43,060


668
00:56:43,060 --> 00:56:45,800


669
00:56:45,800 --> 00:56:47,910


670
00:56:47,910 --> 00:56:53,250


671
00:56:53,250 --> 00:56:59,290


672
00:56:59,290 --> 00:57:03,450


673
00:57:03,450 --> 00:57:06,750


674
00:57:06,750 --> 00:57:12,690


675
00:57:12,690 --> 00:57:18,310


676
00:57:18,310 --> 00:57:23,540


677
00:57:23,540 --> 00:57:28,110


678
00:57:28,110 --> 00:57:32,420


679
00:57:32,420 --> 00:57:37,970


680
00:57:37,970 --> 00:57:44,040


681
00:57:44,040 --> 00:57:50,980


682
00:57:50,980 --> 00:57:54,050


683
00:57:54,050 --> 00:57:59,300


684
00:57:59,300 --> 00:58:02,951


685
00:58:02,951 --> 00:58:08,010


686
00:58:08,010 --> 00:58:13,990


687
00:58:13,990 --> 00:58:21,070


688
00:58:21,070 --> 00:58:28,150


689
00:58:28,150 --> 00:58:32,950


690
00:58:32,950 --> 00:58:37,650


691
00:58:37,650 --> 00:58:42,470


692
00:58:42,470 --> 00:58:47,460


693
00:58:47,460 --> 00:58:53,171


694
00:58:53,171 --> 00:58:57,600


695
00:58:57,600 --> 00:59:02,560


696
00:59:02,560 --> 00:59:08,240


697
00:59:08,240 --> 00:59:13,010


698
00:59:13,010 --> 00:59:18,750


699
00:59:18,750 --> 00:59:24,960


700
00:59:24,960 --> 00:59:30,340


701
00:59:30,340 --> 00:59:35,500


702
00:59:35,500 --> 00:59:41,610


703
00:59:41,610 --> 00:59:44,540


704
00:59:44,540 --> 00:59:47,480


705
00:59:47,480 --> 00:59:51,750


706
00:59:51,750 --> 00:59:57,110


707
00:59:57,110 --> 01:00:02,350


708
01:00:02,350 --> 01:00:08,640


709
01:00:08,640 --> 01:00:14,480


710
01:00:14,480 --> 01:00:18,490


711
01:00:18,490 --> 01:00:22,780


712
01:00:22,780 --> 01:00:28,070


713
01:00:28,070 --> 01:00:33,100


714
01:00:33,100 --> 01:00:38,330


715
01:00:38,330 --> 01:00:41,860


716
01:00:41,860 --> 01:00:43,890


717
01:00:43,890 --> 01:00:47,450


718
01:00:47,450 --> 01:00:49,590


719
01:00:49,590 --> 01:00:53,480


720
01:00:53,480 --> 01:00:58,800


721
01:00:58,800 --> 01:01:03,020


722
01:01:03,020 --> 01:01:06,600


723
01:01:06,600 --> 01:01:08,670


724
01:01:08,670 --> 01:01:11,430


725
01:01:11,430 --> 01:01:20,010


726
01:01:20,010 --> 01:01:39,080


727
01:01:39,080 --> 01:01:43,981