SSL

Kokeneet kirjoittajat eivät ole vielä tarkistaneet sivun nykyistä versiota, ja se voi poiketa merkittävästi 13. joulukuuta 2019 tarkistetusta versiosta . tarkastukset vaativat 35 muokkausta .

SSL ( Eng.  Secure Sockets Layer  - suojattujen sockettien taso ) on salausprotokolla, joka edellyttää turvallisempaa yhteyttä. Se käyttää epäsymmetristä kryptografiaa vaihtoavaimien todentamiseen, symmetristä salausta luottamuksellisuuden säilyttämiseksi ja viestien todennuskoodeja viestin eheyden varmistamiseksi. Protokollaa käytettiin laajasti pikaviestintään ja IP-ääneen ( Voice over IP -  VoIP ) sellaisissa sovelluksissa kuin sähköposti , Internet-faksi jne. Vuonna 2014 Yhdysvaltain hallitus ilmoitti protokollan nykyisen version haavoittuvuudesta [1] . SSL tulisi poistaa käytöstä TLS :n sijaan (katso CVE-2014-3566).  

SSL:n kehitti alun perin Netscape Communications lisätäkseen HTTPS-protokollan Netscape Navigator -verkkoselaimeensa . Myöhemmin SSL 3.0 -protokollan pohjalta kehitettiin ja otettiin käyttöön RFC-standardi , joka sai nimen TLS .

Kuvaus

SSL-protokolla tarjoaa suojatun viestinnän seuraavien kahden elementin kautta:

SSL käyttää epäsymmetristä salausta todentamaan vaihtoavaimia, symmetristä salausta ylläpitämään luottamuksellisuutta ja viestien todennuskoodeja viestien eheyden varmistamiseksi.

SSL-protokolla tarjoaa "suojatun kanavan", jolla on kolme pääominaisuutta:

  1. Kanava on yksityinen. Salausta käytetään kaikissa viesteissä yksinkertaisen dialogin jälkeen, jonka avulla voidaan määrittää salainen avain.
  2. Kanava on todennettu. Dialogin palvelinpuoli todennetaan aina, kun taas asiakaspuoli tekee tämän valinnaisesti.
  3. Kanava on luotettava. Viestien siirto sisältää eheyden tarkistuksen.

SSL:n etuna on, että se on riippumaton sovellusprotokollasta. Sovellusprotokollat ​​( HTTP , FTP , TELNET jne.) voivat toimia SSL-protokollan päällä täysin läpinäkyvästi, eli SSL voi neuvotella salausalgoritmin ja istuntoavaimen sekä todentaa palvelimen ennen kuin sovellus vastaanottaa tai lähettää viestin ensimmäinen tavu.

Historia ja kehitys

SSL 1.0, 2.0 ja 3.0

SSL-protokollan on alun perin kehittänyt Netscape Communications . Versiota 1.0 ei koskaan julkaistu yleisölle. Versio 2.0 julkaistiin helmikuussa 1995, mutta se sisälsi monia tietoturvavirheitä, jotka johtivat SSL-version 3.0 kehittämiseen [2] . Vuonna 1996 julkaistu SSL-versio 3.0 oli perusta TLS 1.0:lle, Internet Engineering Task Force ( IETF ) -protokollastandardille, joka määriteltiin ensimmäisen kerran RFC 2246:ssa tammikuussa 1999. Visa , Master Card , American Express ja monet muut organisaatiot ovat oikeutettuja käyttämään SSL-protokollaa kaupallisiin tarkoituksiin Internetissä. Siten SSL on laajennettavissa projektin mukaisesti tukemaan eteenpäin ja taaksepäin yhteensopivuutta ja yhteyksien välistä neuvottelua vertaisverkossa. Maaliskuusta 2011 alkaen RFC 6176:n mukaan TLS-asiakkaat eivät saa käyttää SSL 2.0 -protokollaa pyytäessään yhteyttä palvelimeen, ja palvelimien on hylättävä tällaiset pyynnöt.

TLS 1.0

TLS 1.0 määriteltiin ensimmäisen kerran RFC 2246 :ssa tammikuussa 1999 päivityksenä SSL 3.0:aan. Kuten RFC:ssä todetaan, "erot tämän protokollan ja SSL 3.0:n välillä eivät ole kriittisiä, mutta ne ovat merkittäviä TLS 1.0:n ja SSL 3.0:n välisten yhteensopimattomien ilmenemisen kannalta." TLS 1.0 sisältää keinot, joilla TLS–SSL 3.0 -yhteyden käyttöönotto heikentäisi turvallisuutta.

TLS 1.1

TLS 1.1 otettiin käyttöön RFC 4346 :ssa huhtikuussa 2006 [3] . Tämä oli päivitys TLS-versioon 1.0. Tämän version merkittäviä muutoksia ovat mm.

TLS 1.2

TLS 1.2 julkistettiin RFC 5246 :ssa elokuussa 2008. Se perustuu aiemmin ehdotettuun TLS 1.1 -versioon.

TLS 1.3

TLS 1.3 tunnustettiin standardiksi RFC 8446 :ssa elokuussa 2018.

Kuinka se toimii

SSL käyttää monikerroksista ympäristöä varmistaakseen tiedonvaihdon turvallisuuden. Viestinnän luottamuksellisuus on olemassa, koska suojattu yhteys on avoin vain kohdekäyttäjille.

Kerrostettu ympäristö

SSL-protokolla on kahden protokollan välissä: asiakasohjelman käyttämän protokollan (HTTP, FTP, LDAP, TELNET jne.) ja TCP/IP-siirtoprotokollan välissä. SSL suojaa dataa toimimalla suodattimena molemmille puolille ja välittää sen edelleen kuljetuskerrokseen [4] [5] .

Protokollan toiminta voidaan jakaa kahteen tasoon:

  1. Handshake Protocol Layer
  2. Tallennusprotokollakerros

Ensimmäinen kerros puolestaan ​​koostuu kolmesta aliprotokollasta:

  1. Kädenpuristusprotokolla
  2. Salausmääritysprotokolla
  3. Varoitusprotokolla

Yhteyden kättelyprotokollaa käytetään istuntotietojen neuvottelemiseen asiakkaan ja palvelimen välillä. Istuntotiedot sisältävät:

Yhteyden kättelyprotokolla tuottaa tiedonvaihtoketjun, joka puolestaan ​​aloittaa osapuolten autentikoinnin ja sopi salauksesta, hajauttamisesta ja pakkaamisesta. Seuraava vaihe on osallistujien autentikointi, joka myös suoritetaan yhteyden vahvistusprotokollalla.

Salausparametrien muutosprotokollaa käytetään avaintietojen (avainmateriaalin) muuttamiseen - tietoihin, joita käytetään salausavainten luomiseen. Protokolla koostuu vain yhdestä viestistä, jossa palvelin ilmoittaa, että lähettäjä haluaa muuttaa avainjoukkoa.

Varoitusprotokolla sisältää viestin, joka ilmoittaa osapuolille tilanmuutoksesta tai mahdollisesta virheestä. Yleensä varoitus lähetetään, kun yhteys suljetaan ja virheellinen viesti vastaanotetaan, viestin salausta ei voida purkaa tai käyttäjä peruuttaa toiminnon.

Digitaaliset sertifikaatit

SSL-protokolla varmistaa varmenteiden avulla, että julkinen avain kuuluu sen todelliselle omistajalle. Tapoja hankkia SSL-sertifikaatti:

  1. Käytä CA :n myöntämää varmennetta
  2. Käytä itse allekirjoitettua varmennetta
  3. Käytä "tyhjää" varmennetta

Itse allekirjoitettu varmenne - käyttäjän itsensä luoma varmenne - tässä tapauksessa varmenteen myöntäjä on sama kuin varmenteen omistaja. "Tyhjä" varmenne on varmenne, joka sisältää kuvitteellisia tietoja, joita käytetään väliaikaisena SSL:n määrittämiseen ja sen toimivuuden tarkistamiseen tietyssä ympäristössä.

SSL - varmenteiden joukossa on toimialueen validoituja varmenteita ja laajennettuja vahvistusvarmenteita .  Jälkimmäinen liittää verkkotunnuksen todelliseen henkilöön tai yhteisöön.

Mekanismit nykyisen istunnon avaimen johtamiseksi SSL/TLS:ssä

Avainten luontialgoritmeja on neljä: RSA , Fixed Diffie-Hellman, Ephemeral Diffie-Hellman, Anonymous Diffie-Hellman

rsa

Kun yksityinen RSA-avain "kadotetaan", sen vastaanottava kryptanalyytikko saa mahdollisuuden purkaa kaikkien tallennettujen menneiden ja tulevien viestien salaus. Avaimenvaihdon toteutus RSA:ssa on yksisuuntainen: kaikki kättelyvaiheessa syntyvän symmetrisen avaimen muodostamiseen tarvittava tieto lähetetään palvelimelle ja salataan palvelimen julkisella avaimella. Yksityisen avaimen paljastaminen mahdollistaa tämän istunnon symmetrisen avaimen selvittämisen.

Diffie-Hellman

Fixed Diffie - Hellman -mekanismi käyttää pysyvää julkista avainta, joka on rekisteröity palvelimen varmenteeseen. Tämä tarkoittaa myös sitä, että jokaisessa uudessa yhteydessä asiakas antaa oman osan avaimesta. Avaimenvaihdon jälkeen muodostetaan uusi symmetrinen avain nykyisen istunnon tietojen vaihtamiseksi. Paljastamalla palvelimen yksityisen avaimen kryptanalyytikko voi purkaa aiemmin tallennetut viestit sekä kaikki tulevat viestit. Tämän tekee mahdolliseksi itse mekanismi. Koska kryptanalyytikko tietää palvelimen yksityisen avaimen, hän pystyy selvittämään jokaisen istunnon symmetrisen avaimen, eikä edes se, että avainten luontimekanismi on kaksisuuntainen, auta.
Anonymous Diffie - Hellman -mekanismi ei takaa yksityisyyttä, koska tiedot siirretään salaamattomina.
Ainoa vaihtoehto, joka takaa menneiden ja tulevien viestien turvallisuuden, on Ephemeral Diffie-Hellman . Erona aiemmin käsiteltyihin menetelmiin on se, että jokaisen uuden yhteyden yhteydessä palvelin ja asiakas luovat kerta-avaimen. Siten, vaikka kryptanalyytikko saisi nykyisen yksityisen avaimen, hän voi purkaa vain nykyisen istunnon, mutta ei aiempia tai tulevia istuntoja.

Salauksen ominaisuudet

Tietojen salaamiseen on kaksi päätapaa: symmetrinen salaus (jaettu salainen avain) ja epäsymmetrinen salaus (julkinen/yksityinen avainpari).

SSL käyttää sekä epäsymmetristä että symmetristä salausta.

Epäsymmetrisen salauksen ydin on, että käytetään avaimia. Yhtä avaimista kutsutaan julkiseksi (yleensä se julkaistaan ​​itse omistajan varmenteessa), ja toista avainta kutsutaan yksityiseksi - se pidetään salassa. Molempia avaimia käytetään pareittain: julkista avainta käytetään tietojen salaamiseen ja yksityistä avainta käytetään salauksen purkamiseen. Tämä suhde antaa sinun tehdä kaksi tärkeää asiaa.

  1. Kuka tahansa käyttäjä voi hankkia julkisen avaimen ja käyttää sitä salaamaan tietoja, joiden salauksen voi purkaa vain yksityisen avaimen omistava käyttäjä.
  2. Jos avainparin omistaja "salaa" (allekirjoittaa) tiedot yksityisellä avaimellaan, niin jokainen voi varmistaa, että tiedot on lähettänyt yksityisen avaimen omistaja eikä kolmas osapuoli ole muuttanut sitä. Tämä on digitaalisten allekirjoitusten perusta .

RSA  on yksi yleisimmin käytetyistä epäsymmetrisistä salausalgoritmeista.

Symmetrisessä salauksessa samaa avainta käytetään sekä tietojen salaamiseen että salauksen purkamiseen. Jos osapuolet haluavat vaihtaa salattuja viestejä turvallisesti, molemmilla osapuolilla on oltava samat symmetriset avaimet. Tämän tyyppistä salausta käytetään suurille tietomäärille (koska symmetrinen salaus on nopeampi). Yleisesti käytetyt algoritmit ovat DES , 3-DES , RC2 , RC4 ja AES .

SSL-protokolla käyttää julkisen avaimen salausta asiakkaan ja palvelimen keskinäiseen autentikointiin (digitaalisen allekirjoitustekniikan avulla) sekä istuntoavaimen luomiseen, jota puolestaan ​​nopeammat symmetriset salausalgoritmit käyttävät suuren tietomäärän salaamiseen. .

Hashing

Hajautusarvo on viestin tunniste, sen koko on pienempi kuin alkuperäisen viestin koko. Tunnetuimmat hash-algoritmit ovat MD5 (Message Digest 5), joka tuottaa 128-bittisen hash-arvon, SHA-1 (Secure Hash Algorithm), joka tuottaa 160-bittisen hash-arvon, SHA-2 ja SHA-3 . Hajautusalgoritmin tulos on arvo, jota käytetään tiedonsiirron eheyden tarkistamiseen.

Äänitystaso

Tallennuskerroksen tason protokolla vastaanottaa salattua dataa asiakasohjelmasta ja siirtää sen siirtokerrokseen. Tallennusprotokolla ottaa tiedot, jakaa ne lohkoiksi ja suorittaa tietojen salauksen (salauksen purkamisen). Samalla käytetään aktiivisesti tietoja, joista on sovittu tietojen vahvistamisen yhteydessä.

SSL-protokolla mahdollistaa symmetrisen avaimen salauksen käyttämällä joko lohkosalauksia tai virtasalauksia . Lohkosalauksia käytetään yleisesti käytännössä. Lohkosalauksen toimintaperiaate on kartoittaa selvätekstilohko samaan salatekstilohkoon. Tämä salaus voidaan esittää taulukkona, joka sisältää 2 128 riviä, joista jokainen sisältää selvätekstilohkon M ja sitä vastaavan salatekstilohkon C. Jokaiselle avaimelle on olemassa samanlainen taulukko.

Salaus voidaan esittää funktiona

C = E ( Key , M ), jossa M  on alkuperäinen data, Avain  on salausavain, C  on salattu data.

Lohkot ovat yleensä pieniä (yleensä 16 tavua), joten herää kysymys: kuinka pitkä viesti salataan?
Ensimmäinen tällaisen salauksen tila on nimeltään ECB (Electronic Codebook) tai yksinkertainen korvaustila. Sen ydin on, että jaamme alkuperäisen viestin lohkoihin (samalle 16 tavulle) ja salaamme jokaisen lohkon erikseen. Tätä tilaa käytetään kuitenkin harvoin lähdetekstin tilastollisten ominaisuuksien säilyttämisongelman vuoksi: 2 identtistä selkeän tekstin lohkoa salauksen jälkeen muuttuu kahdeksi identtiseksi salatekstilohkoksi.
Tämän ongelman ratkaisemiseksi kehitettiin toinen tila - CBC (Cipher-block chaining). Tässä tapauksessa jokainen uusi salatekstilohko XOR-koodataan edellisen salaustuloksen kanssa. Ensimmäinen lohko on XOR-muotoinen jollakin alustusvektorilla (Initialization Vector, IV). Kaikki yllä oleva teoria on kuitenkin kehitetty yhdelle suurelle objektille, kun taas SSL:n on salausprotokollana salattava sarja paketteja. Tällaisessa tilanteessa on kaksi tapaa soveltaa CBC:tä:

  1. Käsittele jokaista viestiä erillisenä objektina ja luo sille joka kerta uusi alustusvektori
  2. Käsittele kaikkia viestejä yhtenä suurena kohteena pitäen CBC-tilan niiden välillä. Tässä tapauksessa edellisen viestin viimeistä salauslohkoa (n-1) käytetään viestin n alustusvektorina.

Sovellus

Sovelluksia suunniteltaessa SSL otetaan käyttöön minkä tahansa muun sovelluskerroksen protokollan, kuten HTTP :n , FTP :n , SMTP :n , NNTP :n ja XMPP :n "alle" , mikä tarjoaa "avoimuutta" sen käyttöön. Historiallisesti SSL:ää on käytetty ensisijaisesti luotettavien siirtoprotokollien, kuten Transmission Control Protocol (TCP) kanssa. Se on kuitenkin toteutettu myös datagrammien siirtoprotokollien, kuten User Datagram Protocol (UDP) ja Datagram Control Protocol (DCCP) kanssa, joiden käyttö on standardoitu, mistä on syntynyt termi Datagram Transport Layer Security (DTLS).

Verkkosivustot

SSL-protokollan toistuva käyttö on johtanut HTTPS -protokollan (Hypertext Transfer Protocol Secure) muodostumiseen, joka tukee salausta. HTTPS -protokollan kautta siirrettävät tiedot "pakataan" SSL- tai TLS -salausprotokollaan , mikä varmistaa näiden tietojen suojauksen. Tätä suojausmenetelmää käytetään laajasti verkkomaailmassa sovelluksissa, joissa yhteyden turvallisuus on tärkeää, kuten maksujärjestelmissä. Toisin kuin HTTP , HTTPS käyttää oletuksena TCP - porttia 443.

Verkkosivuston tuki protokollalle [6]
Protokollan versio Turvallisuus Verkkosivuston tuki
SSL 2.0 Ei 4,9 %
SSL 3.0 Ei 16,6 %
TLS 1.0 Voi olla 94,7 %
TLS 1.1 Joo 82,6 %
TLS 1.2 85,5 %

Selaimet

Vuoden 2017 alusta lähtien kaikki tärkeimmät SSL/TLS:ää tukevat verkkoselaimet ovat:

Selaimet, jotka tukevat SSL/TLS:ää
Selain Alustat TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3
Kromi 1-21 Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8) Joo Ei Ei Ei
Kromi 29-53 Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8,10) kyllä ​​[7] kyllä ​​[7] kyllä ​​[8] Ei
Chrome 58+ Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8,10) Joo Joo Joo Joo
Firefox 1-27 Linux, Mac OS X, Windows (XP, Vista, 7, 8) kyllä ​​[9] Ei [10] Ei [11] Ei
Firefox 27-53 Linux, Mac OS X, Windows (XP, Vista, 7, 8) Joo Joo Joo Ei
Firefox 54+ Linux, Mac OS X, Windows (XP, Vista, 7, 8) Joo Joo Joo Joo
IE6 Windows (XP) Joo Ei Ei Ei
IE 7-8 _ Windows (XP, Vista) Joo Ei Ei Ei
IE 8-9 _ Windows 7 Joo Joo Joo Ei
IE9 Windows Vista Joo Ei Ei Ei
IE 10+ Windows (7, 8) Joo Joo Joo Ei
Reuna 12-15 Windows 10 Joo Joo Joo Ei
Ooppera 5-7 Linux, Mac OS X, Windows Kyllä [12] Ei Ei Ei
Ooppera 8-9 Linux, Mac OS X, Windows Joo Kyllä [13] Ei Ei
Opera 10+ Linux, Mac OS X, Windows Joo Joo Joo Ei
Opera 44+ Linux, Mac OS X, Windows Joo Joo Joo Joo
Safari 4 Mac OS X, Windows (XP, Vista, 7), iOS 4.0 Joo Ei Ei Ei
Safari 5 Mac OS X, Windows (XP, Vista, 7) Joo Ei Ei Ei
Safari 7-10 iOS 5.0- Joo Joo Joo Ei

Tekniset tiedot:

Käyttö ja toteutus

Alun perin SSL-pohjaisia ​​virtuaalisia yksityisverkkoja ( VPN ) kehitettiin täydentäväksi ja vaihtoehtoiseksi IPsec VPN :ään perustuvaksi etäkäyttötekniikaksi . Riittävä luotettavuus ja alhaiset kustannukset tekivät tästä tekniikasta kuitenkin houkuttelevan VPN-organisaatioille. SSL on laajalti käytössä myös sähköpostissa.

SSL:n yleisin toteutus on avoimen lähdekoodin salauspaketti OpenSSL , joka perustuu Eric Youngin kirjoittamaan SSLeayhin . OpenSSL:n uusin versio tukee SSLv3:a. Paketti on suunniteltu luomaan ja hallitsemaan erilaisia ​​varmenteita . Se sisältää myös kirjaston eri ohjelmien SSL-tukea varten. Kirjastoa käyttää esimerkiksi yleisen Apache HTTP -palvelimen SSL-moduuli .

SSL Record Protocol Specification

SSL-tietueen otsikon muoto

Kaikki SSL-tiedot lähetetään tietueiden (tietueiden) muodossa - objekteina, jotka koostuvat otsikosta ja tietystä määrästä tietoa. Jokainen tietueen otsikko sisältää 2 tai 3 tavua pituuskoodia. Jos tietueen pituuskoodin ensimmäisen tavun merkittävin bitti on 1, tietueessa ei ole täyttöä ja otsikon kokonaispituus on 2 tavua, muuten tietue sisältää täytön ja otsikon kokonaispituus on 3 tavua. Pitkän (3 tavua) otsikon tapauksessa ensimmäisen tavun toiseksi merkittävimmällä bitillä on erityinen merkitys. Jos se on yhtä kuin 0 - tietue on informatiivinen, jos se on yhtä suuri kuin 1 - tietue on turvapoikkeama. Tietueen pituuskoodi ei sisällä otsikkotavujen määrää. 2-tavuisen otsikon pituus lasketaan seuraavasti:

TIETUUSPITUUS = ((tavu[0] & 0x7F) << 8) | tavu[1];

Tässä tavu[0] on ensimmäinen vastaanotettu tavu ja tavu[1] on toinen vastaanotettu tavu.
3-tavuisen otsikon tietueen pituus lasketaan seuraavasti:

TIETUUSPITUUS = ((tavu[0] & 0x3F) <<8) | tavu[1];
IS-ESCAPE = (tavu[0] & 0x40) !=0;
TÄYTTÖ = tavu[2];

PADDING -arvo määrittää lähettäjän alkuperäiseen tietueeseen lisäämien tavujen määrän . Täytetietoja käytetään tekemään tietueen pituudesta salauslohkon koon monikerta. Lähettäjä lisää TÄYTEEN annettujen tietojen jälkeen ja salaa sitten kaiken, koska tämän taulukon pituus on monikertainen käytetyn salauksen lohkokoon. Koska lähetetyn datan määrä on tiedossa, viestin otsikko voidaan muodostaa ottaen huomioon PADDING :n määrä . Viestin vastaanottaja purkaa koko tietokentän salauksen ja saa alkuperäiset tiedot, laskee sitten RECORD-LENGTH todellisen arvon , kun taas TÄYTE poistetaan "data"-kentästä.

SSL-tiedon tallennusmuoto

SSL-tietueen dataosa koostuu kolmesta osasta:

  1. MAC-TIEDOT[MAC-KOKO]
  2. TODELLISET TIEDOT[N]
  3. TÄYTTÖ-TIEDOT[TÄYTÖS]

MAC-DATA  - viestin todennuskoodi
MAC-SIZE - tiivistesumman  laskemiseen käytetyn algoritmin toiminto
ACTUAL-DATA  - todellisuudessa lähetetty data tai viestin tietokenttä
TÄYTE-DATA  - TÄYTE -data (lohkosalauksella)

MAC-DATA = HASH [ SALAINEN , TODELLISET TIEDOT , TÄYTTÖTIEDOT , JÄRJESTELMÄNUMERO ]

Tässä SECRET välitetään ensin hash-funktiolle, sen jälkeen ACTUAL-DATA ja PADDING-DATA , jota seuraa järjestysnumero SEQUENCE-NUMBER  . SECRET
- arvon arvo riippuu siitä, kuka viestin lähettää. Jos asiakas tekee niin, SECRET on yhtä kuin CLIENT-WRITE-KEY . Jos asiakas vastaanottaa viestin, SECRET on yhtä kuin CLIENT-READ-KEY . Järjestysnumero on 32-bittinen koodi, joka välitetään hash-funktiolle 4 tavuna käyttämällä verkkojärjestystä korkeasta matalaan. Järjestysnumero on palvelimen tai asiakkaan laskuri. Jokaiselle lähetyssuunnalle käytetään laskurien paria - lähettäjälle ja vastaanottajalle; joka kerta kun viesti lähetetään, laskuri kasvaa 1:llä. Viestin vastaanottaja käyttää odotettua järjestysnumeron arvoa lähettääkseen MAC :n (hajautustyypin määrittää CIPHER-CHOICE- parametri ). Lasketun MAC-DATA- arvon on vastattava lähetettyä arvoa. Jos vertailu epäonnistuu, sanoman katsotaan olevan vioittunut, mikä johtaa virheeseen, joka aiheuttaa yhteyden sulkemisen. Lopullinen täsmäystarkistus suoritetaan, kun käytetään lohkosalausta. Viestin datamäärän ( RECORD-LENGTH ) on oltava salauslohkon koon kerrannainen. Jos tämä ehto ei täyty, sanoman katsotaan olevan vioittunut, mikä johtaa yhteyden katkeamiseen.


2-tavuisen otsikon viestin maksimipituus on 32767 tavua, 3-tavuisen otsikossa 16383 tavua. SSL-keskusteluprotokollaviestien on vastattava yksittäisiä SSL-protokollatietueita, ja sovellusprotokollaviestit voivat varata useita SSL-tietueita.

SSL Conversation Protocol

SSL-keskusteluprotokolla sisältää 2 päävaihetta.

Vaihe 1

Ensimmäisessä vaiheessa luodaan luottamuksellinen viestintäkanava.
Tämä vaihe alustaa yhteyden, kun molemmat kumppanit vaihtavat "hei"-viestejä. Asiakas lähettää CLIENT-HELLO -viestin . Palvelin vastaanottaa tämän viestin, käsittelee sen ja lähettää takaisin SERVER-HELLO- sanoman .
Tässä vaiheessa sekä palvelimella että asiakkaalla on riittävästi tietoa tietääkseen, tarvitaanko uutta pääavainta. Jos avainta ei tarvita, palvelin ja asiakas siirtyvät vaiheeseen 2.
Kun uusi pääavain on luotava , palvelimen SERVER-HELLO- sanoma sisältää jo tarpeeksi dataa, jotta asiakas voi luoda pääavaimen . Nämä tiedot sisältävät palvelimen allekirjoitetun varmenteen, luettelon perussalauksista ja yhteystunnuksen (palvelimen luoma satunnaisluku, jota käytetään koko istunnon aikana). Kun asiakas on luonut pääavaimen , se lähettää palvelimelle CLIENT-MASTER-KEY -sanoman tai virhesanoman, kun asiakas ja palvelin eivät pääse sopimaan perussalauksesta. Pääavaimen
määrittämisen jälkeen palvelin lähettää asiakkaalle SERVER-VERIFY -viestin , joka todentaa palvelimen.

Vaihe 2

Vaihe 2 on nimeltään todennusvaihe. Koska palvelin on jo todennettu ensimmäisessä vaiheessa, asiakas todennetaan toisessa vaiheessa. Palvelin lähettää asiakkaalle pyynnön, ja jos asiakkaalla on tarvittavat tiedot, se lähettää myönteisen vastauksen, jos ei, virheilmoituksen. Kun yksi vertaiskäyttäjä on todentanut toisen kumppanin, se lähettää valmiin viestin . Asiakkaan tapauksessa CLIENT-FINISHED -sanoma sisältää CONNECTION-ID :n salatun muodon, joka palvelimen on tarkistettava. Jos vahvistus epäonnistui, palvelin lähettää ERROR -viestin .
Kun toinen vertaishenkilöistä on lähettänyt valmiin viestin , sen on hyväksyttävä viestejä, kunnes se vastaanottaa valmiin viestin toiselta vertaiselta, ja vasta kun molemmat vertaiskumppanit ovat lähettäneet ja vastaanottaneet valmiit viestit , SSL-keskusteluprotokolla päättyy. Tästä hetkestä lähtien sovellusprotokolla alkaa toimia.

Generic Messaging Protocol

Alla on useita vaihtoehtoja viestien vaihtamiseen SSL-keskusteluprotokollan sisällä. Asiakas on C , palvelin on S. "{smth}avain" tarkoittaa, että "smth" on salattu avaimella.

Istuntotunnuksen puuttuessa
asiakas-hei C®S: haaste, cipher_specs
palvelin-hei S® C: yhteystunnus,palvelinvarmenne,salauksen_tiedot
asiakas-pääavain C®S: {master_key}palvelin_julkinen_avain
asiakas-viimeistely C®S: {connection-id}client_write_key
palvelimen tarkistus S® C: {challenge}palvelin_kirjoitusavain
palvelin-viimeistely S® C: {new_session_id}server_write_key
Asiakas ja palvelin löysivät istunnon tunnuksen
asiakas-hei C®S: haaste, session_id, salaustiedot
palvelin-hei S® C: yhteystunnus, istunnon_tunnus_osuma
asiakas-viimeistely C®S: {connection-id}client_write_key
palvelimen tarkistus S® C: {challenge}palvelin_kirjoitusavain
palvelin-viimeistely S® C: {session_id}server_write_key
Käytetty istunnon tunnus ja asiakkaan todennus
asiakas-hei C®S: haaste, session_id, salaustiedot
palvelin-hei S® C: yhteystunnus, istunnon_tunnus_osuma
asiakas-viimeistely C®S: {connection-id}client_write_key
palvelimen tarkistus S® C: {challenge}palvelin_kirjoitusavain
Pyydä todistus S® C: {auth_type ,challenge'}server_write_key
asiakastodistus C®S: {cert_type,client_cert,response_data}client_write_key
palvelin-viimeistely S® C: {new_session_id}server_write_key

Todennus ja avainten vaihto

SSL tukee kolmea todennustyyppiä:

  • molempien osapuolten todennus (asiakas - palvelin),
  • palvelimen todennus todentamattomalla asiakkaalla,
  • täydellinen nimettömyys.

Jos palvelin on todennettu, sen varmenneviestissä on oltava oikea varmennusketju, joka johtaa hyväksyttävään CA:han. Yksinkertaisesti sanottuna autentikoidun palvelimen on annettava asiakkaalle voimassa oleva varmenne. Kumpikin osapuoli on vastuussa siitä, että toisen osapuolen varmenne ei ole vielä vanhentunut tai peruutettu. Aina kun palvelin todentaa, kanava on vastustuskykyinen (suojattu) verkkopalvelimen ja selaimen väliselle yritykselle siepata dataa, mutta täysin anonyymi istunto on luonnostaan ​​alttiina tällaiselle hyökkäykselle. Anonyymi palvelin ei voi todentaa asiakasta. Avaintenvaihtoprosessin päätarkoitus on luoda asiakassalaisuus (pre_master_secret), jonka vain asiakas ja palvelin tuntevat. Salaisuutta (pre_master_secret) käytetään jaetun salaisuuden (master_secret) luomiseen. Jaettua salaisuutta tarvitaan viestin luomiseen varmenteen, salausavainten, MAC - salaisuuden (message authentication code) ja valmiin viestin vahvistamiseksi. Lähettämällä valmiin viestin osapuolet ilmoittavat tietävänsä oikean salaisuuden (pre_master_secret).

Anonyymi avainten vaihto

Täysin anonyymi istunto voidaan muodostaa käyttämällä RSA- tai Diffie-Hellman-algoritmia vaihtoavainten luomiseen. Käytettäessä RSA :ta asiakas salaa salaisuuden (pre_master_secret) sertifioimattoman palvelimen julkisella avaimella. Asiakas oppii julkisen avaimen palvelimelta tulevasta avaimenvaihtosanomasta. Tulos lähetetään asiakkaalta avaimenvaihtosanomassa. Koska sieppaaja ei tiedä palvelimen yksityistä avainta, sen on mahdotonta purkaa salaisuutta (pre_master_secret). Diffie-Hellman-algoritmia käytettäessä palvelimen julkiset parametrit sisältyvät palvelimelta tulevaan avaimenvaihtosanomaan ja lähetetään asiakkaalle avaimenvaihtosanomassa. Sieppaaja, joka ei tunne yksityisiä arvoja, ei pysty löytämään salaisuutta (pre_master_secret).

Todennus ja avainten vaihto RSA:n avulla

Tässä tapauksessa avainten vaihto ja palvelimen todennus voidaan yhdistää. Julkinen avain voi myös sisältyä palvelimen varmenteeseen tai voidaan käyttää väliaikaista RSA -avainta, joka lähetetään avaimenvaihtosanomassa palvelimelta. Käytettäessä väliaikaista RSA-avainta vaihtoviestit allekirjoitetaan palvelimen RSA- tai DSS-sertifikaatilla (???). Allekirjoitus sisältää Client_Hello.random-viestin nykyisen arvon, joten vanhoja allekirjoituksia ja vanhoja väliaikaisia ​​avaimia ei voida toistaa. Palvelin voi käyttää väliaikaista RSA-avainta vain kerran istunnon luomiseen. Tarkastettuaan palvelimen varmenteen asiakas salaa salaisuuden (pre_master_secret) palvelimen julkisella avaimella. Kun salaisuuden (pre_master_secret) dekoodaus on onnistunut, generoidaan "valmis"-sanoma, joka osoittaa palvelimelle, että se tietää palvelimen varmennetta vastaavan yksityisen avaimen.

Kun RSA:ta käytetään avainten vaihtoon, asiakasvarmenteen vahvistusviestiä käytetään asiakkaan todentamiseen. Asiakas allekirjoittaa master_secret-sanomasta ja kaikista edeltävistä kättelyprotokollasanomista lasketun arvon. Nämä kättelyviestit sisältävät palvelinvarmenteen, joka vastaa palvelimen allekirjoitusta Server_Hello.random-sanoman kanssa, joka vastaa nykyisen kättelyviestin allekirjoitusta (???).

Todennus ja avainten vaihto Diffie-Hellmanin avulla

Tässä tapauksessa palvelin voi myös tukea parametrikohtaista Diffie-Hellman-algoritmia, tai se voi käyttää palvelimen avaintenvaihtosanomia lähettääkseen joukon väliaikaisia ​​parametreja, jotka on allekirjoitettu DSS- tai RSA-varmenteilla. Väliaikaiset parametrit tiivistetään hello.random-viestillä ennen allekirjoittamista, jotta hyökkääjä ei toista vanhoja parametreja. Kummassakin tapauksessa asiakas voi tarkistaa varmenteen tai allekirjoituksen varmistaakseen, että parametrit kuuluvat palvelimelle.

Jos asiakkaalla on varmenne, joka sisältää Diffie-Hellman- algoritmin parametrit, sertifikaatti sisältää myös avaimenvaihdon suorittamiseen tarvittavat tiedot. Tässä tapauksessa asiakkaan ja palvelimen on luotava samat Diffie-Hellman-tulokset (pre_master_secret) joka kerta, kun ne muodostavat yhteyden. Jotta salaisuus (pre_master_secret) ei säilyisi tietokoneen muistissa pidempään kuin on tarpeen, salaisuus tulee muuntaa jaetuksi salaisuudeksi (master_secret) mahdollisimman nopeasti. Asiakkaan asetusten on oltava yhteensopivia palvelimen tukemien asetusten kanssa, jotta avainten vaihto toimisi.

Tallennusprotokolla

Record Layer -protokolla on kerrostettu protokolla. Jokaisella tasolla viestit sisältävät pituutta, kuvausta ja vahvistusta koskevat kentät. Kirjoitusprotokolla vastaanottaa lähetettävät viestit, pilkkoo tiedot hallittaviksi lohkoiksi, pakkaa tiedot älykkäästi MAC:n (viestin autentikointikoodin) avulla, salaa ja lähettää tuloksen. Se purkaa vastaanotetun tiedon salauksen, tarkistaa, purkaa, kerää ja toimittaa ylemmille asiakastasoille.

Tallennusprotokollaa on neljä:

  1. Handshake protokolla;
  2. Varoitusprotokolla;
  3. Muutossalauksen spesifikaatioprotokolla;
  4. Sovellusprotokolla (sovellusdataprotokolla);

Jos SSL-toteutus vastaanottaa merkintätyypin, jota se ei tiedä, kyseinen merkintä yksinkertaisesti ohitetaan. Kaikki protokollat, jotka on luotu käytettäväksi SSL:n kanssa, on harkittava hyvin, koska ne joutuvat käsittelemään niitä vastaan ​​kohdistuvia hyökkäyksiä. Huomaa, että tietueen tyypistä ja pituudesta johtuen protokollaa ei suojata salauksella. Liikenteen minimoimisesta tulee huolehtia.

Handshake protokolla

SSL-asiakas ja palvelin sopivat muodostavansa yhteyden kättelymenettelyllä. Kättelyn aikana asiakas ja palvelin sopivat useista parametreista, joita käytetään yhteyden turvaamiseen:

  1. Asiakas lähettää palvelimelle asiakkaan SSL-versionumeron, tuetut salaus- ja pakkausalgoritmit, istuntokohtaiset tiedot ja muut tiedot, joita palvelin tarvitsee kommunikoidakseen asiakkaan kanssa SSL:n avulla.
  2. Palvelin lähettää asiakkaalle palvelimen SSL-versionumeron, pakkaus- ja salausalgoritmin (valittu asiakkaan aiemmin lähettämistä), istuntokohtaiset tiedot ja muut tiedot, joita asiakas tarvitsee kommunikoidakseen palvelimen kanssa SSL:n kautta. Palvelin lähettää myös oman varmenteensa, mikä edellyttää asiakkaan todennusta. Todennuksen jälkeen palvelin pyytää asiakassertifikaattia.
  3. Asiakas käyttää todentamiseen palvelimen välittämiä tietoja. Jos palvelinta ei voida varmentaa, käyttäjää varoitetaan, että on olemassa ongelma ja että yhteyden salausta ja todennusta ei voida määrittää. Jos palvelin läpäisi testin, asiakas siirtyy seuraavaan vaiheeseen.
  4. Käyttäen kaikkia kättelymenettelystä tähän mennessä vastaanotettuja tietoja, asiakas (yhteistyössä palvelimen kanssa) luo istunnon esijaetun salaisuuden, riippuen palvelimelta käytetystä salauksesta, salaa sen palvelimen julkisella avaimella (saatu palvelimen toisessa vaiheessa lähetetty varmenne) ja lähettää sen sitten palvelimelle.
  5. Jos palvelin on pyytänyt asiakkaan todennusta (valinnainen kättelyvaihe), asiakas allekirjoittaa myös toisen datan, joka on ainutlaatuinen kyseiselle kättelylle ja jonka sekä asiakas että palvelin tuntevat. Tällöin asiakas lähettää palvelimelle kaikki allekirjoitetut tiedot ja asiakkaan oman varmenteen esisalatun salaisuuden mukana.
  6. Palvelin yrittää todentaa asiakkaan. Jos asiakas ei pysty todentamaan, istunto päättyy. Jos asiakas voidaan todentaa onnistuneesti, palvelin käyttää yksityistä avaintaan esisalaisuuden purkamiseen ja käy sitten läpi sarjan vaiheita (jotka myös asiakas käy läpi) luodakseen pääsalaisuuden.
  7. Sekä asiakas että palvelin käyttävät salaisuutta istuntoavainten luomiseen, jotka ovat symmetrisiä avaimia, joita käytetään SSL-istunnon aikana vaihdetun tiedon salaamiseen ja salauksen purkamiseen. Eheystarkistus tapahtuu (toisin sanoen tiedoissa tapahtuvien muutosten havaitsemiseksi sen lähetysajan ja SSL-yhteydellä vastaanoton välillä).
  8. Asiakas lähettää palvelimelle viestin, jossa kerrotaan, että tulevat asiakkaan viestit salataan istuntoavaimella. Sitten se lähettää erillisen, salatun viestin, että kättelyosa on ohi.
  9. Lopuksi palvelin lähettää asiakkaalle viestin, jossa kerrotaan, että tulevat viestit palvelimelta salataan istuntoavaimella. Sitten se lähettää erillisen, salatun viestin, että kättelyosa on ohi.

Tämä päättää kättelyn ja aloittaa suojatun yhteyden, joka salataan ja salaus puretaan avaindatan avulla. Jos jokin yllä olevista epäonnistuu, SSL-kättely on epäonnistunut ja yhteyttä ei luoda.

Protokolla salausparametrien muuttamiseen

On olemassa salausparametrien muutosprotokolla, joka ilmoittaa siirtymisestä salaustilaan. Protokolla sisältää yhden viestin, joka on salattu ja pakattu tällä hetkellä muodostetulla yhteydellä. Viesti koostuu vain yhdestä bitistä, jonka arvo on 1.

struct { enum { change_cipher_spec ( 1 ), ( 255 ) } tyyppi ; } ChangeCipherSpec ;

Asiakas ja palvelin lähettävät salauksen vaihtosanoman ilmoittaakseen vastaanottavalle osapuolelle, että seuraavat kirjoitukset suojataan äskettäin neuvotellun CipherSpecin ja avaimien mukaisesti. Tämän viestin hyväksyminen saa vastaanottajan käskemään kirjoituskerrosta kopioimaan odottavan lukutilan välittömästi nykyiseen lukutilaan. Välittömästi tämän viestin lähettämisen jälkeen lähettäjän on opastettava kirjoituskerrosta vaihtamaan takaisinkirjoitustila nykyiseen kirjoitustilaan. Salauksen vaihtosanoma lähetetään kättelyn aikana, sen jälkeen, kun suojausparametrit on siirretty, mutta ennen "valmis" -viestin lähettämistä.

Hälytysprotokolla

Yksi SSL-kirjoitusprotokollan tukemista vahvistustyypeistä on hälytysprotokolla. Hälytysviesti välittää viestissä kohtaamat vaikeudet ja hälytyksen kuvauksen. Kriittisen tason hälytysviesti katkaisee yhteyden välittömästi. Tässä tapauksessa muut istuntoa vastaavat yhteydet voivat jatkua, mutta istunnon tunniste on mitätöitävä. Kuten muutkin viestit, hälytysviesti salataan ja pakataan heti, kun nykyinen yhteystila näytetään.

Sovellusprotokolla

Datasovellussanoma toimii tietuetasolla. Se on pirstoutunut, pakattu ja salattu yhteyden nykyisen tilan perusteella. Viestit katsotaan läpinäkyviksi tietuekerrokselle.

Turvallisuus

SSL 2.0

SSL-protokollaa vastaan ​​voidaan tehdä useita hyökkäyksiä. SSL on kuitenkin vastustuskykyinen näille hyökkäyksille edellyttäen, että käyttäjä käyttää tietojen käsittelyyn vain luotettuja palvelimia. SSL 2.0 on haavoittuvainen joissakin tilanteissa [23] :

  1. Identtisiä salausavaimia käytetään viestien todentamiseen ja salaamiseen;
  2. SSL 2.0:ssa on heikko MAC-rakenne, joka käyttää MD5-hajautustoimintoa etuliitteellä, mikä tekee siitä alttiin hyökkäyksille.
  3. SSL 2.0:ssa ei ole suojausta kättelyprotokollalle, mikä tarkoittaa, että man-in-the-middle-hyökkäykset voivat jäädä huomaamatta;
  4. SSL 2.0 käyttää suljettua TCP-yhteyttä ilmoittamaan tietojen päättymisestä. Tämä tarkoittaa, että seuraava hyökkäys on mahdollinen: hyökkääjä yksinkertaisesti väärentää TCP FIN:n jättäen vastaanottajalle viestiä tiedonsiirron päättymisestä (tämä vika korjattiin SSL 3.0:ssa);
  5. SSL 2.0 olettaa yhden palvelupisteen ja kiinteän toimialueen, mikä on ristiriidassa verkkopalvelimien tavallisen jaetun isännöinnin ominaisuuden kanssa.

SSL 2.0 on oletuksena poistettu käytöstä selaimissa, jotka alkavat Internet Explorer 7 :stä [24] , Mozilla Firefox 2 :sta [25] , Opera 9.5 :stä [26] ja Safarista .

SSL 3.0

14. lokakuuta 2014 tunnistettiin haavoittuvuus CVE-2014-3566, nimeltään POODLE (Padding Oracle On Downgraded Legacy Encryption). Tämän haavoittuvuuden ansiosta hyökkääjä voi suorittaa Man-in-the-Middle -hyökkäyksen SSL 3.0:lla salattua yhteyttä vastaan. POODLE-haavoittuvuus on protokollan haavoittuvuus, ei missään sen toteutuksissa, joten se vaikuttaa kaikkiin SSL v3:lla salattuihin yhteyksiin.

SSL 3.0:ssa on muitakin heikkouksia. Esimerkiksi puolet asetettavasta pääavaimesta riippuu täysin MD5:n hash-toiminnosta, joka ei ole törmäyksenkestävä ja siksi sitä ei pidetä turvallisena [27] .

Mahdollisten hyökkäysten tyypit

Sanakirjahyökkäys

Tämäntyyppinen hyökkäys suoritetaan, kun hyökkääjällä on käsitys siitä, millaisia ​​viestejä lähetetään.
Kryptanalyytikko voi muodostaa tietokannan, jossa avaimet ovat salattuja selväkielisiä merkkijonoja. Luodun tietokannan perusteella voit määrittää tiettyä tietolohkoa vastaavan istuntoavaimen.

Yleensä tällaiset hyökkäykset ovat mahdollisia SSL:lle. Mutta SSL yrittää torjua näitä hyökkäyksiä käyttämällä suuria istuntoavaimia - asiakas luo vientirajoitusten sallimaa pidemmän avaimen, josta osa lähetetään palvelimelle selkeänä tekstinä ja loput yhdistetään salaisen osan kanssa. riittävän pitkä avain (esimerkiksi 128 bittiä, kuten RC4 vaatii). Tapa estää selkokieliset hyökkäykset on tehdä tarvittavasta tekstimäärästä kohtuuttoman suuri. Jokainen istuntoavaimen pituuteen lisätty bitti kaksinkertaistaa sanakirjan koon. 128-bittisen istuntoavaimen käyttö tekee sanakirjan koon paljon nykyaikaisten teknisten mahdollisuuksien yläpuolelle (ratkaisu vaatisi useita atomeja, joita ei löydy koko universumista). Toinen tapa, jolla SSL voi torjua tätä hyökkäystä, on käyttää suurinta mahdollista avainten pituutta (ei-vientitapauksessa). Tästä seuraa, että yksinkertaisin ja halvin hyökkäystapa on avaimen etuhyökkäys, mutta 128-bittiselle avaimelle sen paljastamiskustannuksia voidaan pitää äärettömänä.

Reflection Attack

Hyökkääjä tallentaa viestintäistunnon palvelimen ja asiakkaan välillä. Myöhemmin se yrittää muodostaa yhteyden palvelimeen toistamalla asiakkaan tallentamia viestejä. Mutta SSL torjuu tämän hyökkäyksen erityisellä ainutlaatuisella yhteystunnisteella (IC). Tietenkin teoriassa kolmas osapuoli ei voi ennustaa IS:ää, koska se perustuu satunnaisten tapahtumien joukkoon. Hyökkääjä, jolla on suuria resursseja, voi kuitenkin kirjata suuren määrän istuntoja ja yrittää poimia "oikean" istunnon palvelimen Server_Hello- viestissä lähettämän ilmoituksen perusteella . Mutta SSL -salaukset ovat vähintään 128 bitin pituisia, mikä tarkoittaa, että hyökkääjän on kirjoitettava 264 poikkeamaa saadakseen 50 %:n mahdollisuuden arvata. Mutta 2 64 on tarpeeksi suuri määrä tehdäkseen näistä hyökkäyksistä merkityksettömiä.

Handshake protokollahyökkäys

Hyökkääjä voi yrittää vaikuttaa kättelyn vaihtoon siten, että osapuolet valitsevat erilaisia ​​salausalgoritmeja, eivät niitä, joita he tavallisesti valitsevat. Koska monet toteutukset tukevat vietyä salausta ja jotkut jopa 0-salausta tai MAC:ia, nämä hyökkäykset ovat erittäin kiinnostavia.

Tällaista hyökkäystä varten hyökkääjän on nopeasti huijattava yksi tai useampi kättelyviesti. Jos näin tapahtuu, asiakas ja palvelin laskevat eri hash-arvot kättelyviestille. Tämän seurauksena osapuolet eivät hyväksy " valmiita " viestejä toisiltaan . Tietämättäsalaisuutta hyökkääjä ei pysty korjaamaanvalmiista viestiä , joten hyökkäys voidaan havaita.

SSL-yhteyksien hakkerointi palvelinkeskuksen sisällä

Tunnetuimman SSL-protokollalla suojatun tiedon joukkohakkeroinnin suorittivat FBI-agentit Carnivore- ja NarusInsight- järjestelmillä , mikä johti ihmisoikeusjärjestön Electronic Frontier Foundationin puolesta nostamaan oikeusjutun AT&T:tä vastaan, joka asensi nämä kompleksit salauksen murtamiseen. suojattua tietoa.

Huolimatta tästä tapauksesta Yhdysvalloissa kohonneesta suuresta julkisuudesta ja edustajainhuoneen perustuslaillisen komitean tasolla tehdystä tutkimuksesta, FBI :n agentit eivät ole hakkeroineet SSL-protokollaa . Carnivore ja NarusInsight asennettiin itse palvelinkeskukseen , jossa oli palvelimia, jotka tekivät SSL-yhteyksiä etäasiakkaiden kanssa. NarusInsight palautti salatut tiedot kokonaan kuuntelemalla ei SSL-yhteyttä, vaan sisäistä liikennettä palvelinkeskuksen sisällä olevien sovelluspalvelimien välillä sen jälkeen, kun palvelin itse pursi SSL:n kautta vastaanotetun tiedon salauksen, joka vastaanotti ne ulkoisilta käyttäjiltä.

Tämä tapaus osoitti kuitenkin, että SSL ei voi olla luotettava tapa suojata palvelintietoja Internetissä, koska erikoispalvelut voivat asentaa palvelinkeskukseen kuuntelujärjestelmiä, kuten NarusInsight tai SORM-2 [28] . Kaiken tyyppinen salaus, joka tarkoittaa, että salausavaimet ovat vastaanottajapalvelimella datakeskuksessa, hakkeroidaan automaattisesti tiedustelupalvelun haistajien toimesta ruiskuttamalla ne vastaanottajaan itselleen. Lisäksi tiedot rekonstruoidaan täysin tällä hetkellä säänneltyjen menettelyjen ja säädösten, kuten " Patriot Actin " mukaisesti. Lisäksi nämä säädökset kieltävät tietokeskusten omistajien syytteeseen asti tiedustelupalvelun haukijoiden poistamisen vastaanottavien palvelimien sisäisestä osasta. Kun nämä järjestelmät ovat käytössä, SSL voi suojata yhteyttä vain kahden käyttäjän välillä Internetissä, ei SSL-yhteyttä ulkoiseen Web-sivustoon.

BEAST attack

23. syyskuuta 2011 thaimaalaiset tutkijat Duong ja Giuliano Rizzo osoittivat Java-sovelman avulla "konseptin todisteen" nimeltä Beast ("Browser Exploit Against SSL/TLS"), joka osoittaa TLS 1.0:n haavoittuvuuden [29] [30] . Aikaisemmin tämä haavoittuvuus, jonka Phillip Rogaway [31] löysi alun perin vuonna 2002, oli käytännössä mahdotonta kenenkään osoittaa. TLS 1.1 -haavoittuvuus raportoitiin vuonna 2006.
Hyökkäys perustuu useisiin oletuksiin, mutta kuten kävi ilmi, ne on täysin mahdollista toteuttaa. Ensinnäkin kryptanalyytikon on kyettävä sieppaamaan selaimen lähettämää liikennettä . Toiseksi on tarpeen jollakin tavalla pakottaa käyttäjä siirtämään tietoja saman suojatun viestintäkanavan kautta . Luodaan suojattu yhteys Bobin ( B ) ja Alicen ( A ) tietokoneiden välille. Oletetaan, että meille tulleen viestin i. lohko sisältää salaisia ​​tietoja (esimerkiksi salasanan).

C i = E ( avain , M i x tai C i-1 ), jossa C i on salattu lohko, M i  on salainen teksti

Oletetaan, että salasana A  on P . Voimme tarkistaa, onko oletuksemme oikea:

Pystyimme siis sieppaamaan alustusvektorin, jota käytetään salaamaan seuraavan viestin ensimmäinen lohko, mutta tämä on myös edellisen viestin viimeinen lohko (salatussa muodossa) - IV . Sieppasimme myös C i-1:n . Tätä dataa käyttämällä muodostamme viestin siten, että ensimmäisestä lohkosta tulee seuraava:

M 1 = C i-1 xor IV xor P

Jos kryptanalyytikko voi lähettää viestin saman suojatun kanavan kautta, uuden viestin ensimmäinen lohko näyttää tältä:

C 1 = E ( näppäin , M 1 x tai IV ) = E ( avain , ( C i-1 x tai IV x tai P ) x tai P ) x tai IV ) = E ( avain , ( C i-1 x tai P )) = C i

Osoittautuu, että jos P = M , niin uuden viestin C1 ensimmäinen salattu lohko on yhtä suuri kuin aiemmin siepattu Ci .

Käytännössä syntyy ongelma: lohko M  on 16 tavua pitkä, vaikka tiedämmekin kaikki paitsi kaksi tavua, tarvitsemme 2 15 yritystä loput arvataksemme. Entä jos emme tiedä mitään?
Tästä johtuu johtopäätös, että tämä käytäntö voi toimia, jos kryptanalyytikolla on rajoitettu määrä oletuksia M :n arvosta tai pikemminkin suurimmasta osasta tämän lohkon sisällöstä. Seuraava oletus on, että kryptanalyytikko voi hallita tietojen sijaintia lohkossa esimerkiksi tietäen, että salasana on n merkkiä pitkä. Tämän tietäen kryptanalyytikko järjestää salasanan siten, että vain 1 merkki pääsee ensimmäiseen lohkoon ja loput (n-1) seuraavaan - eli ensimmäiset 15 tavua sisältävät tunnettua dataa. Ja yhden merkin arvaamiseksi hyökkääjä tarvitsee pahimmillaan 256 yritystä.

Haavoittuvuus tunnettiin paljon aikaisemmin, mutta apuohjelman kehittäjät ovat ensimmäisiä, jotka onnistuivat toteuttamaan kaikki tämän hyökkäyksen ehdot. Nimittäin:

  1. Kryptanalyytikko pystyy kuuntelemaan hyökkäyksen kohteena olevan tietokoneen selaimen käynnistämiä verkkoyhteyksiä
  2. Kryptusanalyytikolla on mahdollisuus pistää agentti uhrin selaimeen
  3. Agentilla on mahdollisuus lähettää mielivaltaisia ​​HTTPS-pyyntöjä

Tässä on luettelo erilaisista teknologioista ja selainlaajennuksista, jotka voivat suorittaa agentin lisäämisen uhrin selaimeen: Javascript XMLHttpRequest API, HTML5 WebSocket API, Flash URLRequest API, Java Applet URLConnection API ja Silverlight WebClient API.

RC4-hyökkäys

Vuonna 2013 Singaporessa pidettiin konferenssi, jossa professori Dan Bernstein esitteli uuden tekniikan SSL/TLS-protokollien murtamiseen käyttämällä RC4-salausta, jota ehdotettiin vuonna 2011 suojaksi BEASTia vastaan. RC4:stä löydetty haavoittuvuus liittyy viestin satunnaisuuden puutteeseen bittivirrassa, joka sekoitti viestin. Kun sama viesti oli ajanut sen läpi monta kertaa, paljastui riittävä määrä toistuvia kuvioita alkuperäisen tekstin palauttamiseksi. Hyökkäystä varten salauksen läpi on ajettava valtava määrä tietoa. Esitetyssä toteutuksessa hakkerointi kesti jopa 32 tuntia, mutta prosessin optimointimahdollisuutta ei suljettu pois. Mutta tätä hyökkäystä on vaikea toteuttaa käytännössä. Tekijät väittävät, että 80 tavun palauttamiseen 256:sta tarvitaan 256 salatekstiä .

Salausten paljastaminen

Kuten tiedät, SSL riippuu useista salausparametreista. RSA:n julkisen avaimen salaus vaaditaan avainten siirtoon ja palvelimen/asiakkaan todentamiseen. Salauksena käytetään kuitenkin erilaisia ​​salausalgoritmeja. Siten, jos onnistunut hyökkäys näitä algoritmeja vastaan ​​suoritetaan, SSL:ää ei voida enää pitää turvallisena. Hyökkäys tiettyjä viestintäistuntoja vastaan ​​tehdään tallentamalla istunto, ja sitten ajan mittaan valitaan istuntoavain tai RSA-avain.

Man-in-the-middle -hyökkäys

Tunnetaan myös nimellä MitM (Man-in-the-Middle) -hyökkäys. Siihen osallistuu kolme osapuolta: palvelin, asiakas ja niiden välissä oleva hyökkääjä. Tässä tilanteessa hyökkääjä voi siepata kaikki viestit, jotka seuraavat molempiin suuntiin ja korvata ne. Hyökkääjä näyttää olevan palvelin asiakkaalle ja asiakas palvelimelle. Diffie-Hellman-avaintenvaihdon tapauksessa tämä hyökkäys on tehokas, koska vastaanotetun tiedon eheyttä ja sen lähdettä ei voida varmistaa. Tällainen hyökkäys ei kuitenkaan ole mahdollista SSL-protokollaa [32] käyttämällä, koska varmentajan [33] todennettuja varmenteita käytetään lähteen (yleensä palvelimen) todentamiseen .

Hyökkäys onnistuu, jos:

  • Palvelimella ei ole allekirjoitettua varmennetta.
  • Asiakas ei vahvista palvelimen varmennetta.
  • Käyttäjä jättää huomioimatta viestin, jonka mukaan varmentaja ei ole allekirjoittanut varmennetta, tai viestin, että varmenne ei vastaa välimuistissa olevaa varmennetta [34] .

Tämäntyyppiset hyökkäykset löytyvät suurista organisaatioista, jotka käyttävät Microsoft Forefront TMG -palomuuria tai Blue Coat Proxy SG -välityspalvelinta . Tässä tapauksessa "tunkeilija" sijaitsee organisaation verkon reunalla ja korvaa alkuperäisen varmenteen omallaan. Tämä hyökkäys tulee mahdolliseksi, koska välityspalvelin itse voidaan määrittää luotetuksi varmentajaksi (joko pääkäyttäjäksi tai yrityksen juuren alijäseneksi). Tyypillisesti tällainen toteutusmenettely on käyttäjälle läpinäkyvä johtuen yrityskäyttäjien Active Directory -ympäristössä tekemästä työstä. Tätä työkalua voidaan käyttää sekä siirrettävien tietojen ohjaamiseen että suojatun HTTPS-yhteyden kautta lähetettyjen henkilötietojen varastamiseen.

Kiistanalaisin kysymys on käyttäjän tietoisuus tietojen sieppaamisen mahdollisuudesta, koska juurivarmenteen korvaamisen yhteydessä turvaviestejä ei näytetä ja käyttäjä odottaa siirrettyjen tietojen luottamuksellisuutta.

Lisäksi käytettäessä Forefront TMG:tä SSL-välityspalvelimena, Internet-puolella on mahdollisuus toiseen MitM-hyökkäykseen, koska alkuperäinen varmenne ei siirry käyttäjälle ja Forefront TMG voidaan määrittää hyväksymään ja sitten korvaamaan itsensä. -allekirjoitetut tai peruutetut sertifikaatit. Suojatakseen tällaista hyökkäystä vastaan ​​on välttämätöntä kieltää kokonaan työskentely sellaisten verkkopalvelimien kanssa, joiden sertifikaatit sisältävät virheitä, mikä johtaa varmasti kyvyttömyyteen työskennellä HTTPS-protokollan kanssa monien sivustojen kanssa.

Blue Coat Proxy SG on suojattu toiselta MitM-hyökkäykseltä: järjestelmän avulla voit määrittää käytännön niin, että epäluotettavan verkkopalvelimen varmenteen tapauksessa järjestelmä antaa myös varmenteen, jonka allekirjoittaa ei luotettu ketju, vaan tilapäinen itse. - allekirjoittanut sellaisen.

THC-SSL-DOS

24. lokakuuta 2011 The Hacker's Choice (THC) julkaisi THC-SSL-DOS-apuohjelman, jota voidaan käyttää DoS-hyökkäyksiin SSL-palvelimia vastaan. Tämä apuohjelma hyödyntää SSL Renegotiation -ominaisuuden haavoittuvuutta, joka alun perin oli suunniteltu tekemään SSL:stä turvallisempi. Uudelleenvalidoinnin avulla palvelin voi luoda uuden yksityisen avaimen olemassa olevan SSL-yhteyden kautta. Tämä ominaisuus on oletuksena käytössä useimmilla palvelimilla. Suojatun yhteyden muodostaminen sekä SSL-uudelleenvalidoinnin suorittaminen vaatii useita kertoja enemmän resursseja palvelinpuolella kuin asiakaspuolella, eli jos asiakas lähettää useita SSL-uudelleenvalidointipyyntöjä, tämä kuluttaa palvelimen järjestelmäresursseja.

Erään THC:n osallistujan mukaan onnistunut hyökkäys vaatii kannettavan tietokoneen, johon on asennettu apuohjelma, ja Internet-yhteyden. Ohjelma julkaistiin julkisesti, koska sen vastine ilmestyi verkkoon muutama kuukausi sitten. Lisäksi kehittäjien mukaan hyökkäys voidaan toteuttaa, vaikka palvelin ei tue uudelleenvalidointitoimintoa, vaikka tämä edellyttää hyökkäysmenetelmän muokkaamista. Tässä tapauksessa useita TCP-yhteyksiä muodostetaan uutta SSL-kättelyä varten, mutta tehokkaaseen hyökkäykseen tarvitaan lisää botteja.
Puolustukseksi jotkut ohjelmistokehittäjät suosittelevat erityisten sääntöjen määrittämistä yhteyden katkaisemiseksi asiakkaan kanssa, joka suorittaa uudelleentarkistustoiminnon useammin kuin tietyn määrän kertoja sekunnissa.

SSLstrip

Vuonna 2009 Black Hat -konferenssissa Washington DC:ssä riippumaton hakkeri Moxie Marlinspike esitteli uutta työkalua SSLstrip, joka voi poimia tärkeitä tietoja huijaamalla käyttäjät uskomaan, että he ovat suojatulla sivulla, vaikka he eivät ole. Tämä voidaan saavuttaa muuntamalla normaalisti SSL-suojatut sivut niiden suojaamattomiksi sivuiksi, mikä pettää sekä palvelinta että asiakasta. Apuohjelma toimii, koska monilla SSL-suojausta käyttävillä sivustoilla on epävarma kotisivu. Ne salaavat vain ne osat, joissa tärkeitä tietoja välitetään. Ja kun käyttäjä napsauttaa valtuutussivua, apuohjelma korvaa sivuston vastauksen muuttamalla https-osoitteen http:ksi. SSLstrip käyttää seuraavia tekniikoita: Ensinnäkin paikalliseen verkkoon otetaan käyttöön välityspalvelin, jolla on voimassa oleva varmenne - tästä lähtien käyttäjä näkee edelleen https-osoitteen osoitepalkissa, toiseksi käytetään tekniikkaa pitkien URL -osoitteiden luomiseen, jotka sisältävät väärennettyjä '/ ' osoitepalkissa - tämä on välttämätöntä, jotta selaimet eivät muuttaisi merkkejä. Todistaakseen järjestelmän toimivuuden Moxxi suoritti SSL-stripin Tor-verkkoa palvelevalla palvelimella ja kalasti 24 tunnin aikana 254 salasanaa Yahoo- , Gmail- , Ticketmasterin, PayPalin ja LinkedInin käyttäjiltä .

Virheiden käsittely SSL-protokollassa

SSL-protokollassa virheiden käsittely on hyvin yksinkertaista. Kun virhe havaitaan, se, joka löysi sen, lähettää siitä viestin kumppanilleen. Vakavat virheet vaativat palvelimen ja asiakkaan katkaisemaan yhteyden [35] . SSL-protokolla määrittää seuraavat virheet:

  1. Unsupported_Certificate_Type_Error : Tämä virhe ilmenee, kun asiakas/palvelin vastaanottaa varmennetyypin, jota ei tueta. Virhe on korjattavissa (vain asiakkaan todennus).
  2. No_Cipher_Error : Virhe ilmenee, kun palvelin ei löydä avaimen kokoa tai salausta, jota myös asiakas tukee. Virhe on korjaamaton.
  3. Bad_Certificate_Error : Tämä virhe ilmenee, kun vastaanottava osapuoli pitää varmennetta huonona. Tämä tarkoittaa, että joko varmenteen allekirjoitus on virheellinen tai sen arvo on väärä. Virhe on korjattavissa (vain asiakkaan todennus).
  4. No_Certificate_Error : Jos Request_Certificate-sanoma lähetetään, tämä virhe voidaan lähettää, koska asiakkaalla ei ole varmennetta. Korjaamme virheen.

SSL:ssä käytetyt algoritmit

Katso myös

Muistiinpanot

  1. ↑ US-CERT. TA14-290A: SSL 3.0 -protokollahaavoittuvuus ja POODLE-hyökkäys  (englanniksi) (lokakuu 2014). Arkistoitu alkuperäisestä 6. marraskuuta 2014.
  2. ↑ SSL  -PROTOKOLLA . Netscape Corporation. Haettu 20. toukokuuta 2013. Arkistoitu alkuperäisestä 14. kesäkuuta 1997.
  3. ↑ Dierks, T. ja E. Rescorla. Transport Layer Security (TLS) -protokollan versio 1.1 , RFC 4346  . Käyttöpäivä: 9. toukokuuta 2013. Arkistoitu alkuperäisestä 9. helmikuuta 2012.
  4. ↑ Yleiskatsaus SSL/TLS-salaukseen Microsoft TechNet . Päivitetty 31. heinäkuuta 2003.
  5. ↑ SSL/TLS yksityiskohtaisesti Microsoft TechNet . Päivitetty 31. heinäkuuta 2003.
  6. ↑ SSL Pulse (downlink) . Haettu 27. huhtikuuta 2017. Arkistoitu alkuperäisestä 15. toukokuuta 2017. 
  7. ↑ 1 2 SSL/TLS yleiskatsaus  (englanniksi)  (downlink) (6. elokuuta 2008). Haettu 9. toukokuuta 2013. Arkistoitu alkuperäisestä 3. heinäkuuta 2013.
  8. ↑ Ongelma 90392: Ei TLS 1.2 (SHA-2) -tukea  ( 27. kesäkuuta 2013). Haettu 15. heinäkuuta 2015. Arkistoitu alkuperäisestä 3. elokuuta 2013.
  9. ↑ Suojaus Firefox 2:ssa  (englanniksi)  (downlink) (6. elokuuta 2008). Haettu 9. toukokuuta 2013. Arkistoitu alkuperäisestä 23. heinäkuuta 2012.
  10. ↑ Virhe 733647 – Ota TLS 1.1 (RFC 4346) käyttöön Geckossa (Firefox, Thunderbird) oletuksena  ( 6. maaliskuuta 2012). Haettu 9. toukokuuta 2013. Arkistoitu alkuperäisestä 30. toukokuuta 2013.
  11. ↑ Virhe 480514 – Ota käyttöön tuki TLS 1.2:lle (RFC 5246)  ( 17. maaliskuuta 2010). Haettu 9. toukokuuta 2013. Arkistoitu alkuperäisestä 31. toukokuuta 2013.
  12. ↑ "Changelog for Opera 5.x for Windows" Arkistoitu 19. lokakuuta 2014 Wayback Machinessa osoitteessa Opera.com
  13. ↑ "Changelog for Opera [8] Beta 2 for Windows" Arkistoitu 23. marraskuuta 2005 Wayback Machinessa osoitteessa Opera.com
  14. ↑ Microsoft. Secure Channel  (englanniksi) (5. syyskuuta 2012). Haettu 9. toukokuuta 2013. Arkistoitu alkuperäisestä 17. huhtikuuta 2013.
  15. ↑ Microsoft. MS-TLSP Liite A  (englanniksi) (27. helmikuuta 2009). Haettu 9. toukokuuta 2013. Arkistoitu alkuperäisestä 17. huhtikuuta 2013.
  16. ↑ Yngve Nysæter Pettersen. Uutta Opera Presto 2.2:ssa: TLS 1.2 -tuki  ( 25. helmikuuta 2009). Haettu 9. toukokuuta 2013. Arkistoitu alkuperäisestä 17. huhtikuuta 2013.
  17. ↑ "Changelog for Opera 9.0 for Windows" Arkistoitu 31. elokuuta 2006 Wayback Machinessa osoitteessa Opera.com
  18. ↑ Adrian, Dimcev. Yleiset selaimet/kirjastot/palvelimet ja niihin liittyvät salaussarjat  toteutettu . TLS Cipher Suites -projekti . Haettu 9. toukokuuta 2013. Arkistoitu alkuperäisestä 17. huhtikuuta 2013.
  19. ↑ Apple. Ominaisuudet  (englanniksi) (10. kesäkuuta 2009). Haettu 9. toukokuuta 2013. Arkistoitu alkuperäisestä 17. huhtikuuta 2013.
  20. ↑ Apple. Tekninen huomautus TN2287 – iOS 5:n ja TLS 1.2:n yhteentoimivuusongelmat  ( 14. lokakuuta 2011). Haettu 9. toukokuuta 2013. Arkistoitu alkuperäisestä 8. syyskuuta 2010.
  21. ↑ Liebowitz, Matt. Apple julkaisee valtavia ohjelmistosuojauskorjauksia  . NBCNews.com (13. lokakuuta 2011). Haettu 9. toukokuuta 2013. Arkistoitu alkuperäisestä 17. huhtikuuta 2013.
  22. ↑ MWR-tietoturva. Adventures with iOS UIWebviews  ( 16. huhtikuuta 2012). Haettu 9. toukokuuta 2013. Arkistoitu alkuperäisestä 17. huhtikuuta 2013. , osio "HTTPS (SSL/TLS)"
  23. ↑ Joris Claessens, Valentin Dem, Danny De Cock, Bart Preneel, Joos Vandewalle. Nykypäivän sähköisten verkkopankkijärjestelmien turvallisuudesta  (eng.) 253–265 (2002). Haettu 11. toukokuuta 2013. Arkistoitu alkuperäisestä 17. lokakuuta 2015.
  24. ↑ Lawrence Eric. IEBlog : Tulevia HTTPS - parannuksia Internet Explorer 7 Beta 2  : ssa . MSDN- blogit (25. marraskuuta 2007). Haettu 11. toukokuuta 2013. Arkistoitu alkuperäisestä 17. huhtikuuta 2013.
  25. ↑ Mozilla Corporation . Bugzilla@Mozilla - Virhe 236933 - Poista SSL2 ja muut heikot salaukset käytöstä  . Haettu 11. toukokuuta 2013. Arkistoitu alkuperäisestä 14. helmikuuta 2017.
  26. ↑ "Opera 9.5 for Windows Changelog" Arkistoitu 26. kesäkuuta 2009 Wayback Machinessa osoitteessa Opera.com : "SSL v2 pois käytöstä ja heikot salaukset."
  27. ↑ National Institute of Standards and Technology. FIPS PUB 140-2:n ja kryptografisen moduulin validointiohjelman käyttöönotto-ohjeet  ( joulukuu 2010). Haettu 11. toukokuuta 2013. Arkistoitu alkuperäisestä 17. huhtikuuta 2013.
  28. ↑ Igor Savchuk. Se on SORM, kulta. Osa 1. Nykyaikaisten salaustyökalujen mahdollisuudet  // “BIT. Business&Information Technologies»  : Journal. - M . : LLC "Publishing House" Polozhevets and Partners ", 2014. - Numero. 1 , nro 34 . — ISSN 2313-8718 . Arkistoitu 28. lokakuuta 2020.
  29. ↑ Dan Goodin. Hakkerit rikkovat miljoonien sivustojen käyttämän SSL-salauksen  (englanniksi) (19. syyskuuta 2011). Haettu 11. toukokuuta 2013. Arkistoitu alkuperäisestä 17. huhtikuuta 2013.
  30. ↑ Y Combinator kommentoi asiaa  ( 20. syyskuuta 2011). Haettu 11. toukokuuta 2013. Arkistoitu alkuperäisestä 17. huhtikuuta 2013.
  31. ↑ CBC-salauspakettien suojaus SSL/TLS:ssä: Ongelmia ja vastatoimia  ( 20. toukokuuta 2004). Haettu 11. toukokuuta 2013. Arkistoitu alkuperäisestä 30. kesäkuuta 2012.
  32. ↑ Eric Rescorla. TLS-uudelleenneuvotteluhyökkäyksen  ymmärtäminen . Koulutettu arvaus (5. marraskuuta 2009). Haettu 11. toukokuuta 2013. Arkistoitu alkuperäisestä 28. huhtikuuta 2013.
  33. ↑ Simon Josephson. GnuTLS 2.10.0 julkaistu  . GnuTLS:n julkaisutiedot (25.6.2010). Haettu 11. toukokuuta 2013. Arkistoitu alkuperäisestä 28. huhtikuuta 2013.
  34. ↑ Adrian Dimcev. Satunnainen SSL/TLS 101 - SSL/TLS-version palautukset ja  selaimet . Satunnainen SSL/TLS 101 . Haettu 11. toukokuuta 2013. Arkistoitu alkuperäisestä 28. huhtikuuta 2013.
  35. ↑ Kaspar Brand. Nimetyt SSL-virtuaalipalvelimet: kuinka ratkaista ongelma  ( 18. huhtikuuta 2007). Haettu 20. toukokuuta 2013. Arkistoitu alkuperäisestä 3. elokuuta 2012.
  36. ↑ Christopher Allen, Tim Dierks. SSL-protokolla - Käännös - versio 1.0 . Certicom . Semenov Yu. A. Haettu 20. toukokuuta 2013. Arkistoitu alkuperäisestä 11. heinäkuuta 2012.
  37. ↑ David Wagner. SSL 3.0 -protokollan  analyysi . Kalifornian yliopisto. Haettu 24. toukokuuta 2013. Arkistoitu alkuperäisestä 31. lokakuuta 2014.

Kirjallisuus

Kirjat
  • Pouyan Sepehrdad. Uusien harhojen löytäminen ja hyödyntäminen RC4:ssä. – 1. - Springer Berlin Heidelberg, 2011. - T. 1. - S. 24. - 91 s. - ISBN 978-3-642-19573-0 .
  • Joris Claessens. Tietokoneturvallisuus ja teollinen kryptografia. - 3-t. - Leuven-Heverlee, Belgia, 2002. - T. 1. - S. 253-265. — 287 s. — ISBN 0167-4048.
  • John Viega. Verkkosuojaus OpenSSL:llä. – 1. - O'Reilly Media, USA, 15. kesäkuuta 2002. - Vol. 1. - 386 sivua s. - ISBN 978-0596002701 .
  • Eric Rescorla. SSL ja TLS: Turvallisten järjestelmien suunnittelu ja rakentaminen. – 1. - Addison-Wesley Professional, 27. lokakuuta 2000. - Vol. 1. - 528 sivua s. — ISBN 978-0201615982 .
  • Stephen Thomas. SSL & TLS Essentials: Internetin suojaaminen. – 1. - Wiley, 11. helmikuuta 2000. - T. 1. - 224 sivua s. — ISBN 978-0471383543 .
Artikkelit
  • SSL/TLS-protokollien kuvaus // 3. - CRYPTO-PRO LLC., 2002. - S. 49.
  • Semenov Yu.A. SSL-protokolla. Turvallinen liittimen taso. - 2000. - Nro 1 .
  • E. Rescorla. Transport Layer Security (TLS) -protokollan versio 1.2 // 1-st. - RTFM, Inc., elokuu 2008. - Nro 1 . - s. 101.
  • P. Karlton. SSL (Secure Sockets Layer) -protokollan versio 3.0 // 1-st. - RTFM, Inc., elokuu 2011. - Nro 1 . - s. 67.
  • T. Dierks. Secure Sockets Layer (SSL) // 1-st. - RTFM, Inc., elokuu 2008. - Nro 1 . - s. 207.

Linkit