Yleistä

SSL (ja sen seuraaja, TLS ) on protokolla, joka toimii suoraan TCP: n päällä (vaikkakin on olemassa toteutuksia datagrammin perustuville protokollille, kuten UDP) .Näin tavoin ylempien kerrosten (kuten HTTP) protokollat voidaan jättää muuttumattomiksi, kun s kunnes luot turvallisen yhteyden. SSL-tason alla HTTP on identtinen HTTPS: n kanssa.

Kun SSL / TLS: ää käytetään oikein, kaikki hyökkääjät näkevät kaapelilla sen IP-osoitteen ja portin, johon olet yhteydessä, suunnilleen kuinka paljon dataa lähetät. ja mitä salausta ja pakkausta käytetään. Hän voi myös katkaista yhteyden, mutta molemmat osapuolet tietävät, että kolmas osapuoli on keskeyttänyt yhteyden.

Tyypillisessä käytössä hyökkääjä voi myös selvittää, mihin isäntänimeen olet yhteydessä. (mutta ei loput URL-osoite): Vaikka HTTPS itse ei paljasta isäntänimeä, selaimesi on yleensä tehtävä ensin DNS-pyyntö selvittääksesi mihin IP-osoitteeseen pyyntö lähetetään.

Korkea – protokollan tason kuvaus

TCP-yhteyden muodostamisen jälkeen asiakas aloittaa SSL-kädenpuristuksen. Asiakas (joka voi olla selain sekä mikä tahansa muu ohjelma, kuten Windows Update tai PuTTY) lähettää useita spesifikaatioita:

• mikä SSL / TLS-versio se on käynnissä,
• mitä salauspaketteja haluaa käyttää, ja
• mitä pakkausmenetelmät , jota se haluaa käyttää.

Palvelin tunnistaa korkeimman SSL / TLS-version, jota sekä se että asiakas tukevat, valitsee salausjoukon yhdestä asiakkaan vaihtoehdoista (jos se tukee sitä) ja valitsee vaihtoehtoisesti pakkausmenetelmän.

Tämän jälkeen perusasetukset on tehty, palvelin lähettää varmenteensa. Joko asiakkaan itsensä tai asiakkaan luotettavan osapuolen on luotettava tähän varmenteeseen. Esimerkiksi, jos asiakas luottaa GeoTrustiin, asiakas voi luottaa Google.com -sertifikaattiin, koska GeoTrust kryptografisesti allekirjoitettu Googlen varmenne.

Vahvistettuaan varmenteen ja ollessaan varma, että tämä palvelin todella on se, jonka hän väittää olevansa (eikä mies keskellä), avain vaihdetaan. Tämä voi olla julkinen avain, ” PreMasterSecret ” tai ei mitään, valitun salausjoukon mukaan. Sekä palvelin että asiakas voivat nyt laskea avaimen symmetrinen salaus ^{miksi PKE ei ole?} . Asiakas kertoo palvelimelle, että tästä lähtien kaikki viestinnät salataan, ja lähettää salatun ja todennetun viestin palvelimelle.

Palvelin tarkistaa, että MAC (todentamiseen käytetty) on oikea ja että viesti voidaan purkaa oikein. Se palauttaa sitten viestin, jonka asiakas tarkistaa kuten hyvin.

Kädenpuristus on nyt valmis, ja kaksi isäntää voivat kommunikoida turvallisesti. Lisätietoja on aiheissa technet.microsoft.com/en-us/library/cc785811 ja fi.wikipedia .org / wiki / Secure_Sockets_Layer .

Yhteyden sulkemiseksi käytetään close_notify-hälytystä. Jos hyökkääjä yrittää katkaista yhteyden viimeistelemällä TCP-yhteyden (injektoimalla FIN-paketin), molemmat osapuolet tietävät, että yhteys on katkaistu väärin. Tämä ei kuitenkaan voi vaarantaa yhteyttä, vaan vain keskeyttää.

Lisätietoja

Miksi voit luottaa Google.comiin luottamalla GeoTrustiin?

Verkkosivusto haluaa olla yhteydessä sinuun turvallisesti. Palvelimen ”s julkinen avain tarvitsee todistaa henkilöllisyytensä ja varmistaa, että se ei ole hyökkääjä. Et kuitenkaan tuskin voi tallentaa kaikkia avaimia kaikilta maan päällä olevilta verkkosivustoilta tietokanta olisi valtava ja päivitysten olisi suoritettava joka tunti!

Ratkaisu tähän on sertifikaattiviranomaiset tai lyhyesti CA.Kun asennit käyttöjärjestelmän tai selaimen, luultavasti mukana oli luettelo luotetuista varmentajista. Tätä luetteloa voidaan muuttaa haluamallasi tavalla. voit poistaa ne, joille et luota, lisätä muita tai jopa luoda oman varmentajan (vaikka sinäkin luotat tähän varmenteeseen, joten siitä ei ole paljon hyötyä julkisille verkkosivustoille). Tähän CA-luetteloon on tallennettu myös CA: n julkinen avain.

Kun Googlen palvelin lähettää sinulle varmenteen, siinä mainitaan myös, että GeoTrust on allekirjoittanut sen. Jos luotat GeoTrustiin, voit tarkistaa (käyttämällä GeoTrustin julkista avainta), että GeoTrust todella allekirjoitti palvelimen varmenteen. Jos haluat allekirjoittaa varmenteen itse, tarvitset yksityisen avaimen, jonka vain GeoTrust tietää. Näin hyökkääjä ei voi itse allekirjoittaa varmentetta ja väittää olevansa väärin Google.com. Kun sertifikaattia on muutettu edes yhdellä bitillä, merkki on väärä ja asiakas hylkää sen.

Joten jos tiedän julkisen avaimen, palvelin voi todistaa henkilöllisyytensä?

Kyllä. Tyypillisesti julkinen avain salaa ja yksityisen avaimen salauksen. Salaa viesti palvelimen julkisella avaimella, lähetä se, ja jos palvelin pystyy toistamaan alkuperäisen viestin, se vain osoitti saaneensa yksityisen avaimen paljastamatta avainta.

Siksi se on niin tärkeää, että voit luottaa julkiseen avaimeen: kuka tahansa voi luoda yksityisen / julkisen avaimen parin, myös hyökkääjä. Et halua päätyä käyttämään hyökkääjän julkista avainta!

Jos yksi luotettavista varmentajista on vaarantunut, hyökkääjä voi käyttää varastettua yksityistä avainta allekirjoittamaan varmenteen mistä tahansa haluamastaan verkkosivustosta. Kun hyökkääjä voi lähettää asiakkaalle väärennetyn varmenteen, jonka hän on allekirjoittanut luotettavan varmentajan yksityisellä avaimella, asiakkaasi ei tiedä, että julkinen avain on väärennetty, allekirjoitettu varastetulla yksityisellä avaimella.

Mutta varmentaja voi saada minut luottamaan mihin tahansa palvelimeen, jonka he haluavat!

Kyllä, ja luottamus tulee sinne Sinun on luotettava, että varmentaja ei tee varmenteita haluamallaan tavalla. Kun Microsoftin, Applen ja Mozillan kaltaiset organisaatiot luottavat kuitenkin varmenteeseen, varmentajalla on oltava tarkastuksia; toinen organisaatio tarkistaa ne säännöllisesti varmistaakseen, että kaikki toimii edelleen

Varmenteen myöntäminen tapahtuu vain ja vain, jos rekisteröijä voi todistaa, että hänellä on verkkotunnus, jolle varmenne on annettu.

Mikä tämä MAC on viestin todennuksessa?

Jokainen viesti on allekirjoitettu ns. viestin todennuskoodilla tai Lyhyesti MAC. Jos olemme sopineet avaimesta ja hajautuskoodista, voit vahvistaa, että viestini tulee minulta, ja voin varmistaa, että viestisi tulee sinulta.

Esimerkiksi avaimella ” korjaa hevosen akun niitti ” ja viesti ” esimerkki ”, Voin laskea MAC ” 58393 ”. Kun lähetän tämän viestin MAC: n kanssa sinulle (tiedät jo avaimen), voit suorittaa saman laskennan ja sovittaa lasketun MAC: n lähettämäni MAC: n kanssa.

Hyökkääjä voi muokata viestiä mutta ei tiedä avainta. Hän ei voi laskea oikeaa MAC-tiedostoa, ja tiedät, että viesti ei ole aito.

Lisäämällä järjestysnumeron MAC-laskentaohjelmaan voit poistaa -toiston hyökkäykset . SSL tekee tämän.

Sanoit, että asiakas lähettää avaimen, jota käytetään sitten määritykseen symmetrinen salaus. Mikä estää hyökkääjää käyttämästä sitä?

Palvelimen julkinen avain tekee. Koska olemme varmistaneet, että julkinen avain todella kuuluu palvelimelle eikä kenellekään muulle, voi salata avaimen julkisella avaimella. Kun palvelin vastaanottaa tämän, hän voi purkaa sen yksityisellä avaimella. Kun kukaan muu saa sen, he eivät voi purkaa sitä.

Siksi avaimen koko on tärkeä: Mitä suurempi on julkinen ja yksityinen avain, sitä vaikeampi on murtaa avain, jonka asiakas lähettää palvelimelle.

Kuinka murtaa SSL

Yhteenvetona :

• Yritä, jättääkö käyttäjä huomiotta varmenteiden varoitukset;
• sovellus voi ladata tietoja salaamaton kanava (esim. HTTP), jota voidaan peukaloida;
• HTTPS: lle lähettämää suojaamatonta kirjautumissivua voidaan muokata siten, että se lähettää HTTP: lle;
• viemättömiä sovelluksia voidaan haavoittuvainen hyväksikäytöille, kuten BEAST ja CRIME;
• turvautua muihin menetelmiin h fyysisenä hyökkäyksenä;
• Käytä sivukanavia , kuten viestin pituus ja aika otettiin muodostamaan viesti;
• Odota -kvanttihyökkäyksiä .

Katso myös: Ivan Risticin kaavio, jossa on monia SSL-hyökkäysvektoreita ^(png)

Yksityiskohtaisesti:

Ei ole yksinkertaista ja suoraviivaista tapa; SSL on turvallinen, kun se tehdään oikein. Hyökkääjä voi yrittää, jos käyttäjä jättää kuitenkin huomiotta sertifikaattivaroitukset , mikä rikkoa tietoturvan välittömästi. Kun käyttäjä tekee tämän, hyökkääjä ei tarvitse varmenteen väärentämiseen varmentajan yksityistä avainta, vaan hänen on vain lähetettävä oma varmenne.

Toinen tapa olisi sovellus (palvelin- tai asiakaspuoli). Helppo esimerkki verkkosivustoista: jos jokin verkkosivuston käyttämistä resursseista (kuten kuva tai komentosarja) ladataan HTTP: n kautta, luottamuksellisuutta ei voida taata enää. Vaikka selaimet älä lähetä HTTP-viittausotsikkoa, kun pyydät suojaamattomia resursseja suojatulta sivulta ( lähde ), liikenteen salakuuntelija voi silti arvata, missä olet ”vierailet uudelleen; Esimerkiksi jos he tietävät, että kuvia X, Y ja Z käytetään yhdellä sivulla, he voivat arvata, että vierailet tällä sivulla, kun he näkevät selaimesi pyytävän näitä kolmea kuvaa kerralla. Lisäksi Javascriptia ladattaessa koko sivu voi vaarantua. Hyökkääjä voi suorittaa minkä tahansa sivun komentosarjan muuttamalla esimerkiksi sitä, kenelle pankkitapahtuma menee.

Kun näin tapahtuu (resurssi ladataan HTTP: n kautta), selain antaa sekoitetun sisällön varoituksen: Chrome , Firefox , Internet Explorer 9

Toinen HTTP-temppu on, kun kirjautumissivua ei ole suojattu ja se lähettää https-sivulle. ” Loistava, ” kehittäjä luultavasti ajatteli, ” nyt tallennan palvelimen kuormituksen salasana lähetetään edelleen salattuna! ” Ongelma on sslstrip , työkalu, joka muuttaa suojaamatonta kirjautumissivua siten, että se lähettää jonnekin, jotta hyökkääjä voi lukea sen.

Viime vuosina on myös tapahtunut useita hyökkäyksiä, kuten TLS-neuvottelujen heikkous , sslsniff , BEAST ja äskettäin RIKOS . Kaikki yleiset selaimet ovat kuitenkin suojattuja kaikilta näiltä hyökkäyksiltä, joten nämä haavoittuvuudet eivät ole vaarassa, jos sinulla on ajan tasalla oleva selain.

Viimeisenä mutta ei vähäisimpänä, voit käyttää muita tapoja saadaksesi tiedot, joita SSL estää sinua saamasta. Jos pystyt jo näkemään ja muuttamaan käyttäjän yhteyttä, ei ehkä ole niin vaikeaa korvata yhtä hänen .exe-lataustaan näppäinlukijalla tai yksinkertaisesti hyökätä kyseistä henkilöä vastaan. Salaus voi olla melko turvallista, mutta ihmiset ja inhimilliset virheet ovat edelleen heikko tekijä. tämän Verizonin paperin mukaan 10% tietorikkomuksista liittyi fyysisiin hyökkäyksiin (katso sivu 3), joten ” on varmasti jotain mielessä pidettävää.

Kommentit

• Olisin kiinnostunut hieman tarkemmasta selityksestä ” avain vaihdetaan ” symmetriseen avaimeen. Kuinka näin tapahtuu, että joku, jolla on pakettinipuri, ei pääse käsiksi.
• @Yehosef Hyvä kysymys! Unohdin selittää sen vastauksessani. Ympäristössä käy ilmi, että tälle on omistettu kysymys: security.stackexchange.com/q/6290/10863
• @ Iwazaru Kaikki CA: t tekevät tämän ensimmäisestä päivästä lähtien. Varmenteen tarkoituksena on antaa julkinen avain tietylle verkkotunnukselle, ja sen allekirjoittamisen kohta todistaa, että se on oikea verkkotunnuksen avain. Anna ’ s Encryptin tehdä juuri niin kuin sen pitäisi: vahvistaa, että omistat verkkotunnuksen, ja allekirjoita varmenteesi (avaimellasi), jos pystyt todistamaan sen. Nyt kaikki, jotka luottavat Let ’ s Encrypt -palveluun, joka on käytännössä jokainen selain, luottavat siihen varmenteeseen.
• Eee, ei. TLS on todellakin juuri otettu käyttöön TCP: n päällä.
• Löysin tämän graafisen SSL-kädenpuristusprosessin erittäin selkeästi.

Koska SSL: n yleinen käsite on jo käsitelty joissakin muissa kysymyksissä (esim. tämä ja tuo yksi ), tällä kertaa kerron lisätietoja. Yksityiskohdat ovat tärkeitä. Tämä vastaus tulee olemaan jonkin verran yksityiskohtainen.

Historia

SSL on protokolla, jolla on pitkä historia ja useita versioita.Ensimmäiset prototyypit tulivat Netscapesta, kun he kehittivät lippuselaimensa Netscape Navigator : n ensimmäisiä versioita (tämä selain tappoi Mosaiikki selainsotien alkuaikoina, jotka ovat edelleen raivoissaan, vaikkakin uusien kilpailijoiden kanssa). Versiota 1 ei ole koskaan julkaistu, joten emme tiedä miltä se näytti. SSL-versio 2 kuvataan luonnoksessa, joka voidaan lukea siellä ; sillä on useita heikkouksia, joista osa on melko vakavia, joten se on vanhentunut eikä uudemmat SSL / TLS-toteutukset tue sitä (kun taas vanhemmat deaktivoitu oletusarvoisesti). En puhu enää SSL-versiosta 2 paitsi satunnaisena viitteenä.

SSL-versio 3 (jota kutsun nimellä ”SSLv3”) oli parannettu protokolla, joka toimii edelleen tänään ja jota tuetaan laajalti. Vaikka protokolla on edelleen Netscape Communicationsin (tai kuka sen omistaa nykyään) omaisuus, protokolla on julkaistu ”historiallisena RFC: nä” ( RFC 6101 ). Samaan aikaan protokolla on standardoitu uudella nimellä oikeudellisten ongelmien välttämiseksi; uusi nimi on TLS .

TLS: stä on tähän mennessä tuotettu kolme versiota, joista jokaisella on omistettu RFC: TLS 1.0 , TLS 1.1 ja TLS 1.2 . Ne ovat sisäisesti hyvin samanlaisia toistensa ja SSLv3: n suhteen siihen pisteeseen asti, että toteutus voi helposti tukea SSLv3: ta ja kaikkia kolmea TLS-versiota siten, että vähintään 95% koodista on yhteistä. Sisäisesti kaikki versiot on kuitenkin merkitty versionumerolla, jonka muoto on major.minor ; SSLv3 on silloin 3,0, kun taas TLS-versiot ovat vastaavasti 3.1, 3.2 ja 3.3. Siksi ei ole ihme, että TLS 1.0: ta kutsutaan joskus SSL 3.1: ksi (eikä se myöskään ole väärä). SSL 3.0 ja TLS 1.0 eroavat toisistaan vain muutamilla yksityiskohdilla. TLS 1.1: tä ja 1.2: ta ei vielä tueta laajalti, vaikka sille onkin sysäys mahdollisten heikkouksien vuoksi (katso jäljempänä ”BEAST-hyökkäys”). SSLv3: ta ja TLS 1.0: ta tuetaan ”kaikkialla” (jopa IE 6.0 tuntee ne).

Konteksti

SSL: n tarkoituksena on tarjota turvallinen kaksisuuntainen tunneli mielivaltaisille tiedoille. Harkitse TCP -palvelua, joka on hyvin tunnettu tiedonsiirtoprotokolla Internetin kautta. TCP toimii IP-pakettien kautta ja tarjoaa kaksisuuntaisen tunnelin tavuille; se toimii jokaisen tavuarvon suhteen ja lähettää ne kahteen virtaan, jotka voivat toimia samanaikaisesti. TCP hoitaa tiedon jakamisen paketteihin, kuittaa ne, kokoaa ne takaisin oikeaan järjestykseen samalla kun poistaa kaksoiskappaleet ja palauttaa kadonneet paketit. TCP: tä käyttävän sovelluksen kannalta on vain kaksi virtaa, ja paketit ovat näkymättömiä; etenkään virtauksia ei jaeta ”viesteiksi” (sovelluksen on otettava omat koodaussäännönsä, jos se haluaa saada viestejä, ja juuri tämä on HTTP tekee).

TCP on luotettava ”onnettomuuksien” läsnä ollessa, ts. Siirtohäiriöistä, jotka johtuvat hilseilevästä laitteistosta, verkon ruuhkautumisesta, älypuhelimella varustetuista ihmisistä, jotka kulkevat tietyn tukiaseman kantaman ulkopuolella. , ja muut ei-haitalliset tapahtumat. Harkittomat henkilöt (”hyökkääjät”), joilla on jonkin verran pääsyä kuljetusvälineeseen, voivat kuitenkin lukea kaikki välitetyt tiedot ja / tai muuttaa niitä tarkoituksellisesti, eikä TCP suojaa sitä. SSL.

SSL olettaa , että se toimii TCP: n kaltaisella protokollalla, joka tarjoaa luotettavan virran; SSL ei toteuta kadonneiden pakettien ja vastaavien uudelleenlähetystä. Hyökkääjä on oletettavasti olevan vallassa häiritä viestintää kokonaan väistämättömällä tavalla (esimerkiksi hän voi katkaista kaapelit), joten SSL: n tehtävä on:

• havaitse muutokset (hyökkääjä ei saa pystyä muuttamaan tietoja hiljaa );
• varmistaa tietojen luottamuksellisuus ( hyökkääjä ei saa hankkia tietoa vaihdetusta datasta).

SSL täyttää nämä tavoitteet suuressa määrin (mutta ei absoluuttisesti).

Tallentaa

SSL on kerrostettu ja alin kerros on tietueprotokolla . SSL-tunnelissa lähetetyt tiedot jaetaan tietueisiin . Johdon (alla olevan TCP-liitännän tai TCP-tyyppisen välineen) yli tietue näyttää tältä:

HH V1:V2 L1:L2 data

missä:

• HH on yksi tavu, joka ilmoittaa tietuetyypin tietueessa.Neljä tyyppiä on määritelty: muutoksen_salaus_spec (20), hälytys (21), kädenpuristus (22) ja sovelluksen_tiedot ( 23).
• V1: V2 on kahden tavun protokolla-versio. Kaikilla tällä hetkellä määritellyillä versioilla V1 on arvo 0x03, kun taas V2 on arvo 0x00 SSLv3: lle, 0x01 TLS 1.0: lle, 0x02 TLS 1.1: lle ja 0x03 TLS 1.2: lle.
• L1: L2 on data: n pituus tavuina (big-endian yleissopimus on käytetty: pituus on 256 * L1 + L2). data -kohdan kokonaispituus ei voi ylittää 18432 tavua, mutta käytännössä se ei voi edes saavuttaa tätä arvoa.

Joten tietueella on viisi- tavun otsikko, jota seuraa enintään 18 kt dataa. Symmetrinen salaus ja eheyden tarkistus tehdään data -kohdassa. Kun tietue lähetetään, sekä lähettäjän että vastaanottajan on sovittava siitä, mitä salausalgoritmeja käytetään ja mitä avaimia; tämä sopimus saadaan kättelyprotokollalla, joka on kuvattu seuraavassa osassa. Mahdollista pakatusta käytetään myös siinä vaiheessa.

Yksityiskohtaisesti tietueen rakentaminen toimii näin:

• Aluksi on siirrettäviä tavuja ; nämä ovat sovellustietoja tai muunlaisia tavuja. Tämä hyötykuorma koostuu enintään 16384 tavusta, mutta mahdollisesti vähemmän (hyötykuorma 0 on laillinen, mutta käy ilmi, että Internet Explorer 6.0 ei pidä siitä ollenkaan ) .
• Hyötykuorma pakataan sitten millä tahansa tällä hetkellä sovitulla pakkausalgoritmilla. Pakkaus on tilallinen ja voi siten riippua aiempien tietueiden sisällöstä. Käytännössä pakkaus on joko ”nolla” (ei puristusta lainkaan) tai ”tyhjennä” ( RFC 3749 ), jälkimmäinen on tällä hetkellä kohteliaasti, mutta lujasti esillä ovi verkkoyhteydessä äskettäisen RIKKOMUS-hyökkäyksen vuoksi. Pakkauksella pyritään lyhentämään dataa, mutta sen on välttämättä laajennettava sitä hieman joissakin epäsuotuisissa tilanteissa (johtuen kyyhkyreikäperiaatteesta ). SSL sallii enintään 1024 tavun laajennuksen. Tietysti nollapakkaus ei koskaan laajene (mutta ei myöskään lyhennä); Tyhjennys laajenee enintään 10 tavua, jos toteutus on hyvä.
• Pakattu hyötykuorma suojataan sitten muutoksilta ja salataan. Jos nykyiset salaus- ja eheysalgoritmit ovat ”nollia”, tämä vaihe on ei-toiminto. Muussa tapauksessa MAC lisätään, sitten täyte (salausalgoritmista riippuen) ja tulos salataan. Nämä vaiheet aiheuttavat jälleen jonkin verran laajennusta, jonka SSL-standardi rajoittaa 1024 ylimääräiseen tavuun (yhdistettynä pakkausvaiheen maksimilaajennukseen tämä johtaa meidät 18432 tavuun, joihin meidän on lisättävä 5-tavuinen otsikko).

MAC on yleensä HMAC , jolla on jokin tavallisista hash-toiminnoista (enimmäkseen MD5, SHA-1 tai SHA-256) (SSLv3: n kanssa tämä ei ole ”oikea” HMAC, mutta jotain hyvin samanlaista ja parhaan tietomme mukaan yhtä turvallista kuin HMAC). Salaus käyttää joko lohkosalausta CBC-tilassa tai RC4 -salausta. Huomaa, että teoriassa voitaisiin käyttää muun tyyppisiä moodeja tai algoritmeja, esimerkiksi yhtä näistä hienoista tiloista, jotka yhdistävät salauksen ja eheyden tarkistukset; siihen on jopa jokin RFC . Käytännössä käyttöönotetut toteutukset eivät kuitenkaan vielä tiedä näitä, joten he tietävät HMAC: n ja CBC: n. Keskeistä on, että MAC lasketaan ensin ja liitetään dataan, ja tulos salataan. Tämä on MAC-sitten-salaus, ja se ei todellakaan ole ole kovin hyvä idea . MAC lasketaan (pakatun) hyötykuorman ja järjestysnumeron yhdistämisen yli, jotta ahkera hyökkääjä ei voi vaihtaa tietueita.

Kättely

Kädenpuristus on protokolla, jota toistetaan tietueprotokollassa. Sen tavoitteena on luoda algoritmit ja avaimet, joita käytetään tietueisiin. Se koostuu viesteistä . Jokainen kättelyviesti alkaa nelitavuisella otsikolla, yksi tavu, joka kuvaa viestityyppiä, sitten kolme tavua viestin pituudelle (big-endian-käytäntö). Peräkkäiset kättelyviestit lähetetään sitten tietueilla, jotka on merkitty ”kättely” -tyypillä (jokaisen tietueen otsikon ensimmäisellä tavulla on arvo 22).

Huomaa kerrokset: kädenpuristusviestit, joissa on neljä tavun otsikko, lähetetään sitten tietueina, ja jokaisella tietueella myös on oma otsikko. Lisäksi samassa tietueessa voidaan lähettää useita kättelyviestejä, ja annettu kädenpuristusviesti voidaan jakaa useaan tietueeseen.Kättelyviestejä rakentavan moduulin näkökulmasta ”tietueet” ovat vain virta, johon tavuja voidaan lähettää; se on unohdettu kyseisen virran tosiasialliselle jakamiselle tietueiksi.

Täysi kättely

Aluksi asiakas ja palvelin ”sopivat” null-salauksesta ilman MAC: ää ja tyhjää pakkausta. Tämä tarkoittaa, että heidän lähettämänsä tietue lähetetään selkeänä tekstinä ja suojaamattomana.

Kädenpuristuksen ensimmäinen viesti on ClientHello. Se on viesti, jolla asiakas ilmoittaa aikomuksestaan tehdä SSL. Huomaa, että ”asiakas” on symbolinen rooli; se tarkoittaa ”puolue, joka puhuu ensin”. Sattuu niin, että HTTPS-kontekstissa, joka on HTTP-SSL-sisällä-TCP: ssä, kaikilla kolmella kerroksella on käsite ”asiakas” ja ”palvelin”, ja ne kaikki ovat yhtä mieltä (TCP-asiakas on myös SSL-asiakas ja HTTP-asiakas), mutta se on eräänlainen sattuma.

ClientHello -sanoma sisältää:

• protokollan enimmäismäärän versio, jota asiakas haluaa tukea;
• ”asiakkaan satunnainen” (32 tavua, joista 28 oletetaan luotavan kryptografisesti vahvalla numerogeneraattorilla);
• ” istunnon tunnus ”(jos asiakas haluaa jatkaa istuntoa lyhennetyllä kättelyllä, katso alla);
• luettelo asiakkaan tuntemista” salauspaketeista ”, jotka on järjestetty asiakkaan mieltymysten mukaan;
• luettelo pakkausalgoritmeista, joista asiakas tietää, asiakkaan mieltymysten mukaan järjestettyinä;
• joitain valinnaisia laajennuksia.

A salauspaketti on 16-bittinen symbolinen tunniste joukolle salauksia c-algoritmit. Esimerkiksi salauspaketin TLS_RSA_WITH_AES_128_CBC_SHA arvo on 0x002F, ja se tarkoittaa, että ”tietueet käyttävät HMAC / SHA-1- ja AES-salausta 128-bittisellä avaimella, ja avaimen vaihto tapahtuu salaamalla satunnainen avain palvelimen RSA: n julkisella avaimella.

Palvelin vastaa ClientHello -merkillä ServerHello joka sisältää:

• protokollaversio, jota asiakas ja palvelin käyttävät;
• ”palvelimen satunnaisuus” (32 tavua, 28 satunnaiset tavut);
• tämän yhteyden istuntotunnus;
• käytettävä salauspaketti;
• käytettävä pakkausalgoritmi;
• vaihtoehtoisesti joitain laajennuksia.

Koko kädenpuristus näyttää tältä:

 Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data 

(Tämä malli on häpeämättömästi kopioitu RFC: stä.)

Näemme ClientHello ja ServerHello. Sitten palvelin lähettää muutama muu viesti, jotka riippuvat salauspaketista ja joistakin muista parameteista rs:

• Sertifikaatti: palvelimen varmenne, joka sisältää sen julkisen avaimen. Lisää siitä alla. Tämä viesti lähetetään melkein aina, paitsi jos salauspaketti määrää kädenpuristuksen ilman sertifikaattia.
• ServerKeyExchange: joitain ylimääräisiä arvoja avaimenvaihtoon, jos varmenteessa oleva ei riitä. Erityisesti DHE-salauspaketit käyttävät lyhytaikaista Diffie-Hellman -avaimenvaihtoa, joka vaatii kyseisen viestin.
• CertificateRequest: viesti, joka pyytää asiakasta myös tunnistamaan itsensä omalla varmenteellaan. Tämä viesti sisältää luettelon luotettavien ankkureiden nimistä (alias ”juurivarmenteista”), joita palvelin käyttää asiakassertifikaatin vahvistamiseen.
• ServerHelloDone: merkitsevä viesti (pituus nolla), joka sanoo, että palvelin on valmis, ja asiakkaan pitäisi nyt puhua.

Asiakkaan on sitten vastattava kanssa:

• Sertifikaatti: asiakassertifikaatti, jos palvelin pyysi sitä. Versioiden välillä on hienovaraisia muunnelmia (SSLv3: n kanssa asiakkaan on jätettävä tämä viesti pois, jos sillä ei ole varmentetta; TLS 1.0+: n kanssa samassa tilanteessa sen on lähetettävä Certificate viesti, jossa on tyhjä luettelo sertifikaateista).
• ClientKeyExchange: varsinaisen avaimenvaihdon asiakasosa (esim. jokin satunnaisarvo, joka on salattu palvelimen RSA-avaimella).
• CertificateVerify: a digitaalinen allekirjoitus , jonka asiakas on laskenut kaikkien aikaisempien kättelyviestien yli. Tämä viesti lähetetään, kun palvelin on pyytänyt asiakassertifikaattia ja asiakas noudattaa sitä. Näin asiakas osoittaa palvelimelle, että hän todella ”omistaa” julkisen avaimen, joka on koodattu lähettämässään varmenteessa.

Sitten asiakas lähettää ChangeCipherSpec -viesti, joka ei ole kättelyviesti: sillä on oma tietueen tyyppi, joten se lähetetään omana tietueena.Sen sisältö on puhtaasti symbolinen (yksi tavu arvon 1). Tämä viesti merkitsee kohtaa, jossa asiakas vaihtaa äskettäin neuvoteltuun salauspakettiin ja avaimiin. Asiakkaan seuraavat tietueet salataan.

Valmis -sanoma on salattu tarkistus summa kaikkien aiempien kättelyviestien yli (sekä asiakkaalta että palvelimelta). Koska se lähetetään ChangeCipherSpec: n jälkeen, se kuuluu myös eheystarkastuksen ja salauksen piiriin. Kun palvelin vastaanottaa kyseisen viestin ja tarkistaa sen sisällön, se saa todistuksen siitä, että se on todellakin puhunut saman asiakkaan kanssa koko ajan. Tämä viesti suojaa kättelyä muutoksilta (hyökkääjä ei voi muokata kädenpuristusviestejä ja silti saada Finished -viestin oikein).

Palvelin vastaa vihdoin omalla ChangeCipherSpec sitten Finished. Siinä vaiheessa kädenpuristus on valmis, ja asiakas ja palvelin voivat vaihtaa sovellustietoja (sellaisina merkittyihin salattuihin tietueisiin).

Muista: asiakas ehdottaa , mutta palvelin valitsee . Salauspaketti on palvelimen käsissä. Kohteliaisien palvelimien oletetaan noudattavan asiakkaan mieltymyksiä (jos mahdollista), mutta ne voivat tehdä toisin ja jotkut todella (esimerkiksi osana BEAST-suojausta).

Lyhennetty kädenpuristus

Täydellä kädenpuristuksella palvelin lähettää asiakkaalle ”istunnon tunnuksen” (eli jopa 32 tavua). Myöhemmin asiakas voi palata ja lähettää saman istuntotunnuksen osana ClientHello. Tämä tarkoittaa, että asiakas muistaa edelleen salauspaketin ja avaimet edellisestä kättelystä ja haluaisi käyttää näitä parametreja uudelleen. Jos palvelin myös muistaa salauspaketin ja avaimet, se kopioi kyseisen istuntotunnuksen ServerHello -kansioonsa ja seuraa sitten lyhennetty kättely :

 Client Server ClientHello --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data 

Lyhennetty kädenpuristus on lyhyempi: vähemmän viestejä, ei epäsymmetrinen salausliiketoiminta ja mikä tärkeintä, pienennetty viive . Web-selaimet ja palvelimet tekevät sen paljon. Tyypillinen verkkoselain avaa SSL-yhteyden täydellä kädenpuristuksella ja tekee sitten lyhennetyt kättelyt kaikille muille yhteyksille samalle palvelimelle: muut yhteydet, jotka se avaa samanaikaisesti, ja myös seuraavat yhteydet samalle palvelimelle. Tyypilliset verkkopalvelimet sulkevat yhteyden 15 sekunnin käyttämättömyyden jälkeen, mutta muistavat istunnot (salauspaketti ja avaimet) paljon pidempään (mahdollisesti tunteja tai jopa päiviä).

Avainten vaihto

SSL voi käyttää useita avaimenvaihtoalgoritmeja. Tämän määrittelee salauspaketti; kukin avaimenvaihtoalgoritmi toimii jonkinlaisen palvelimen julkisen avaimen kanssa. Yleisimmät avaimenvaihtoalgoritmit ovat:

• RSA: palvelimen avain on tyyppiä RSA. Asiakas tuottaa satunnaisen arvon (” pre-master secret ”48 tavua, joista 46 on satunnaisia) ja salaa sen palvelimen julkisella avaimella. ServerKeyExchange ei ole.
• DHE_RSA: palvelimen avain on tyyppiä RSA, mutta sitä käytetään vain allekirjoitus. Varsinainen avaimenvaihto käyttää Diffie-Hellmania. Palvelin lähettää ServerKeyExchange -sanoman, joka sisältää DH-parametrit (moduuli, generaattori) ja äskettäin generoidun julkisen DH-avaimen; lisäksi palvelin allekirjoittaa tämän viestin. Asiakas vastaa ClientKeyExchange -sanomalla, joka sisältää myös äskettäin luodun julkisen DH-julkisen avaimen. DH tuottaa ”pre-master secret” ”.
• DHE_DSS: kuten DHE_RSA, mutta palvelimella on DSS-avain (” DSS ”tunnetaan myös nimellä ”DSA” ). DSS on vain allekirjoitusta käsittelevä algoritmi.

Harvemmin käytettyjä avaimenvaihtoalgoritmeja ovat:

• DH: palvelimen avain on tyyppiä Diffie-Hellman (puhumme sertifikaatista , joka sisältää DH-näppäin). Tämä oli aiemmin ”suosittua” hallinnollisella tavalla (Yhdysvaltain liittohallitus määräsi sen käytön), kun RSA-patentti oli vielä voimassa (tämä oli edellisen vuosisadan aikana). Byrokraattisesta painostuksesta huolimatta sitä ei koskaan käytetty yhtä laajalti kuin RSA.
• DH_anon: kuten DHE -sviitit, mutta ilman palvelimen allekirjoitusta. Tämä on sertifikaattittomia salauspaketteja. Rakenteeltaan se on altis Man-in-the-Middle -hyökkäyksille , joten se on hyvin harvoin mahdollista ollenkaan.
• PSK: jaetun avaimen salauspaketit. Vain symmetrinen avaintenvaihto, joka perustuu ennalta määritettyyn jaettuun salaisuuteen.
• SRP: SRP-protokollan sovellus, joka on Salasanan todennettu avainten vaihto -protokolla. Asiakas ja palvelin todentavat toistensa jaetun salaisuuden suhteen, mikä voi olla matalan entropian salasana (kun taas PSK vaatii korkean entropian jaetun salaisuuden). Erittäin upea. Ei vielä laajasti tuettu.
• Väliaikainen RSA-avain: kuten DHE, mutta vasta luodulla RSA-avainparilla. Koska RSA-avainten luominen on kallista, tämä ei ole suosittu vaihtoehto, ja se määriteltiin vain osana ”viennin” salauspaketteja, jotka noudattivat Yhdysvaltojen salausta edeltäviä vientisääntöjä ennen vuotta 2000 (ts. Enintään 512 bitin RSA-avaimet). Kukaan ei tee sitä nykyään.
• DH* -algoritmien variantit elliptisten käyrien kanssa. Erittäin muodikas. Pitäisi tulla yleiseksi tulevaisuudessa.

Sertifikaatit ja todennus

Digitaaliset varmenteet ovat asymmetristen avainten aluksia. Ne on tarkoitettu ratkaisemaan avainten jakelu. Nimittäin asiakas haluaa käyttää palvelimen julkista avainta . Hyökkääjä yrittää saada asiakkaan käyttämään hyökkääjän julkista avainta. Joten asiakkaalla on oltava tapa varmistaa, että se käyttää oikeaa avainta.

SSL: n on tarkoitus käyttää X.509 . Tämä on sertifikaattien standardi. Jokainen varmenne on allekirjoittanut varmentaja . Ajatuksena on, että asiakas tietää luonnostaan kourallisen varmentajan julkiset avaimet (nämä ovat ”luottamusankkurit” tai ”juurivarmenteet”). Näillä avaimilla asiakas voi tarkistaa varmentajan laskeman allekirjoituksen palvelimelle myönnetyn varmenteen kautta. Tätä prosessia voidaan laajentaa rekursiivisesti: varmentaja voi antaa varmenteen toiselle varmentajalle (ts. allekirjoita varmenteen rakenne, joka sisältää toisen varmentajan nimen ja avaimen). Sertifikaattiketjua, joka alkaa juurivarmentajasta ja päättyy palvelimen sertifikaattiin, välissä olevien CA-varmenteiden kanssa, kukin varmenne allekirjoitetaan suhteessa julkiseen avaimeen, joka on koodattu edellisessä varmenteessa, kutsutaan mielikuvituksetta a > sertifikaattiketju .

Joten asiakkaan on tarkoitus tehdä seuraava:

• Hanki varmenteketju, joka päättyy palvelimen varmenteeseen. Palvelimen Certificate -sanoman on tarkoitus sisältää tarkalleen tällainen ketju.
• Vahvista ketju, eli tarkista kaikki allekirjoitukset ja nimet sekä erilaiset X.509-bitit. Asiakkaan tulisi myös tarkistaa ketjun kaikkien varmenteiden peruutustila , joka on monimutkainen ja raskas (verkkoselaimet tekevät sen nyt enemmän tai vähemmän, mutta se on äskettäinen kehitys).
• Varmista, että tarkoitettu palvelimen nimi on todella kirjoitettu palvelimen varmenteeseen. Koska asiakas ei halua käyttää vain vahvistettua julkista avainta, se haluaa käyttää myös julkista avainta tietyn palvelimen . Katso kohdasta RFC 2818 lisätietoja siitä, miten tämä tehdään HTTPS-kontekstissa .

Sertifiointimallia, jolla on X.509-sertifikaatit, on usein kritisoitu, ei oikeastaan teknisistä syistä, vaan pikemminkin poliittis-taloudellisista syistä. , jotka eivät välttämättä ole hyvää tarkoittavia tai ainakaan aina päteviä . Toisinaan julkaistaan ehdotuksia muiksi järjestelmiksi (esim. Lähentyminen tai

Jälkeen SSL: n pitkä esittely edellisessä vastauksessa , mennään mukaan hauskoille asioille, nimittäin:

SSL-hyökkäykset

SSL: ää vastaan on tehty useita hyökkäyksiä, jotkut rakentavat toteutusvirheitä, toiset todellisia protokollan heikkouksia.

On muistettava, että vaikka SSL on yksi eniten hyökätyistä protokollista (koska se on erittäin korkean profiilin: onnistunut SSL-sovellus näyttää erittäin mukava tutkimusartikkelin tiivistelmänä), SSL on myös yksi korjattuimmista protokollista.Sitä on pidettävä vankkana juuri siksi, että kaikki tunnetut tapat hyökätä siirtoprotokolliin on kokeiltu SSL: llä, ja SSL on korjattava tarvittaessa.

Version palautus

SSLv3: n alkuaikoina SSLv2: ta käytettiin edelleen laajalti, ja siksi asiakkaat lähettivät yleisesti SSLv2-yhteensopivaa ClientHello -viestit, jotka vain osoittivat, että myös SSLv3: ta tuettiin; palvelin ottaisi sitten vihjeen ja vastaisi SSLv3 + -murretta (lisätietoja on kohdassa RFC 2246 ). Koska SSLv2: lla oli heikkouksia, hyökkääjän edun mukaista oli järjestää asiakas ja palvelin, jotka molemmat tietävät SSLv3: n, kuitenkin keskustelemaan keskenään SSLv2: n avulla. Tätä kutsutaan version palautushyökkäykseksi . Konsepti ulottuu muodollisesti myös myöhempiin versioihin.

Kludgejä on lisätty palautusyritysten havaitsemiseksi. SSLv2-paluureittejä varten asiakkaan, joka tuntee SSLv3 +: n, tulisi käyttää erityistä täytettä RSA-salausvaiheeseen (SSLv2 tukee vain RSA-pohjaista avaimenvaihtoa): PKCS # 1 , salattavien tietojen oletetaan olevan täytetty useilla satunnaisilla tavuilla; SSLv3-tietoisen asiakkaan oletetaan asettavan kumpikin kahdeksasta viimeisestä täytetavusta kiinteään arvoon 0x03. Palvelin tarkistaa sitten nämä tavut; jos löydetään kahdeksan 0x03, yritetään todennäköisesti palauttaa, ja palvelin hylkää yrityksen (vain SSLv2-asiakkaalle on todennäköistä, että vain 255 ^-8 käyttää tällaisia täytetavuita pelkän puutteen vuoksi onnea, joten vääriä positiivisia esiintyy vähäisellä nopeudella).

Vanhan SSL / TLS-version, mutta ei vanhemman kuin SSLv3, palauttamisen yhteydessä lisättiin toinen kludge: pre-master-salaisuuteen 48 tavua, jotka asiakas salaa palvelimen RSA-avaimella, kaksi ensimmäistä tavua eivät ole satunnaisia, mutta niiden on oltava yhtä suuri kuin ”suurin tuettu protokollaversio”, jonka asiakas kirjoitti ensin ClientHello viesti. Valitettavasti jotkut asiakkaat saivat sen väärin, ja tämä kludge toimii vain RSA-pohjaisen avainten vaihdon kanssa, joten suoja palautusta vastaan on siellä hyvin rajallinen. Onneksi SSLv3 +: lla on toinen, paljon tehokkaampi suojaus vastaan palautukset, eli kättelyviestit sekoitetaan yhteen, kun Finished -viestit rakennetaan. Tämä pro suojaa palautuksilta, ellei ”vanha versio” olisi niin perusteellisesti heikko, että hyökkääjä voisi rikkoa koko salauksen ennen kädenpuristuksen loppua. Tätä ei ole vielä tapahtunut (SSLv3 on edelleen kohtuullisen kestävä).

Heikko salauspaketti

Jotkut tavallisista salauspaketeista ovat tarkoituksella heikkoja jollain tavalla. On olemassa:

• joitain salauspaketteja, joissa ei ole lainkaan salausta, vain eheystarkistus, esim. TLS_RSA_WITH_NULL_SHA;
• jotkut salauspaketit 40-bittisellä salauksella, kuten TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (salauspaketit, jotka on tarkoitettu noudattamaan tiukat Yhdysvaltain viime vuosisadan vientisäännöt – nämä määräykset on enimmäkseen poistettu Bill Clintonin aikakauden lopussa);
• jotkut salauspaketit 56-bittisellä salauksella, kuten TLS_RSA_WITH_DES_CBC_SHA. 56-bittinen DES on irrotettavissa olemassa olevalla tekniikalla , mutta se on vielä vähän vaikeaa harrastajalle (jopa tylsistyneelle opiskelijalle, jolla on pääsy muutamaan sadaan yliopiston koneeseen) ), joten minulla on tapana luokitella 56-bittinen DES ”keskivahvuudeksi”.

Tämä avaa tietä version palautushyökkäyksille, joissa hyökkääjä pakottaa asiakkaan ja palvelimen sopimaan heikossa salauspaketissa, ajatuksena on, että hyökkääjä muuttaa asiakkaan ilmoittamaa salauspakettien luetteloa.Tämä on hyökkääjälle toimiva, jos valittu salauspaketti on niin heikko, että hän voi rikkoa sen laskeakseen uudelleen ilmeisen oikean Finished -viesti. Itse asiassa SSLv3 +: ssa käytetty MAC (jopa MD5: n perusteella) on riittävän vahva estämään tämän. Joten tässä ei ole varsinaista huolta. Mielestäni täällä on todellisia heikkouksia on silloin, kun asiakas tai palvelin suostuu käyttämään heikkoa salauspakettia lainkaan.

Oletusarvoisesti nykyaikaiset verkkoselaimet eivät salli tällaisten heikkojen salauspakettien käyttöä.

Yksityisen avaimen varkaus

Jos SSL-yhteys käyttää RSA-avaimenvaihtoa, ja hyökkääjä säilyttää kopion tietueista, ja sitten myöhemmin (mahdollisesti kuukausien kuluttua, mahdollisesti tarkastamalla kaikki hylättyjen kiintolevyjen tai nauhojen varmuuskopiot), hän saa kopion yksityisestä avaimesta, minkä jälkeen hän voi purkaa kättely ja salauksen purkaminen.

Täydellinen välitys salassapitoon liittyy tämän vastaiseen torjuntaan myöhemmin. Saat sen käyttämällä salauspaketteja DHE. DHE-salauspaketilla todellinen yksityinen avain, jota voidaan käyttää kädenpuristuksen selvittämiseen, on lyhytaikainen Diffie-Hellman-avain, ei palvelimen yksityinen RSA (tai DSS) -avain.Koska se oli lyhytaikainen, se oli olemassa vain RAM-muistissa, eikä sitä koskaan kirjoitettu kiintolevylle; sellaisenaan sen pitäisi olla paljon kestävämpi takaosan varkauksille.

Joten oppitunti on: Yritä pääsääntöisesti käyttää DHE-salauspakettia, jos mahdollista. Muista silti pitää varmuuskopiot ja antaa yksityisen avaimen vuotaa, mutta ainakin DHE-sviitit tekevät tällaisesta vuotamisesta hieman vähemmän ongelman, varsinkin jos se tapahtuu avaimen käyttöiän päättymisen jälkeen (ts. Vastaava varmenne ei ole enää voimassa).

Sertifikaattihäiriöt

Koko varmenteliike on kipeä kohta SSL: ssä.

Teknisesti SSL on melko riippumaton X.509: stä. Sertifikaattiketjut vaihdetaan läpinäkymättöminä tahroina. Jossain vaiheessa asiakkaan on käytettävä palvelimen julkista avainta, mutta asiakas voi vapaasti ”tuntea” avaimen kaikella tavalla, jonka pitää sopivana. Joissakin erityisissä tilanteissa, joissa SSL: ää voidaan käyttää, asiakas tuntee palvelimen jo ”julkinen avain (koodattu kovakoodattu) ja ohittaa vain palvelimen lähettämän varmenteen. Siitä huolimatta yleisessä HTTPS-tapauksessa asiakas tarkistaa palvelimen varmenteketjun tarkistuksen kohdassa X.509 kuvatulla tavalla ( lue se järkevyytesi kustannuksella; sinua on varoitettu).

Tämä tuottaa useita hyökkäysvektoreita, esimerkiksi:

• Vahvistaminen edellyttää tarkistamista, että varmenteet ovat edelleen voimassa nykyisenä päivänä. Mistä asiakaskone tietää nykyisen päivämäärän? Sisäisellä kellollaan ja mahdollisesti puhumalla NTP-palvelinten kanssa ( melko suojaamaton tapa!). Asiakas voi olla poissa muutamilla minuuteilla, tunneilla, päivillä, jopa vuosilla (olen nähnyt sen), ja jossain määrin voimakas hyökkääjä voi pakottaa sen kävelemällä NTP-viestejä. hyökkääjä käyttää vanhentuneita varmenteita, jotka on peruutettu vuosia sitten. Huomaa hauska tosiasia: SSL: n ”asiakas satunnainen” ja ”palvelimen satunnainen” tulisi sisältää 28 satunnaista tavua ja paikallinen päivämäärä ja aika (yli 4 tavua) ajan oli tarkoitus olla osa kiertotapaa aikaperusteisiin hyökkäyksiin. En ole tietoinen toteutuksesta, joka todella tarkistaa sen.

• Vuoteen 2003 saakka varmenteiden vahvistus Internet Explorerissa / Windowsissa ei käsitellyt ”Basic Constraints” -laajennusta. asianmukaisesti. Nettovaikutus oli, että kuka tahansa, jolla oli 100 € sertifikaatti, voisi toimia varmentajana ja antaa ”varmenteita” mielivaltaisesti valitulla nimellä ja avaimilla.

• X .509 sisältää vahingonkorjausominaisuuden nimeltä peruuttaminen : kyse on luettelon karkotetuista varmenteista, jotka näyttävät hyviltä salauksellisesti, mutta joihin ei pitäisi luottaa (esim. Heidän yksityinen avain on varastettu tai ne sisältävät virheellinen nimi). Peruutus toimii vain, jos mukana olevat osapuolet (eli selaimet) suostuvat lataamaan mammuttien peruutusluetteloita (jotka voivat olla useita megatavuja!) Tai ottamaan yhteyttä OCSP-palvelimiin . Nykyaikaiset selaimet tekevät sen nyt, mutta hieman vastahakoisesti, ja monet suostuvat muodostamaan yhteyden joka tapauksessa, jos he eivät pystyneet saamaan peruutustilan tietoja ajoissa (koska ihmiskäyttäjä ei ole kärsivällinen). Yleinen tilanne paranee vuosien varrella, mutta melko hitaasti.

• Jotkut juurivarmentajat tekivät aiemmin virheitä (esim. Comodo ja DigiNotar). Tämä johti väärennettyjen varmenteiden myöntämiseen (nimi on www.microsoft.com, mutta yksityinen avain ei ole lainkaan Microsoftin käsissä …). Nämä virheet löydettiin ja sertifikaatit kumottiin, mutta se herättää kuitenkin joitain epämiellyttäviä kysymyksiä (esim. Onko olemassa muita varmentajia, joilla oli tällaisia ongelmia, mutta jotka eivät paljastaneet niitä, tai mikä vielä pahempaa, eivät koskaan huomanneet niitä?).

X.509 on hyvin monimutkainen algoritmien, tekniikoiden, spesifikaatioiden ja komiteoiden kokoonpano, ja sitä on hyvin vaikea saada oikein. X.509-varmenteiden purkaminen ”käsin” suojaamattomalla ohjelmointikielellä, kuten C, on helppo tapa saada puskurin ylivuotoja.

Bleichenbacher-hyökkäykset

Daniel Bleichenbacher löysi vuonna 1998 mukavan hyökkäyksen RSA: ta vastaan. Kun salaat tietopalan RSA: lla (kuten SSL: n ClientKeyExchange -sanomalle), salattavat tiedot on täytettävä , jotta ne tehdä tavusekvenssi, jonka pituus on sama kuin RSA-moduuli. Täyte koostuu enimmäkseen satunnaisista tavuista, mutta siinä on vähän rakennetta (etenkin kahden ensimmäisen tavun täytön jälkeen on oltava 0x00 0x02).

Salauksen purkamisen jälkeen (palvelimella) täytteen on oltava löytää ja poistaa. Sattuu, että tuolloin, kun palvelin purki salauksen, mutta sai virheellisen täytteen (0x00 0x02 tavua ei ollut), se ilmoitti siitä hälytysviestillä (SSL-määrityksen mukaisesti), kun taas kelvollinen täyte johti palvelin käyttää näennäisesti purettua arvoa ja pitää kiinni kädenpuristuksesta.

Tällainen asia tunnetaan nimellä pehmusteinen oraakkeli . Sen avulla hyökkääjä voi lähettää mielivaltaisen tavujärjestyksen ikään kuin se olisi salattu pre-master-salaisuus, ja tietää, tuottaako kyseisen sekvenssin salauksen purkaminen kelvollisen täytteen vai ei. Se on vain 1-bittinen tieto, mutta riittää palauttamaan yksityinen avain muutamalla miljoonalla pyynnöllä (ovelasti muotoilluilla ”salatuilla” kielillä).

Kiertotapa: kun salauksen purku johtaa virheelliseen täyttö, palvelin jatkaa satunnaisen pre-master-salaisuuden käyttöä. Kättely epäonnistuu myöhemmin myöhemmin Finished -viesteillä. Kaikki SSL: n nykyiset toteutukset tekevät sen.

Pehmusteen Oracle iski takaisin. kirjaa itsensä. Harkitse CBC-salausta ja HMAC: ää. Salattavat tiedot ensin MACed, sitten tulos salataan. CBC-salauksen avulla salattavien tietojen on oltava kerrannaisia lohkon koosta (8 tavua 3DES: lle, 16 tavua AES: lle). Joten käytetään joitain täytteitä, joissa on jonkinlainen rakenne.

Tuolloin (hyökkäyksen löysi Vaudenay vuonna 2002), kun SSL-toteutus käsitteli vastaanottoa d-tietue palautti erilliset hälytysviestit näille kahdelle ehdolle:

• Salauksen purkamisen yhteydessä ei löytynyt kelvollista täytepakettia.
• Salauksen purkamisen yhteydessä kelvollinen täyte löydettiin, mutta sitten MAC vahvistettiin eikä se täsmää.

Tämä on pehmuste-oraakeli, jota voidaan käyttää salattujen tietojen palauttamiseen. Se vaatii aktiivisen hyökkääjän, mutta se ei ole niin vaikeaa. Vaudenay pani sen täytäntöön, ja se laajennettiin tapaukseen, jossa muokattu SSL-toteutus palautti saman hälytysviestin molemmissa tapauksissa, mutta toisessa tapauksessa palautus kesti kauemmin, koska MAC: n uudelleenarviointi vie aikaa. a ajoitushyökkäys ).

Koska ihmiset eivät koskaan opi, ASP.NET: ssä käytetyn SSL: n Microsoft-toteutus oli ei ole vielä ladattu vuodesta 2010 (kahdeksan vuotta myöhemmin!), kun Rizzo ja Duong toteuttivat uudelleen Vaudenay-hyökkäyksen ja rakensivat esittelyn, joka palautti HTTP-evästeet.

Katso tämä sivu joillekin osoittimille. On huomattava, että jos SSL olisi käyttänyt encrypt-then-MAC , tällaisia ongelmia olisi vältetty (vialliset tietueet olisi hylätty MAC-tasolla ennen jopa salauksen purkamista ajatellen).

BEAST

BEAST-hyökkäys on jälleen Duong ja Rizzo, ja jälleen kerran, se on remake vanhemmasta hyökkäyksestä (Philip Rogawayn vuonna 2002). Saadaksesi idean, harkitse CBC . Tässä toimintatilassa kukin tietolohko XORoidaan ensin edellisen lohkon salauksen tuloksena; ja tämä on XOR: n tulos joka on salattu. Tämä tehdään lohkojen ”satunnaistamiseksi” ja EKP-tilassa havaittujen vuotojen välttämiseksi. Koska ensimmäisellä lohkolla ei ole ”edellinen” lohko, siinä täytyy olla alustusvektori (IV), jolla on ensimmäisen lohkon edellisen lohkon rooli.

On käynyt ilmi, että jos hyökkääjä voi hallita salattavan datan osaa ja pystyy myös ennustamaan käytetyn IV: n, hän voi muuttaa salauskoneen uudeksi salauksen purkamiseksi oraakkelin avulla ja palauttaa sen avulla joitain muita salattuja tietoja (joita hyökkääjä ei valitse). SSLv3: ssa ja TLS 1.0: ssa hyökkääjä voi ennustaa tietueen IV: n: se on viimeinen lohko Joten hyökkääjän on pystyttävä lähettämään joitain tietoja virrassa kohdedatan ”työntämiseksi” kohtaan, jossa toteutus rakensi ja lähetti edellisen tietueen (tyypillisesti kun 16 kt: n arvo on dataa on kertynyt), mutta ei alkanut rakentaa seuraavaa.

TLS 1.1+ on suojattu sitä vastaan, koska TLS 1.1: ssa (ja myöhemmissä versioissa) käytetään tietuekohtaista satunnaista IV. SSLv3: n ja TLS 1.0: n kiertotapa on lähettää nollapituiset tietueet: toisin sanoen tietueet, joiden hyötykuorma on nolla – mutta MAC: llä ja täytteellä ja salauksella, ja MAC lasketaan salaisesta avaimesta ja sekvenssin yli numero, joten tämä on satunnaislukugeneraattorin rooli. Valitettavasti IE 6.0 tukehtuu nollapituisissa tietueissa. Muihin strategioihin liittyy 1 / n-1 jako ( n tavuinen tietue lähetetään kahtena tietueena, toisella on yksi tavu hyötykuormaa, toisella jäljellä olevan n-1 ).

Toinen kiertotapa on pakottaa käyttämään muuta kuin CBC-salauspakettia, kun mahdollista – palvelin valitsee RC4-pohjaisen salauspaketin, jos sellaista on käyttäjän lähettämässä salauspakettien luettelossa. asiakas, vaikka asiakas olisi halunnut CBC-pohjaisen salauspaketin. Tämä työkalu voi kertoa, toimiiko tietty palvelin ilmeisesti näin.(Huomaa: BEAST on hyökkäys asiakasta vastaan, mutta valitsemalla RC4-salauspaketin palvelin voi suojata huolimattoman asiakkaan.)

Katso tämä sivu joillekin osoittimille. Vaikka TLS 1.1 on vuodelta 2006, BEAST-hyökkäys voi pakottaa selaimen toimittajat lopulta päivittämään.

CRIME

Kuten mitä tahansa Hollywood-franchising-ohjelmaa varten, Duong ja Rizzo julkaisivat vuonna 2012 jatko-osan. RIKOLLISUUS käyttää hyväksi vuotoa, joka teoretisoitiin vuosia sitten, mutta se osoitettiin elävästi vain heidän äskettäin julkaisemassaan mielenosoituksessa. CRIME hyödyntää pakkaamista samassa asennuksessa kuin BEAST-hyökkäys (hyökkääjä voi lähettää joitain omia tietoja SSL-yhteydellä, johon lähetetään myös mielenkiintoisia kohdetietoja, kuten eväste). Karkeasti ottaen hyökkääjä lisää tietoihinsa potentiaalisen arvon kohdemerkkijonolle, ja jos se täsmää, pakkaus lyhentää tuloksena olevia tietueita. Katso tämä kysymys (esikognitiivinen) analyysi.

RIKOSTEET vältetään, jos TLS-tason pakkausta ei käytetä lainkaan, mikä on mitä selaimet nyt tekevät. Internet Explorer ja IIS eivät koskaan toteuttaneet TLS-tason pakkausta ensinnäkin (huolimattomuus pelasti kerran); Firefox ja Chrome ottivat sen käyttöön ja poiskytkivät toimintansa tänä kesänä (Duong ja Rizzo varoittivat heitä, jotka ovat melko vastuullisia toiminnassaan).

RIKOLLISUUS osoittaa miksi kirjoitin, lähellä SSL-selitykset :

SSL täyttää nämä tavoitteet suuressa määrin (mutta ei absoluuttisesti).

Salaus todellakin vuotaa salattujen tietojen pituuden . Tätä vastaan ei ole tunnettua hyvää ratkaisua. Ja pituus yksin voi paljastaa monia asioita. Esimerkiksi kun tarkkailemme verkkomonitorilla SSL-yhteyttä, voimme havaita ”ylimääräiset kättelyt” virrassa (koska kunkin tietueen ensimmäinen tavu tunnistaa tietueen tietotyypin eikä sitä ole salattu); tietueiden pituuksien kanssa on melko helppo nähdä, toimittiko asiakas varmenteen vai ei.

Villakoira

( edit: tämä osio on lisätty 15.10.2014)

”Villakoira” -hyökkäys käyttää hyväksi SSL 3.0: lle ominaisen virheen CBC-pohjaisten salauspakettien kanssa. Se perustuu SSL 3.0: n usein unohdettuun ominaisuuteen: useimmat täytetavat jätetään huomiotta. TLS 1.0: ssa täyte (tietueeseen lisätyt tavut, jotta pituus olisi yhteensopiva vain täyslohkoja käsittelevän CBC-salauksen kanssa) on määritelty kokonaan; kaikilla tavuilla on oltava tietty arvo ja vastaanottaja tarkistaa sen. SSL 3.0: ssa täytetavujen sisältö jätetään huomioimatta, mikä antaa hyökkääjälle mahdollisuuden tehdä muutoksia, jotka jäävät enimmäkseen huomaamatta. Muutos vaikuttaa vain ei-sovellettavaan dataan, mutta sitä voidaan käyttää salauksen purkuohjelmana tavalla, joka on epämääräinen kuin BEAST.

Lisätietoja on luettavissa tässä vastaus .

Tulevaisuus

Ihmiset eivät koskaan opi. SSL: ään on hienoa lisätä hienoja laajennuksia monista syistä, jotka näyttävät aina hyvältä alussa, mutta voivat aiheuttaa ylimääräisiä ongelmia.

Harkitse esimerkiksi SSL FalseStart . Lähinnä kyse on siitä, että asiakas lähettää sovellustietonsa heti sen jälkeen, kun se on lähettänyt Finished -sanomansa (täydellä kädenpuristuksella), odottamatta Finished viesti palvelimelta. Tämä vähentää latenssia, mikä on hyvää ja hyvää tarkoittavaa. Se kuitenkin muuttaa turvallisuustilannetta: ennen kuin se on saanut Finished -sanoman palvelimelta, jälkimmäinen todennetaan vain implisiittisesti (asiakkaalla ei ole vielä todisteita siitä, että aiottu palvelin oli todella mukana kaikki; se vain tietää, että kaikki, mitä se lähettää, on luettavissa vain tarkoitetulle palvelimelle). Tällä voi olla vaikutuksia; esimerkiksi hyökkääjä voi jäljitellä palvelinta siihen pisteeseen asti ja pakottaa asiakkaan käyttämään esimerkiksi CBC-pohjaista salauspakettia tai TLS-pakkausta. Siksi, jos asiakas ottaa käyttöön FalseStartin, se heikentää BEAST- ja CRIME-suojaustoimenpiteiden tehokkuutta, kuten palvelin muuten voi toteuttaa.

(Google poisti käytöstä FalseStart tänä keväänä, ilmeisesti joidenkin palvelimien yhteensopivuusongelmien vuoksi. Joka tapauksessa ”30%: n viiveen vähentäminen” näytti oudolta, koska FalseStartilla olisi jonkin verran vaikutusta vain täydellisiin kättelyihin, ei lyhennettyihin kättelyihin, joten en ” en usko näihin väitettyihin etuihin; ainakaan siinä määrin.)

Kommentit

• Kuinka paljon ponnistelet hyvän tiedon tarjoamiseksi tämä sivusto on todella hullu ja erittäin ihailtavaa. Arvostettu.
• Katso myös tools.ietf.org / html / rfc7457