Žodis angliškai

SSL/TLS protocols

Santrumpa

SSL/TLS

Žodis Lietuviškai

SSL/TLS protokolai

Apibrėžimas

SSL (Secure Socket Layer) ir TLS (Transport Layer Security) - tai kriptografiniai protokolai, skirti saugiai keistis internetu perduodamais duomenims. Veikia taikomąjame TCP/IP modelio lygmenyje.

Įvadas

Vis daugiau darbo sričių persikelia į virtualią erdvę. Dažnai pasitaiko duomenų, kuriais reikia apsikeisti internete, tačiau jie turi išlikti slapti nuo pašalinių. Šia problema susirūpinta jau seniai. Perduodamus slaptus duomenis imta šifruoti, pradėti spręsti apsikeitimo raktais klausimai. Nors ir ankstyvi metodai iš pirmo žvilgsnio gali pasirodyti saugūs, tačiau laikui einant vis randama būdų, kaip juos nulaužti. Galiausia atsirado TLS protokolas, kuris tobulinamas iki šių laikų ir taikomas saugiai keistis informacija internete. Jis naudojamas dažnai su HTTP protokolu, el. paštu, VoIP ir kt. Saugiųjų susijungimų sluoksnio (Secure Socket Layer – SSL) ir iš jo išsivystęs Transporto lygmens saugumo (Transport Layer Security – TLS) yra kriptografiniai protokolai, skirti saugiai keistis duomenimis internete. Jie autentikacijai naudoja X.509 sertifikatus, veikia virš TCP (nors yra ir realizacijų kitiems protokolams, veikiantiems datagramų pagrindu, tokiems kaip UDP). Šiuo atveju aukštesnių lygmenų protokolai (kaip HTTP) gali būti palikti be pakeitimų ir vistiek palaikyti saugų susijungimą, pavyzdžiui, virš SSL sluoksnio HTTPS protokolas yra visiškai identiškas HTTP protokolui. Kai SSL/TLS naudojamas teisingai, viskas, ką įsilaužėlis gali pagauti kabelyje – IP ir prievado numeriai, per kuriuos klientas bendrauja su serveriu, apytiksliai, kiek duomenų yra perduodama, koks šifravimo ir koks suspaudimo algoritmas yra naudojamas. Jis taip pat gali nutraukti susijungimą, tačiau ir klientas, ir serveris supras, kad susijungimą nutraukė trečioji šalis. Įprastai naudojant, įsilaužėlis taip pat galės išsiaiškinti prie kokio (host name) vartotojas yra prisijungęs (tačiau tik vardą, o ne visą URL): nors pats HTTPS neatskleidžia vardo (hostname), tačiau naršyklė įprastai turės užklausti DNS, kad pagal vardą sužinotų IP, į kurį reikės kreiptis. DNS užklausos nėra šifruojamos.

Šifravimo ir apsikeitimo raktais idėja

SSL/TLS autentikacijai naudoja X.509 sertifikatus ir todėl asimetrinę kriptografiją (taip nurodyta X.509 specifikacijose). Autentikacijos metu su kolega, apsikeičiama simetriniu raktu. Kuom skiriasi asimetrinė nuo simetrinės kriptografijos? Asimetrinė kriptografija dar yra vadinama viešojo rakto (angl. public key) kriptografija, naudoja du atskirus raktus, iš kurių vienas yra privatus (slaptas, angl. private), o kitas – viešas (public). Nepaisant to, kad šie raktai yra skirtingi, matematiškai jie yra susiję. Viešas raktas yra skirtas, kad užšifruoti atvirą tekstą (plaintext) arba patikrinti skaitmeninį parašą, o privatus raktas naudojamas, kad dešifruoti šifruotą tekstą (ciphertext) arba siekiant sukurti skaitmeninį parašą. Terminas „asimetrinis“ kilęs iš to, kad skirtingi raktai naudojami atlikti priešingas funkcijas. Simetrinė kriptografija naudoja tą patį raktą atlikti abiems veiksmams arba gali užtekti paprastos transformacijos, kad iš vieno rakto gauti kitą. Nenuspėjamas (įprastai didelis ir atsitiktinis) skaičius yra naudojamas, kad pradėti generuoti tinkamą raktų porą, kuri galės būti naudojama su asimetrinio rakto algoritmu (1 pav). Viešojo rakto algoritmai remiasi tokiais matematiniais uždaviniais, kurie, tikimasi, kad neturi jokio efektyvaus sprendimo būdo: skaičių skaidymo į pirminius (angl. integer factorization arba prime factorisation), diskrečiojo logaritmo ir elipsinių kreivių (y^2=x3+ax+b) sąryšiai. Vartotojas nesunkiai gali susigeneruoti savo viešąjį ir privatų rakta ir tuomet juos naudoti šifravimui ir dešifravimui. Algoritmo patikimumas slypi tame, kad, jei yra gerai sugeneruotas privatus raktas, yra neįmanoma (matematiškai neišeina) jo sužinoti iš viešo rakto. Todėl viešas raktas gali būti viešinamas be jokios saugumo rizikos, kuomet privatus raktas privalo būti laikomas slaptai, neatskleidžiamas niekam, kam negalima skaityti šifruotų duomenų ar atlikti skaitmeninius parašus. Viešojo rakto algoritmai, priešingai nei simetrinių raktų algoritmai, nereikalauja saugaus pradinio susijungimo, kad apsikeisti vienu (ar keletu) saugių raktų tarp vartotojų. 2 pav. vaizduojama, kaip du vartotojai (Bobas ir Alisa) slapta bendrauja, naudodami asimetrinį šifravimą. Pradžoje Bobas ir Alisa susigeneravo savo viešuosius ir privačius raktus. Tada apsikeitė viešaisiais raktais, kuriais galima tik šifruoti. Bobas parašo „Labas, Alisa“, tada šį pranešimą šifruoja jos viešuoju raktu. Šifruoto pranešimo pakeliui niekas negalės perskaityti, nes niekas negavo privataus rakto – jis niekad nesiunčiamas. Alisa gautą pranešimą dešifruoja savo privačiu raktu ir gautą pranešimą perskaito... Taigi, reikėtų įsiminti: kai naudojamas asimetrinio rakto šifravimo algoritmas, bet kas gali šifruoti pranešimą naudodamasis viešuoju raktu, tačiau tik privačiojo rakto savininkas(-ė) gali dešifruoti. Su viešu raktu galima tik šifruoti, bet dešifruoti neįmanoma.

1 pav. Viešojo ir privataus rakto generavimas

2 pav. Kaip Alisa bendrauja su Bobu

Skaitmeninis parašas

Skaitmeninis parašas – matematinis būdas skaitmeninio pranešimo ar dokumento autentiškumo patvirtinimui. Skaitmeninis parašas gavėjui suteikia pasitikėjimą, kad dokumentas nėra suklastotas ir kad jo turinys nebuvo pakeistas nepageidaujamų asmenų. Skaitmeniniai parašai dažnai naudojami programinei įrangai platinti (software distribution), financinėms tranzakcijoms ir kt. Prieš išsiunčiant pranešimą yra paskaičiuojamas ho hešas, kuris tuomet šifruojamas privačiu raktu ir taip gaunamas skaitmeninis parašas (šifruotas hešas). Po to bet kas, kas turi viešąjį raktą, gavęs duomenis ir parašą, jį dešifruoti ir gauti hešą. Tada paskaičiuoti gautų duomenų hešą. Šiuos hešus gavėjas palygina (3 pav.). Jei jie lygūs tai, pranešimas nebuvo modifikuotas (liko autentiškas) nuo to laiko, kai jis buvo pasirašytas ir, laikant, kad pasirašiusiojo asmens privatus raktas vis dar yra paslaptyje (vis dar žinomas tik pasirašiusiajam), jį parašė būtent tas kas turėjo ir ne kasnors kitas.

3 pav. Skaitmeninio parašo taikymas ir tikrinimas

Apie X.509 sertifikatus

Kriptografijoje X.509 yra ITU-T (ITU Telecommunication Standardization Sector) sukurtas standartas viešojo rakto infrastruktūrai (PKI – public key infrastructure – aparatinės ir programinės įrangos, žmonių, politikų ir procedūrų rinkinys, reikalingas tam, kad sukurti, tvarkyti, platinti, naudoti, saugoti ir atšaukti skaitmeninius sertifikatus) ir privilegijų tvarkymo infrastruktūrai (PMI – Privilege Management Infrastructure – vartotojų privilegijų/autorizacijų valdymas pagal X.509 rekomendacijas). X.509 kartu su kitais dalykais apibrėžia standartų formatus viešųjų raktų sertifikatams ir kt.

4 pav. Vartotojo aptarnavimas naudojant sertifikatus

Kriptografijoje PKI yra tvarka, kurią nustato sertifikavimo centras (CA – Certification Authority), susiedamas viešuosius raktus su tam tikrais vartotojų identifikatoriais. Vartotojų identifikatoriai turi būti unikalūs kiekviename CA domene. Trečiųjų šalių esantis tikrinimo centras (VA – validation authority) gali šią informaciją pateikti CA vardu. Susiejimas yra atliekamas per registracijos ir išdavimo procedūras, kurios, priklausomai nuo susiejimo apdraudimo lygmens, gali būti atliktos CA programinės įrangos ar prižiūrint vartotojui (human supervision). Susiejimą atlieka registracijos centras (RA – registration authority), kuris užtikrina, kad viešas raktas yra susietas su tam tikru vartotoju. CA ir PKI tikrina sąryšį tarp sertifikato ir jo savininko, bei tam kad generuoti, pasirašyti ir administruoti, tvarkyti sertifikatų galiojimą.

X.509 sistemoje CA išduoda sertifikatą, susiejantį viešąjį raktą su tam tikru skiriamu vardu arba alternatyviuoju vardu, pavyzdžiui, email adresu ar DNS įrašu. Organizacijos patikimi šaktiniai sertifikatai (trusted root sertificates) gali būti išplatinti visiems darbuotojams, kad jie juos galėtų naudoti kompanijos PKI sistemoje. Populiariausios naršyklės, pavyzdžiui Firefox, Internet Explorer, Chrome ir kt., kai yra instaliuojamos, jau su savimi turi šakninių sertifikatų (root certificates) rinkinį, todėl sertifikatai iš stambesnių kompanijų veiks iš karto, nes naršyklių kūrėjai nustatė, kuriais CA trečiosios šalys gali pasitikėti. Šakninis sertifikatas (Root Certificate) – nepasirašytas viešojo rakto sertifikatas arba savo paties pasirašytas (self-signed) sertifikatas, kuris identifikuoja šakninį CA. Šakniniame sertifikate yra dalis PKI infrastrukturos. CA gali išduoti keletą sertifikatų, sudarančių medžio struktūrą. Šakninio sertifikato privatus raktas (žinomas tik išdavėjui), naudojamas visiems kitiems sertifikatams pasirašyti. Šakninis sertifikatas yra pačioje medžio viršūnėje. Visi kiti sertifikatai yra po šakninio sertifikato ir turi jo pasitikėjimą. Žemiau esantys sertifikatai taip pat laikomi patikimais aukštesnių. Dauguma programų laiko, kad šie šakniniai sertifikatai yra patikimi vartotojui. Pavyzdžiui, naršyklės juos naudoja, kad patikrintų serverio tapatybę SSL/TLS saugaus ryšio metu. Žinoma, tai reiškia, kad vartotojas pasitiki jo naudojamos naršyklės kūrėjais, pasitiki šakniniais sertifikatų centrais ir visais tarpiniais CA, kurie gavo sertifikatus iš aukščiau, ištikimybe ir ketinimais visų šalių, kurios yra sertifikatų savininkės. Šie tarpiniai sertifikatai pasitiki šakniniu ir atvirkščiai. Tai įprasta ir tokia yra X.509 sertifikatų grandinės idėja. SSL privalo laikytis X.509. Tai sertifikatų standartas. Kiekvieną sertifikatą pasirašo sertifikavimo institucija (CA – Certification Authority). Idėja ta, kad klientas žino kažkiek CA (tai yra „trust anchors“ arba „root certificates“), kuriom gali pasitikėti. Su šiais raktais klientas gali patikrinti parašą, kurį paskaičiavo jam CA ir turi su savimi su parašu, kuris yra serverio duotame sertifikate. Šis procesas gali vykti rekursyviai: CA gali išduoti sertifikatą kitai CA (t.y. pasirašyti sertifikatų struktūrą, kurioje yra kito CA vardas ir raktas). Sertifikatų grandinė prasideda šakniniu sertifikatu ir baigiasi serverio sertifikatu, tarp kurių yra dar tarpinių CA sertifikatai, kurių kiekvienas yra pasirašytas ankstesnio sertifikato viešuoju raku, kuris yra ankstesniame sertifikate. Tai ir vadinama sertifikatų grandine. Taigi, klientas yra linkęs elgtis taip:

• Gauti sertifikatų grandinę, kuri užsibaigia serverio sertifikatu. „Certificate“ pranešimas iš serverio turėtų savyje turėti būtent tokią sertifikatų grandinę.

• Patikrinti grandinę, t.y. patikrinti visus parašus ir vardus, ir įvairius X.509 bitus. Taip pat klientas turi patikrinti ar nėvienas iš grandinėje esančių sertifikatų nėra atšauktas, o tai yra sudėtinga ir lėta ( web naršyklės po truputį tai ima daryti, tačiau tik pradeda).

• Patikrinti, kad serverio vardas yra įrašytas serverio sertifikate. Nes klientas ne tik nori patikrinti viešąjį raktą, bet ir įsitikinti, kad jis priklauso būtent tam serveriui. Detaliau apie tai HTTPS kontekste yra aprašyta RFC 2818. Sertifikavimo modelis su X.509 sertifikatais dažnai yra kritikuojamas, tačiau nevisai dėl techninių priežasčių, tačiau dėl politinių ir ekonominių priežasčių. Nes visa galia sukoncentruoja į kelių didelių žaidėjų rankas, kurie nebūtinai siekia gero, ar bent jau ne visada kompetetingi. Dabar jau vėl siūlomos kitos sistemos (pvz., Convergence ar DNSSEC) bet nei vienas neįgijo plataus pripažinimo (kolkas).

Kai naudojama sertifikatų pagrindu veikianti kliento autentikacija, serveris pats sprendžia, ką jam daryti su kliento sertifikatu (ir taip pat su klientu, kuris atsisakė duoti sertifikatą). Kai naudojama Windows/IIS/Active Directory kliento sertifikate turėtų būti įrašytas sąskaitos vardas (account name) kaip „User PrincipalName“ (įrašytas „Subject Alt Name extension“ sertifikato plėtinyje); serveris jo ieško Active Directory serveryje. Šakinis sertifikatas yra tikrai patikimas, jei jis platinamas yra saugiose distribucijose, programose, kurias sukūrė gerai žinomos kompanijos. Pavyzdžiui, keletas iš žinomiausių šakninių sertifikatų yra platinami interneto naršyklėse jų kūrėjų. „Microsoft“ platina šakninius sertifikatus, priklausančius „Microsoft Root Certificate Program“ programos dalyviams savo „Windows“ ir „Windows Phone“ operacinėse sistemose.

X.509 sertifikatų struktūra

X.509 sertifikatų failų struktūra yra tokia:

Pats sertifikatas
Versija
Serijos Numeris
Algoritmo identifikatorius
Išdavėjas
Galiojimas
Subject
Subject viešojo rakto informacija
Išdavėjo unikalus identifikatorius (nebūtina)
Subject unikalus identifikatorius (nebūtina)
Plėtiniai (nebūtina)
- ...
Sertifikato parašo algoritmas
Sertifikato parašas

Kiekvienas plėtinys (extension) turi savo ID, išreikštą kaip objekto identifikatorių, kuris yra reikšmių rinkinys, kartu su kritiniu arba nekritiniu indikatoriumi (jis kritinis ar ne). Sertifikatus naudojanti sistema privalo atmesti sertifikatą, jei jis turi kritinį plėtinį (critical extension), kurio jis neatpažįsta arba kritinį plėtinį, kuris turi informaciją, kurios sistema negali apdoroti. Nekritinis plėtinys gali būti ignoruotas, jei nebuvo atpažintas, bet privalo būti apdorotas, jei buvo atpažintas. Plėtinių galimybė buvo įvesta trečioje CA versijoje. CA gali naudoti plėtinius, kad išduoti sertifikatus kokiai nors specifinei sričiai, pavyzdžiui, skirtus tiktais pasirašyti skaitmeninius objektus (signing digital object arba kitaip code signing, t.y. skriptų ir programų vykdomųjų failų pasirašymas). Kiekvienas plėtinys gali būti kritinis ir nekritinis. Jei plėtinys yra kritinis ir sistema apdorodama sertifikatą jo neatpažino arba negali to plėtinio apdoroti, tai sistema tokį sertifikatą privalo atmesti. Nekritinis plėtinys jei nebuvo atpažintas arba negali būti apdorotas gali būti ignoruotas ir gali būti tęsiamas tolimesnis sertifikato apdorojimas [7]. Visose versijose kiekvienam sertifikatui, išduotam CA, serijos numeris privalo būti unukalus. Tai minima RFC2459, RFC 1422.

Plėtiniai, nurodantys specifinį sertifikato naudojimą:

RFC5280 (ir jo pirmtakai) apibrėžia kažkiek plėtinių, kurie nurodo, kaip sertifikatas turėtų būti naudojamas. Keletas populiariausių ["RFC 5280]:

• Pagrindiniai apribojimai (Basic Constraints), { id-ce 19 } yra skirta nurodyti, ar sertifikatas priklauso CA.

• Rakto naudojimas (Key Usage), { id-ce 15 } turi bitų rinkinį (bitmap), nurodantį kriptografines operacijas, kurios gali būti atliekamos naudojantis viešuoju raktu, kuris yra sertifikate, pavyzdžiui, jis gali rodyti, kad raktas turėtų būti naudojamas parašams, bet ne šifravimui.

• Išplėstinis rakto naudojimas (Extended Key Usage), { id-ce 37 }, įprastai yra naudojamas lapo (leaf) sertifikate, kad nurodyti sertifikate esančio viešojo rakto paskirtį. Jis savyje turi sarašą objektų identifikatorių (OIDs), kurių kiekvienas nurodo leidžiamą naudojimą. Pavyzdžiui, { id-pkix 3 1 } nurodo, kad raktas gali būti naudojamas TLS ar SSL ryšyje, serverio pusėje; { id-pkix 3 4 } nurodo, kad raktas galibūti naudojamas saugiam el. paštui.

Bendraja prasme, jei sertifikatas turi keletą plėtinių, kurie draudžia jo naudojimą, visi draudimai turi būti patenkinti , kad sertifikatas būtų naudojamas pagal paskirtį. RFC5280 pateikiamas specifinis pavyzdys sertifikato, kuris turi ir keyUsage, ir extendedKeyUsage plėtinius: šiuo atveju abudu turėtų būti apdorojami ir sertifikatas gali būti naudojamas tik tuo atveju , jei abudu plėtiniai yra susiję taip, kad gali nurodyti sertifikato paskirtį [8, 6].

X.509 sertifikato pavyzdys:

Pateikiamas su OpenSSL sugeneruotas dekoduoto X.509 sertifikato pavyzdys, skirtas www.freesoft.org. Paties sertifikato dydis yra apie 1kB. Jį išdavė „Thawte“ (ją veliau nusipirko „VeriSign“ ir dabar ji priklauso kompanijai „Symantec“), ką nurodo laukas „issuer“ (išdavėjas). Jo „subject“ turi daug įrašų, bet svarbiausia yra bendras vardas (common name – CN), kadangi ši dalis turi sutapti su hostu , kuris bus autentikuojamas. Taip pat sertifikate yra RSA viešas raktas, po kurio seka parašas, apskaičiuotas imant pirmosios sertifikato dalies MD5 hešą ir jį (hešą) pasirašant (pritaikant šifravimo operaciją) su „Thawse“ RSA privačiu raktu.

$ openssl x509 -in freesoft-certificate.pem -noout -text
Certificate:
   Data:
       Version: 1 (0x0)
       Serial Number: 7829 (0x1e95)
       Signature Algorithm: md5WithRSAEncryption
       Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
               OU=Certification Services Division,
               CN=Thawte Server CA/emailAddress=server-certs@thawte.com
       Validity   
           Not Before: Jul  9 16:04:02 1998 GMT
           Not After : Jul  9 16:04:02 1999 GMT
       Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
                OU=FreeSoft, CN=www.freesoft.org/emailAddress=baccala@freesoft.org
       Subject Public Key Info:
           Public Key Algorithm: rsaEncryption
           RSA Public Key: (1024 bit)
               Modulus (1024 bit):
                   00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb:
                   33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1:
                   66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66:
                   70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17:
                   16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b:
                   c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77:
                   8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3:
                   d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8:
                   e8:35:1c:9e:27:52:7e:41:8f
               Exponent: 65537 (0x10001)
   Signature Algorithm: md5WithRSAEncryption
       93:5f:8f:5f:c5:af:bf:0a:ab:a5:6d:fb:24:5f:b6:59:5d:9d:
       92:2e:4a:1b:8b:ac:7d:99:17:5d:cd:19:f6:ad:ef:63:2f:92:
       ab:2f:4b:cf:0a:13:90:ee:2c:0e:43:03:be:f6:ea:8e:9c:67:
       d0:a2:40:03:f7:ef:6a:15:09:79:a9:46:ed:b7:16:1b:41:72:
       0d:19:aa:ad:dd:9a:df:ab:97:50:65:f5:5e:85:a6:ef:19:d1:
       5a:de:9d:ea:63:cd:cb:cc:6d:5d:01:85:b5:6d:c8:f3:d9:f7:
       8f:0e:fc:ba:1f:34:e9:96:6e:6c:cf:f2:ef:9b:bf:de:b5:22:
       68:9f

Kad patvirtinti šį sertifikatą reikalingas kitas sertifikatas, kuris atitinka išdavėją (šiuo atveju Thawte Server CA). Pirmiausia reikia patikrinti ar tas kitas sertifikatas yra CA rūšies, t.y. ar jis gali būti naudojamas kitų sertifikatų išdavimui. Tai atliekama peržiūrint plėtinio X509v3 viduje esančią CA atributo reikšmę. Tuomet RSA viešas raktas iš CA sertifikato yra panaudojamas pirmojo sertifikato parašo dešifravimui, kad būtų ištrauktas MD5 hešas, kuris turi sutapti su apskaičiuotu MD5 hešu. CA sertifikato, tinkančiam aukščiau pateiktam, pavyzdys:

$ openssl x509 -in thawte-ca-certificate.pem -noout -text
Certificate:
   Data:
       Version: 3 (0x2)
       Serial Number: 1 (0x1)
       Signature Algorithm: md5WithRSAEncryption
       Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
               OU=Certification Services Division,
               CN=Thawte Server CA/emailAddress=server-certs@thawte.com
       Validity
           Not Before: Aug  1 00:00:00 1996 GMT
           Not After : Dec 31 23:59:59 2020 GMT
       Subject: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc,
                OU=Certification Services Division,
                CN=Thawte Server CA/emailAddress=server-certs@thawte.com
       Subject Public Key Info:
           Public Key Algorithm: rsaEncryption
           RSA Public Key: (1024 bit)
               Modulus (1024 bit):
                   00:d3:a4:50:6e:c8:ff:56:6b:e6:cf:5d:b6:ea:0c:
                   68:75:47:a2:aa:c2:da:84:25:fc:a8:f4:47:51:da:
                   85:b5:20:74:94:86:1e:0f:75:c9:e9:08:61:f5:06:
                   6d:30:6e:15:19:02:e9:52:c0:62:db:4d:99:9e:e2:
                   6a:0c:44:38:cd:fe:be:e3:64:09:70:c5:fe:b1:6b:
                   29:b6:2f:49:c8:3b:d4:27:04:25:10:97:2f:e7:90:
                   6d:c0:28:42:99:d7:4c:43:de:c3:f5:21:6d:54:9f:
                   5d:c3:58:e1:c0:e4:d9:5b:b0:b8:dc:b4:7b:df:36:
                   3a:c2:b5:66:22:12:d6:87:0d
               Exponent: 65537 (0x10001)
       X509v3 extensions:
           X509v3 Basic Constraints: critical
               CA:TRUE
   Signature Algorithm: md5WithRSAEncryption
       07:fa:4c:69:5c:fb:95:cc:46:ee:85:83:4d:21:30:8e:ca:d9:
       a8:6f:49:1a:e6:da:51:e3:60:70:6c:84:61:11:a1:1a:c8:48:
       3e:59:43:7d:4f:95:3d:a1:8b:b7:0b:62:98:7a:75:8a:dd:88:
       4e:4e:9e:40:db:a8:cc:32:74:b9:6f:0d:c6:e3:b3:44:0b:d9:
       8a:6f:9a:29:9b:99:18:28:3b:d1:e3:40:28:9a:5a:3c:d5:b5:
       e7:20:1b:8b:ca:a4:ab:8d:e9:51:d9:e2:4c:2c:59:a9:da:b9:
       b2:75:1b:f6:42:f2:ef:c7:f2:18:f9:89:bc:a3:ff:8a:23:2e:
       70:47

Tai save pasirašančio (self-signed) sertifikato pavyzdys, kadangi ir išdavėjas (issuer), ir subject yra tas pats. Nėra kito būdo patikrinti šį sertifikatą, nebent jį palyginti su savimi. Vietoje to šie šakniniai (top-level, t.y. medžio viršūnėje esantys) sertifikatai yra saugomi su kiekviena naršykle, kaip jau buvo minėta anksčiau. „Thawte“ yra viena iš šakninių (root) sertifikatų CA, pripažinta „Microsoft“, „Netscape“ ir kt. Šis sertifikatas yra instaliuojamas kartu su naršykle ir juo pasitikima pagal nutylėjimą. Šis sertifikatas egzistuoja jau ilgą laiką ir juo yra globaliai pasitikima, bei juo galima pasirašyti viską, kadangi jis neturi jokių apribojimų (constraints) X509v3 pagrindinių apribojimų sekcijoje. Jį atitinkantis privatus raktas privalo būti kruopščiai saugomas.

Trumpa SSL/TLS istorija

Kaip jau minėta, SSL protokolą sukūrė „Netscape“. 1.0 versija niekada nebuvo viešai išleista, versija 2.0 buvo išleista 1995 m. vasarį, bet turėjo daugybę sugumo spragų ir laikyta juodraštine (draft) versija, tad būtinai teko kurti 3.0 versiją [Rescorla 2001]. SSL versija 3.0, išleista 1996 metais ir tai buvo visiškai perdarytas protokolas, sukurtas Paul Kocher, dirbusio su Netscape inžinieriais Phil Karlton ir Alan Freier. Naujesnės SSL/TLS versjos remiasi SSL 3.0. Nors visdar „Netscape Communications“ nuosavybė (ar tos kompanijos, kuriai ši dabar priklauso), 1996 m. SSL 3.0 juodraštinė versija buvo išplatinta IETF kaip istorinis dokumentas, pateiktas RFC 6101. Tuo tarpu protokolas buvo standartizuotas nauju pavadinimu, kad išvengti teisinių sunkumų. Naujasis jo vardas yra TLS. Pagrindinį algoritmą parašė Dr. Taher Elgamal. Kaip pagrindinis Netscape mokslininkas, Dr. Elgamal yra pripažintas „SSL tėvu“. SSL versija 3.0 dabar laikoma nebesaugia, kadangi pažeidžiama POODLE atakos. Šį pažeidžiamumą aptiko „Google“ saugumo komanda ir atskleidė 2014 m. rugsėjį.

TLS 1.0

TLS 1.0 ankščiausia minimas RFC 2246, 1999 m. sausį, kaip SSL 3.0 atnaujinimas. Kaip skelbiama RFC, „skirtumai tarp šio protokolo ir SSL 3.0 yra neryškūs. Protokolo pavadinimas buvo pakeistas (standartizuotas nauju pavadinimu) siekiant išvengti teisinių klausimų. TLS 1.0 turi galimybę pažeminti (downgrade) susijungimą į SSL 3.0 taip sumažinant saugumą [9].

TLS 1.1

* TLS 1.1 buvo apibrėžtas 2006 m. balandį, RFC 4346. Tai TLS 1.0 versijos atnaujinimas. Pagrindiniai skirtumai šioje versijoje yra tokie: * Įdėta apsauga nuo chipher-blocking chaining (CBC) atakų * Numatomas (implicit) initializacijos vektorius (IV – fiksuoto dydžio įvestis kriptografiniams primityvams, t.y. žemo lygmens kriptografijos algoritmams, kurie įprastai naudojami sudarant kriptografijos protokolus; įprastai tai atsitiktiniai ar pseudo atsitiktiniai skaičiai) buvo pakeistas į aiškiai (explicit) apibrėžtą IV. * Lygiavimo klaidų (padding errors paskirtis: block cipher dirba su tam tikro fiksuoto dydžio [žinomo kaip block size] vienetais, nors pranešimai ateina įvairiausių ilgių). Todėl kai kuriais atvejais galutinis blokas bus papildytas [padded] prieš šifravimą) valdymo (handling) būdų pakeitimas

TLS 1.2

TLS 1.2 ankščiausia paminėtas RFC 5246, 2008 balandį. Remiasi TLS 1.1 specifikacija. Esminiai pakeitimai:

• MD5-SHA-1 ir pseudoatsitiktinės funkcijos (PRF, pseudorandom function) naudojimas kartu buvo pakeistas į SHA-256, su galimybe naudoti pasirinktą PRF

• MD5-SHA-1 naudojimas kartu su pabaigto pranešimo hešu buvo pakeistas į vieną hešą, perduodamą, kai vyksta handshake, o tuomet pagal nutylėjimą naudojama SHA-1.

• Išplėsta kliento ir serverio galimybė nurodyti, kuriuos hešavimo ir parašo algoritmus jie priims

• Išplėstas autentikuoto šifravimo (AE) šifrų (ciphers) palaikymas, naudotų pagrinde Galois/Counter Mode (GCM) ir CCM mode of Advanced Encryption Standard šifravime.

• TLS išplėtimai apibrėžti AES (Advanced Encryption Standard) šifravimo algoritmai buvo pridėti

Visos TLS versijos vėliau buvo surašytos į RFC 6176 2011 kovą, pašalinant jų atgalinį suderinamumą su SSL taip, kad TLS sesijos niekada nebegalėtų bandyti naudoti SSL 2.0.

TLS 1.3 (draft)

Dabar (2014 m. lapkritį) TLS 1.3 vis dar yra juodraštinė versija ir jis dar nėra pilnai apibrėžtas. Remiasi TLS 1.1 ir TLS 1.2. Keliatas pagrindinių pasikeitimų nuo TLS 1.2:

• Pašalintas GMT laikas

• Iš dalies apjungtas ECC (Elliptic Curve Cryptography) iš RFC 4492

• Ir kt. [1]

SSL 3.0 ir TLS 1.0 skiriasi labai nežymiai ir didžioji dalis kodo (source code) sutampa. Todėl nenuostabu, kad kartais TLS 1.0 vadinamas SSL 3.1 ir tai nelaikoma klaida [2] TLS 1.1 ir 1.2 nėra plačiai palaikomi, nes turi trūkumų, pavyzdžiui, pažeidžiami BEAST atakos. SSLv3 ir TLS 1.0 yra palaikomi labai plačiai (netgi IE 6.0 palaiko).

Kaip veikia SSLv3 ir TLS

IP (TCP/IP) modelyje, SSL ir TLS šifruoja tinklo duomenis taikomajame (application) lygmenyje. OSI modelyje TLS/SSL yra initializuojamas penktame (sesijos) ir dirba šeštame (prezentacijos) lygmenyje. Sesijos lygmenyje atliekamas pradinis susijungimas (handshake) naudojant asimetrinį šifravimą, kad apsikeisti tolimesnio šifravimo duomenimis ir šios sesijos viešuoju raktu. Abejuose modeliuose TLS ir SSL dirba virš žemiau esančio transporto lygmens, kuris pereduoda jau šifruotus duomenis. TLS protokolas leidžia kliento-serverio tipo programoms bendrauti per internetą tokiu būdu, kad perduodamų duomenų pašaliniai negalėtų klausytis bei klastoti. Kadangi protokolai gali dirbti su arba be TLS (ar SSL), klietas būtinai turi pranešti serveriui, kad jis nori bendrauti saugiai – kad serveris ruoštųsi saugiam susijungimui. Tam pasiekti yra du būdai. Pirmasis – pasinaudoti kitu prievado(porto) numeriu, kuris skirtas specialiai TLS susijungimams (pavyzdžiui, prievadas 443, t.y. HTTPS). Antrasis būdas – klientas prisijungia nesaugiu būdu ir tada paprašo serverio, kad serveris susijungimą permestų ant TLS, pasinaudodamas specifiniu naudojamo protokolo mechanizmu (pavyzdžiui, jei naudojamas el. pašto ar naujienų protokolas tai yra STARTTLS komanda). Kai jau TCP susijungimas tarp kliento ir serverio užmegstas bei klientas ir serveris susitarė, kad naudos TLS, jie tariasi dėl susijungimo naudodamiesi handshake procedūrą. Šios procedūros metu klientas susitaria su serveriu dėl įvairiausių parametrų, kad užtikrinti kuo saugesnį ryšį. Ji vadinama handshake ir čia aprašoma keletą kartų, vis labiau detalizuojant ir naudojant skirtingus atvejus.

„Handshake“ procedūra trumpai

Tarime, yra bankas ir vartotojas, norintis prie jo prisijungti. Kai vartotojas atsidaro banko tinklapį, banko serveris, prieš jam parodydamas prisijungimo formą, jį automatiškai nukreipia jį į savo saugų tinklapį, kuriame naudojamas HTTPS protokolas. Tuomet tarp banko tinklapio ir vartotojo naršyklės prasideda derybos sėl saugaus kanalo (SSL) naudojimo. Labai supaprastintas derybų procesas yra toks. Naršyklė nusiunčia pranešimą, kuriame yra skelbiama, kokią vėliausią SSL versiją jis palaiko ir sąrašą simetrinių algoritmų, kuriuos jis gali taikyti. Tada web serveris vartotojui nusiunčia atsakymą, kuriame yra nurodyta, kuri SSL versija ir koks algoritmas bus naudojami. Jis taip pat nusiunčia ir sertifikatą. Naršyklė patikrina sertifikatą pasinaudodama žinomais sertifikatais, kurie buvo kartu su ja suinstaliuoti. Kitaip tariant, ji patikrina, ar sertifikatas yra pasirašytas patikimos CA ir jo galiojimo laikas nėra pasibaigęs. Jei sertifikatas galioja, naršyklė sugeneruoja vienkartinį raktą, kuris bus naudojamas tik šios sesijos metu, užšifruoja serverio viešuoju raktu (jis yra sertifikate) ir nusiunčia jį serveriui. Serveris dešifruoja raktą ir tuomet jį naudoja su sutartu simetrinio šifravimo algoritmu visos sesijos metu. Užmezgus saugų ryšį ir prasidėjus sesijai banko serveris atsiunčia vartotojui formą ir paprašo įvest vartotojo vardą ir slaptažodį. Visi duomenys jau yra perduodami šifruoti. [10]

Svarbu žinoti [2]

Kodėl jei pasitiki „GeoTrust“, tai pasitiki ir „Google.com“?

Tinklapis su vartotoju nori bendrati saugiai. Kad patikrinti jo tapatybę ir skiekiant būti užtikrintu, kad tai nėra kenkėjas, reikia gauti serverio viešąjį raktą. Tačiau nelabai įmanoma vartotojui saugoti visus raktus iš visų pasaulyje egzistuojančių tinklapių, duomenų bazė būtų milžiniška ir atnaujinimai turėtų būti daromi kas valandą. Šios problemos sprendimas yra CA. Kai instaliuojama operacinė sistema ir naršyklė, yra instaliuojamas ir sąrašas su patikimom (trusted) CA. Jei vartotojas nori, tai šį sąrašą gali modifikuoti, gali pašalinti tai, kuo nepasitiki, pridėti kitus CA ar netgi susikurti savo CA (tačiau tokia CA pasitikės tik jis vienas, tad iš jos nedaug naudos, jei norėtų naudoti viešam tinklapiui). Šiame CA sąraše taip pat saugomi ir viešieji raktai. Kai „Google“ serveris išsiunčia vartotojui jo sertifikatą, jis taip pat pamini, kad jis yra pasirašytas „GeoTrust“. Jei vartotojas pasitiki „GeoTrust“, tai, naudodamas „GeoTrust“ viešąjį raktą, vartotojas gali patikrinti, kad „GeoTrust“ tikrai pasirašė serverio sertifikatą. Šiaip betkas pats sertifikato pasirašyti negali, kadangi tam reikalingas „GeoTrust“ privatus raktas, žinomas tik pačiam „GeoTrust“. Todėl kenkėjas negali pats pasirašyti sertifikato „GeoTrust“ vardu ir apsimesti, kad jis yra „Google.com“. Kai sertifikatas modifikuojamas nors vienu bitu, parašas nustoja galioti ir klientas juo nebepasitikės ir tokį sertifikatą atmes.

Taigi, jei žinau viešąjį raktą, tai serveris gali patvirtinti savo tapatybę?

Taip. Įprastai viešasis raktas šifruoja, o privatus dešifruoja. Užšifravus pranešimą serverio viešuoju raktu ir jį išsiuntus, jei serveris galės pasakyti, ką iš pradžių sakė, tai patvirtina, kad jis turi privatų raktą neatskleisdamas savo rakto. Štai dėl to yra labai svarbu pasitikėti viešuoju raktu: kiekvienas gali sugeneruoti privataus/viešo rakto porą, taip pat ir kenkėjas. Nesinori galiausia naudotis kenkėjo viešuoju raktu. Jei vienas iš CA, kuriuo vartotojas pasitiki tampa pažeistas, kenkėjas gali naudoti pavogtą privatų raktą, kad pasirašyti sertifikatą kokiam tik nori tinklapiui. Kai kenkėjas gali nusiųsti suklastotą sertifikatą vartotojo klientui, klientas juo pasitikės, nes nežinos, kad viešas raktas yra suklastotas, pasirašytas vogtu privačiuoju raktu.

Bet CA gali leisti man pasitikėti, bet kokiu serveriu, kokiu jie tiktais nori!

Taip. Jie nepasirašo betkam. Netgi kai organizacijos, tokios, kaip Microsoft, Mozilla pasitiki CA, CA turi auditus – kita organizacija periodiškai tikrina, kad būtų užtikrinta, jog viskas vyksta pagal susitarimus. Sertifikatas išduodamas tada ir tik tada, jei besiregistruojantis gali įrodyti, kad jis yra domeno, kuriam bus išduotas sertifikatas, savininkas.

Kas pranešimo autentikacijai yra MAC?

Kiekvienas pranešimas yra pasirašomas taip vadinamu pranešimo autentikacijos kodu (Message Autentication Code – MAC). Jei klientas ir serveris susitars dėl rakto ir šifravimo algoritmo, klientas galės patikrinti, kad to serverio pranešimas gautas būtent iš to serverio ir atvirkščiai. Pavyzdžiui, su raktu „correct horse battery staple“ ir pranešimu „example“ serveris gali paskaičiuoti MAC „58393“. Kai jis pranešimą su tuo MAC nusiųs klientui (klientas jau raktą žino), tai klientas gali atlikti tuos pačius skaičiavimus ir palyginti gautą MAC su tuo, kurį atsiuntė serveris. Kenkėjas gali modifikuoti pranešimą, tačiau nežino rakto, tad negali paskaičiuoti teisingo MAC. Jei įterpiamas sekos numeris, kai skaičiuojamas MAC, galima pašalinti atsako (reply) atakų riziką. SSL tai atlieka.

Buvo minėta, kad klientas išsiunčia raktą, kuris tuomet naudojamas siekiant pradėti simetrinį šifravimą. Kas kenkėjui jį trukdo naudoti?

Trukdo serverio viešas raktas. Kadangi patikrinome, jog viešas raktas tikrai priklauso serveriui ir ne kamnors kitam, mes galime šį raktą užšifruot viešuoju raktu. Kai serveris tai gauna, jis jį gali dešifruoti naudodamasis savo privačiu raktu. Kai ššį šifruotą raktą gaus kas nors kitas, tai negalės jo dešifruoti. Čia taip pat svarbus rakto dydis: kuo ilgesnis viešas ir privatus raktas, tuo sunkiau yra nulaužti tą raktą, kurį klientas siunčia serveriui.

Įrašai (Records)

SSL yra išskaidytas į keletą lygmenų. Apatinis lygmuo yra įrašų protokolas. Betkokie duomenys, siunčiami SSL tuneliu, yra padalinami į įrašus. Žemiau esančiam TCP lygmeniui jie atrodo taip:

HH V1:V2 L1:L2 data

kur:

• HH – vienas baitas, nurodantis, kokio tipo duomenys yra įraše. Egzistuoja keturi tipai: change_cipher_spec (20), alert (21), handshake (22) ir application_data (23).

• V1:V2 – protokolo versija, užima du baitus. Visom dabar egzistuojančiom versijom, V1 reikšmė yra 0x03, o V2 reikšmė yra 0x00, kai naudojamas SSLv3, 0x01, kai naudojamas TLS 1.0, 0x02, kai naudojamas TLS 1.1 ir 0x03, kai naudojamas TLS 1.2.

• L1:L2 – duomenų ilgis baitais (big-endian formatas, t.y. ilgis = 256*L1+L2). Visas duomenų ilgis negali viršyti 18432 baitų, tačiau praktiškai net negali ir pasiekti šios reikšmės.

Taigi, įrašas turi penkių baitų antraštę, po kurios eina 18 kB duomenų. Šiems duomenims pritaikytas simetrinis šifravimas ir vientisumo patikrinimas. Kai įrašas išsiunčiamas, siuntėjas ir gavėjas jau turėtų būti prieš tai susitarę, kokį kriptografijos algoritmą naudoja ir su kokiais raktais. Šis susitarimas turėjo būti padarytas handshake procedūros metu. Jei naudojamas, tai čia jau yra pritaikytas ir suspaudimo algoritmas.

Detaliau, įrašo sudarymas vyksta taip:

Pradžioje yra keletas baitų, kuriuos reikia perduoti. Tai programos duomenys ar dar kokie nors baitai. Šie naudingieji duomenys (payload) turi neviršyti 16384 baitų, ar net mažiau (0 yra leistina, tačiau „Internet Explorer 6.0“ to nemėgsta).

• Šie duomenys suspaudžiami naudojant sutartinį suspaudimo algoritmą.

• Compression priklauso ir nuo ankstesnių įrašų turinio. Praktikoje suspaudimas yra „null“ (nesuspaudžiama visai) arba „Deflate“ (RFC 3749), pastarasis jau išeidinėja iš naudojimo Web kontekste dėl nesenos CRIME ir „Poodle“ atakos. Nors suspaudimo tikslas yra sutrumpinti perduodamus duomenis, tačiau būna atveju, kai pasitaiko nepalankios sąlygos ir duomenys užuot suspaudžiami, truputį išsiplečia (dėl pigeonhole principo). SSL leidžia išsiplėsti iki 1024 papildomų baitų. Žinoma, „null“ suspaudimo atveju įrašas niekada neišsiplės, tačiau niekada ir nesutrumpės; „Deflate“ suspaudimas gali išplėsti iki 10 baitų, jei realizacija yra gera.

• Suspausti naudingieji duomenys (payload) po to yra apsaugojami nuo pakitimų ir užšifruojami. Jei vientisumo tikrinimo ir šifravimo algoritmai yra „null“, tada šiame žingsnyje niekas neatliekama. Kitu atveju pridedamas MAC ir kažkiek papildymo (padding) baitų (priklausomai nuo šifravimo algoritmo) ir rezultatas užšifruojamas. Šie žingsniai kažkiek paaiškina, kodel SSL riboja įrašo išplėtimą tik 1024 papildomais baitais (kartu su maksimaliu išplėtimu suspaudimo žingsnyje; iš to gaunamas iki 18432 baitų įrašas, prie kurio dar reikia pridėti 5 baitų antraštę).

MAC įprastai yra HMAC (hešuotas MAC) su viena iš įprastinių hešavimo funkcijų (dažniausia MD5, SHA-1 ar SHA-256)(su SSLv3, tai nėra „tikrasis“ HMAC, tačiau kažkas į tai labai panašaus ir, geriausia yra tai, kad saugus kaip HMAC). Šifruojama įprastai naudojant blokų šifravimo algoritmą (block cipher) CBC režime arba RC4 srauto šifravimo algoritmą (stream cipher). Reikėtų pabrėžti, kad teoriškai kiti režimai ar kiti algoritmai gali būti irgi panaudoti, pavyzdžiui, vienas iš tokių, kurie apjungia šifravimą ir vientisumo tikrinimą. Apie tai yra netgi keletas RFC. Tačiau išplatintos realizacijos dar to nežino, todėl naudoja HMAC ir CBC. Svarbiausia, kad MAC pirmiausia yra paskaičiuojamas ir pridedamas prie duomenų ir tada rezultatas užšifruojamas. Tai vadinama MAC-and-encrypt, bet taip daryti nėra labai gera mintis. MAC yra skaičiuojamas jau po sekos numerio sujungimo su naudingais duomenim (payload), tad kruopštus užpuolikas negali sukeisti įrašų. [2]

„Handshake“ procedūra išsamiau

Handshake yra protokolas, kuris yra įrašų (record) protokole. Jo tikslas – nustatyti algoritmus ir raktus, kurie bus naudojami įrašams. Jis susideda iš pranešimų. Kiekvienas handshake pranešimas prasideda 4 baitų antrašte: vienas baitas nusako pranešimo tipą, o likę trys – pranešimo ilgį (big-endian formatas naudojamas). Sėkmingi handshake pranešimai tuomet yra nusiunčiami įrašais, kurių pranešimo tipą nurodantis baitas turi reikšmę, nurodančią „handshake“ tipą (pirmasis kiekvienos tokios antraštės baitas, reikšmė 22) Čia galima pastebėti lygmenis: handshake pranešimas, prie kurio pridėta 4 baitų antraštė, tuomet yra siunčiami kaip įrašai ir kiekvienas įrašas taip pat turi savo antraštę. Negana to, net keletas handshake pranešimų gali būti išsiųsti tame pačiame įraše, bei koks nors handshake pranešimas gali būti išdalintas į keletą įrašų. Modulio, kuris kuria handshake pranešimus, atžvilgiu, „įrašai“ yra tiesiog srautas, kuriuo gali būti perduoti baitai. Tačiau reikėtų nepamiršti, kad iš tiesų šis srautas skaidomas į įrašus.

1. Klientas nusiunčia serveriui savo naudojamos SSL versijos numerį, šifravimo nustatymus (cipher settings) – šifravimo algoritmus, kuriuos jis norėtų naudoti, kokius suspaudimo metodus jis norėtų naudoti, bei specifinius šios sesijos duomenis ir kitą informaciją, kuri reikalinga serveriui, kad jis galėtų bendrauti su klientu naudodamas SSL.

2. Serveris pasitikrina, kokią aukščiausią SSL/TLS versiją jie abu palaiko, pasirenka vieną iš kliento siųlomų šifravimo algoritmų (ciphersuite) (jei bent kurį nors palaiko), jei nori, pasirenka, kokį suspaudimo algoritmą naudos iš kliento siūlomų. Ir nusiunčia klientui savo SSL versijos numerį, šifravimo nustatymus, specifinius šios sesijos duomenis ir kitą informaciją, kuri reikalinga klientui, kad jis galėtų bendrauti su serveriu naudodamas SSL. Serveris taip pat nusiunčia savo sertifikatą. Klientas turės pranešti serveriui, kad šiuo sertifikatu pasitiki, o jis gali pasitikėti, jei šiuo sertifikatu pasitiki jis pats arba ta šalis, kuria jis (klientas) pasitiki. Pavyzdžiui, jei klientas pasitiki „GeoTrust“, tai jis gali pasitikėti sertifikatu iš „Google.com“, nes šį sertifikatą pasirašė GeoTrust. Tuomet klientas gali būti užtikrintas, kad serveris su kuriuo bendrauja nėra apsimetėlis ir kad tai nėra man-in-the-middle situacija (srautas eina ne per tarpinį asmenį). Ir jei klientas prašo serverio tokio resurso, kurį serveris gali duoti tik tada, jei klientas autentikuosis, tai serveris paprašo kliento, kad jis duotų savo sertifikatą.

3. Klientas naudoja informaciją, kurią jam atsiuntė serveris, kad autentikuotų serverį, pvz. jeigu web naršyklė jungiasi prie web serverio, naršyklė patikrina, ar gauto sertifikato „subject name“ laukas iš tiesų atitinka serverio, su kuriuo yra jungiamasi, vardą, ar sertifikatą išdavė patikima CA (trusted CA), ar sertifikato galiojimo laikas nepasibaigęs ir, idealiu atveju, ar sertifikatas nėra panaikintas (tačiau tai patikrinti užtruktų ilgesnį laiką ir taip sulėtintų naršymą, todėl įprastai naršyklės to nedaro, nebent vartotojas pats taip sukonfigūravo). Jei serveris negali būti autentkuotas, vartotojas yra perspėjamas apie šią problemą ir informuoja, kad šifruotas ir autentikuotas susijungimas nepavyko. Jei serveriui pavyko autentikuotis, klientas pereina prie sekančio žingsnio.

4. Naudojantis visais duomenimis, kurie buvo sugeneruoti handshake metu iki šiol ir jau būdamas tikrai užtikrintas, kad serveris su kuriuo bendrauja nėra apsimetėlis ir kad tai nėra man-in-the-middle, klientas su serveriu apsikeičia raktais. Tai jis atlieka padedamas serverio ir priklausomai nuo naudojamo šifravimo tai gali būti viešas raktas, viešoji paslaptis tarp savęs ir serverio (pre-master secret), ar paprasčiausia niekas. Prieš ją išsiųsdamas, užšifruoją ją su serverio viešuoju raktu (ištrauktu iš serverio sertifikato, kuris buvo gautas 2 žingsnyje) ir tada nusiunčia serveriui tą šifruotą pre-master secret, viešą raktą ar dar ką.

5. Jei serveris paprašė kliento autentikacijos (neprivalomas žingsnis handshake procedūroje), klientas taip pat pasirašo kitą gabalą duomenų, kurie yra unikalūs šiam handshake ir žinomi tiek klientui, tiek serveriui. Šiuo atveju klientas nusiunčia pasirašytus duomenis ir savo paties sertifikatą serveriui kartu su užšifruota pre-master secret.

6. Jei serveris paprašė kliento autentikacijos, serveris bando autentikuoti klientą. Jei kliento autentikacija nesėkminga, tai susijungimas užbaigiamas. Jei klientą sėkmingai pavyko autentikuoti arba jei serveris nusprendė, kad vis delto šioje sesijoje klientą prileis be autentikacijos, serveris naudoja savo privatų raktą, kad dešifruoti pre-master secret ir tuomet atlieka keletą žingsnių (kuriuos klientas taip pat atlieka, pradėdamas nuo tos pačios pre-master secret), kad sugeneruotų master secret.

7. Ir klientas, ir serveris naudoja šią master secret sesijos raktams sugeneruoti, kurie bus simetriniai (nes simetriniai algoritmai greitesni už asimetrinius) ir skirti tam, kad šifruoti ir dešifruoti SSL sesijos metu perduodamus duomenis ir tikrinti duomenų vientisumui (t.y. nustatyti, ar nebuvo duomenyse padaryta pakeitimų, kol jie keliavo tarp kliento ir serverio naudojant SSL ryšį).

8. Klientas nusiunčia pranešimą serveriui (MAC), informuodamas jį, kad sekantys kliento pranešimai bus šifruoti sesijos raktu. Tuomet jis nusiunčia atskirą (šifruotą) pranešimą, kad klientas užbaigė handshake procedūrą.

9. Serveris patikrina ar tas MAC (naudojamas autentikacijai) yra teisingas ir ar pranešimas gali būti teisingai dešifruotas. Tuomet jis nusiunčia pranešimą klientui, informuodamas jį, kad sekantys serverio pranešimai bus šifruoti sesijos raktu. Tuomet jis nusiunčia atskirą (šifruotą) pranešimą, kad serveris užbaigė handshake procedūrą. Šiuos pranešimus klientas taip pat patikrina.

SSL handshake procedūra dabar jau yra užbaigta ir sesija prasideda. Klientas ir serveris naudoja sesijos raktus, kad užšifruotų ir dešifruotų duomenis, kuriuos jie perdavinėja vienas kitam bei tikrintų jų vientisumą. Tai saugaus kanalo normalaus darbo sąlyga. Bet kuriuo metu dėl vidinių ar išorinių veiksnių (pavyzdžiui, automatizacijos ar vartotojo įsikišimo) bet kuri pusė (serveris ar klientas) gali iš naujo pradėti susijungimą. Tokiu atveju šis procesas kartojamas iš naujo. Jei bet kuris iš aukščiau išvardintų žingsniu būna nesėkmingas, TLS handshake laikomas nesėkmingu ir susijungimas lieka neužmegstas. 3 žingsnyje klientas privalo patikrinti parašų grandinę iš „root of trust“ (šakninių sertifikatų), kurie buvo kartu su klientu arba kuriuos pridėjo vartotojas . Klientas taip pat privalo patikrinti, kad nei vienas iš jų nebuvo atšauktas; tai nevisuomet yra teisingai realizuota, bet visad to reikalaujama iš kiekvienos viešųjų raktų autentikavimo sistemos. Jei tam tikras pasirašantysis šio serverio grandinės pradžioje yra patikimas ir visi parašai šioje grandinėje lieka patikimi, tai sertifikatas (tad ir serveris) lieka patikimas.[1]

Kad užbaigti ryšį, close_notify 'alert' perspėjimas yra naudojamas. Jei įsilaužėlis bandys nutraukti susijungimą užbaigdamas TCP sesiją (įterpdamas FIN paketą), abi pusės žinos, kad susijungimas buvo nutrauktas neteisingai. Taip įsilaužėlis niekaip kitaip negalėjo pakenkti, o tik laiknai nutraukė susijungimą, kurį be problemų galima pradėti iš naujo. [2]

Pilnas handshake žemesniame lygmenyje

Pradžioje klientas ir serveris susitaria dėl „null“ šifravimo ir „null“ suspaudimo, bei kad nebus MAC. Tai reiškia, kad pirmasis įrašas bus atviru tekstu (cleartext) ir neapsaugotas. Pirmasis handshake pranešimas yra ClientHello. Išsiųsdamas šį pranešimą serveriui, klientas jam pasako, kad nori bendrauti su serveriu slaptai, t.y. naudojant SSL. HTTPS kontekste tai yra taip: HTTP-per-SSL-per-TCP. Visi trys lygmenys yra ir kliente, ir serveryje ir šie lygmenys yra tose pat vietose. TCP klientas taip pat yra ir SSL klientas, ir HTTP klientas šiuo atveju.

ClientHello pranešime yra:

• Vėliausia protokolo versija, kurią klientas palaiko

• „Client random“ (32 baitai, iš kurių 28 turėtų būti sugeneruoti su atsitiktinių skaičių generatoriumi, kuris specialiai sudarytas taip, kad jo generuojami skaičiai būtų gerai tinkami kriptografijai)

• Sesijos identifikatorius (jei klientas norės pratęsti sesiją naudodamas sutrumpintą handshake, žiūrėti toliau)

• Šifravimo algoritmų rinkinių (cipher suites) sąrašas, kurį klientas palaiko, surūšiuotas kliento norima tvarka

• Suspaudimo algoritmų sąrašas, kurį klientas palaiko, surūšiuotas kliento norima tvarka

• Keletas nebūtinų išplėtimų (extensions).

„cipher suite“ – 16 bitų simbolinis identifikatorius, skirtas kriptografinių algoritmų rinkiniui (cipher suite). Pavyzdžiui, TLS_RSA_WITH_AES_128_CBC_SHA šifravimo algoritmo atvejui šis identifikatorius lygus 0x002F, o tai reiškia „įrašai naudoja HMAC/SHA-1 ir AES šifravimą su 128-bitų raktu, bei rakto apsikeitimas atliekamas šifruojant atsitiktinį raktą su serverio RSA viešuoju raktu“. Serveris į ClientHello atsako atsiųsdamas ServerHello pranešimą, kuriame yra:

• Protokolo versija, kurią naudos klientas ir serveris

• „Server random“ (32 baitai, iš kurių 28 atsitiktiniai);

• Šio susijungimo sesijos identifikatorius

• Šifravimo algoritmų rinkinys (cipher suite), kuris bus naudojamas

• Suspaudimo algoritmas, kuris bus naudojamas;

• Keletas nebūtinų išplėtimų (extensions).

Pilnas handshake atrodo taip [11]:

Atliktas ClientHello ir ServerHello. Tada serveris išsiunčia keletą kitų pranešimų, kurie priklauso nuo pasirinkto šifravimo algoritmų rinkinio ir keleto kitų parametrų: • Sertifikatas: serverio sertifikatas, kuriame yra serverio viešasis raktas. Daugiau apie tai pateikta žemiau. Šis pranešimas visada išsiunčiamas, išskyrus tuos atvejus, jei šifravimo algoritmų rinkinys nusprendžia padaryti handshake be sertifikato. • ServerKeyExchange: keletas papildomų reikšmių, kad apsikeisti raktais, jeigu to, kas yra sertifikate nepakanka. Pavyzdžiui, DHE šifravimo algoritmų rinkinys (cipher suite) naudoja trumpalaikį Diffie Hellman rakto apsikeitimą, dėl ko reikalingas šis pranešimas. • CertificateRequest: pranešimas, reikalaujantis, kad klientas taip pat prisistatytų su savo sertifikatu. Šiame pranešime yra sąrašas patikimų šakninių sertifikatų vardų, kuriuos serveris naudos, kad patikrinti kliento sertifikatą • ServerHelloDone: pranešimas-markeris (nulinio ilgio), kuris pasako, kad serveris baigė kalbėti, tad atėjo laikas kalbėti klientui.

Klientas turi atsakyti su:

• Sertifikatas: kliento sertifikatas, jei serveris jo prašo. Yra nežymių pokyčių tarp skirtingų versijų (kai SSLv3 naudojamas, tai klientas šį pranešimą turi praleisti, jei neturi sertifikato; TLS 1.0+ atveju jis turi išsiųsti šį pranešimą su jame esančiu tuščiu sertifikatų sąrašu). • ClientKeyExchange: rakto apsikeitimo proceso kliento dalis (pavyzdžiui, keletas atsitiktinių skaičių, užšifruotų serverio RSA raktu) • CertificateVerify: skaitmeninis parašas, apskaičiuotas kliento per visus ankstesnius handshake pranešimus. Šis pranešimas yra išsiųstas, kai serveris paprašo kliento sertifikato ir klientas jį atsiuntė. Tai tokiu būdu klientas įrodo serveriui, kad klientas tikrai turi viešąjį raktą, kurį turėjo rasti serverio atsiųstame sertifikate.

Tada klientas nusiunčia ChangeCipherSpec pranešimą, kuris jau nėra handshake pranešimas: jis turi jau savą įrašo tipą, tad išsiunčiamas jau savo atskirame įraše. Jo turinys grynai simbolinis – vienas baitas, kurio reikšmė yra 1. Šis pranešimas žymi laiko momentą, nuo kurio klientas persijungia į naują. Pabaigos (Finished) pranešimas yra kriptografinė kontrolinė suma, apskaičiuota iš visų ankstesnių handshake pranešimų (tiek kliento, tiek serverio). Kadangi jis išsiunčiamas po ChangeCipherSpec, jis taip pat apimamas vientisumo patikrinimo ir šifravimo. Kai serveris gauna pranešimą ir patikrina jo turinį, jis įsitikina, kad visa laiką kalbėjosi su tuo pačiu klientu. Šis pranešimas apsaugo handshake nuo pakeitimų (kenkėjas negali modifikuoti handshake pranešimų ir vistiek gauti teisingą pabaigos (Finished) pranešimą). Galiausia serveris atsako su savo paties ChangeCipherSpec ir tada Finished. Dabar jau handshake baigtas. Klientas ir serveris gali keistis šifruojamais programos duomenimis. Prisiminti: visad klientas siųlo, o sprendimą priima serveris. Šifravimo algoritmų rinkinys (Cipher suite) yra serverio rankose. Mandagūs serveriai linkę atsižvelgti į kliento poreikius (jei galima), bet jie gali elgtis ir kitaip. Kai kurie taip ir daro, pavyzdžiui, siekiant apsisaugoti nuo BEAST atakos.

Sutrumpintas handshake

Pilname handshake serveris išsiunčia klientui sesijos identifikatorių (iki 32 baitų). Paskui klientas gali grįžt atgal ir išsiųsti tokį patį sesijos ID savo ClientHello pranešime. Tai reiškia, kad nuo ankstesnio handshake klientas vis dar prisimena susitarimus dėl naudojamo šifravimo algoritmų rinkinio ir raktus, bei norėtų naudoti šiuos parametrus dar kartą. Jeigu serveris taip pat visdar prisimena naudotą šifravimo algoritmų rinkinį ir raktus, tai jis nukopijuoja kliento atsiųstą sesijos ID į ServerHello pranešimą ir tada vyksta sutrumpinto handshake procedūra [11]:

Sutrumpintas handshake yra trumpesnis: mažiau pranešimų, nėra asimetrinės kriptografijos nutarimo reikalų ir, svarbiausia, tai vyksta trumpiau. Web naršyklės ir serveriai tai daro dažnai. Tipinė web naršyklė atidaro SSL susijungimą naudodama pilną handshake, o tada visiems kitiems susijungimams su tuo pat serveriu daro sutrumpintus handshake: visi kiti susijungimai atidaromi nuosekliai ir vyksta lygiagrečiai. Tipinė naršyklė uždaro susijungimus po 15 sekundžių neaktyvumo, bet prisimena sesijas (cipher suite ir raktus) daug ilgiau (galbūt kažkiek valandų ar netgi dienų).

Apsikeitimas raktais

Yra keletas apsikeitimo raktais algoritmų, kuriuos gali naudoti SSL. Tai nurodo šifravimų algoritmų rinkinys (cipher suite); kiekvienas apsikeitimo raktais algoritmas su kelių tipų serverio viešaisiais raktais. Populiariausi apsikeitimo raktais algoritmai:

• RSA: serverio raktas yra RSA tipo. Klientas sugeneruoja atsitiktinę reikšmę (vadinamą „pre-master secret“, kurią sudaro 48 baitai, iš kurių 46 yra atsitiktiniai) ir šifruoja tai serverio viešuoju raktu. Čia nėra „ServerKeyExchange“.

• DHE_RSA: serverio raktas yra RSA tipo, bet naudojamas tiktais parašui. Apsikeitimas aktualiu raktu vyksta naudojant Diffie-Hellman. Serveris išsiunčia ServerKeyExchange pranešimą, kuriame yra DH parametrai (liekana, generatorius) ir naujai sugeneruotas DH viešasis raktas, be to, serveris pasirašo šį pranešimą. Klientas atsako ClientKeyExchange pranešimu, kuriame taip pat yra naujai sugeneruotas DH viešasis raktas. DH duoda „pre-master secret“.

• DHE_DSS: kaip ir DHE_RSA, bet serveris turi DSS raktą („DSS“ taip pat žinomas kaip „DSA“). DSS yra toks algoritmas, kuris naudoja tik parašą (signature-only).

Keletas rečiau naudojamų apsikeitimo raktais algoritmų:

• DH: serverio rakto tipas yra Diffie-Hellman (kalbame apie sertifikatą, kuris turi DH raktą). Jis yra dažnai naudojamas administracinėje veikloje (JAV federalinė vyriausybė įgaliojo jo naudojimą) kai RSA patentas buvo vis dar galiojantis (tai buvo praeitame amžiuje). Nepaisant biurokratinio spaudimo, jis niekada nebuvo taip plačiai taikomas kaip RSA.

• DH_anon: kaip ir DHE rinkiniai, bet be parašo iš serverio. Šis šifravimo algoritmų rinkinys (cipher suite) priskiriamas certificate-less (be-sertifikatų) grupei. Dėl savo sandaros yra pažeidžiamas Man-in-the-Middle atakos, todėl iš viso labai retai naudojamas.

• PSK: pre-shared key šifravimo algoritmų rinkinys. Apsikeičiama tik simetriniais raktais, sudarius „pre-established shared secret“.

• SRP: šis protokolas yra taikomas „Password Authenticated Key Exchange“ protokole. Klientas ir serveris autentikuojasi vienas su kitu, naudodami „shared secret“, kuri gali būti žemos entropijos (low-entropy) slaptažodis (kuomet PSK reikalauja aukštos entropijos „shared secret“). Labai patogus, bet visdar nėra plačiai palaikomas.

• Įvairūs DH* algoritmų variantai su elipsės kreivėmis (elliptic curves). Turėtų tapti plačiai naudojama ateityje.

Pakartotinis „handshake“

Kadangi handshake yra tik keletas pranešimų, kurie yra išsiunčiami kaip įrašai su dabartiniais šifravimo/suspaudimo susitarimais, niekas klientui ir serveriui netrukdo padaryti dar vieno handshake jau esančiame SSL susijungime. Ir iš tikrųjų tai yra palaikoma ir nutinka praktikoje. Bet kuriuo metu klientas arba serveris gali pradėti naują handshake (serveris gali nusiųsti HelloRequest pranešimą, kad jį pradėtų, arba tiesiog klientas vėl nusiųsti ClientHello). Tipinė situacija gali būti tokia [2]: • HTTPS serveris yra sukonfigūruotas taip, kad klausytųsi SSL užklausų • Klientas prisijungia ir atlieka handshake procedūrą • Kai handshake jau atliktas, klientas nusiunčia savo taikomuosius duomenis, t.y. HTTP užklausą. Tuomet (ir tik tuomet) serveris įsimena galutinį kelią. Iki tol, URL, kurį klientas norėjo pasiekti buvo nežinomas serveriui (serveris gali būti supažindinamas su tuo vardu, kuriuo buvo kreiptasi, per „Server Name Indication“ SSL plėtinį, bet čia kelias nenurodomas) • Po to, kai serveris pamato kelią, jis gali jį įsiminti, kad klientas nori dalies duomenų iš tos vietos, kuri turėtų būti prieinama tik klientams, kurie autentikavosi su sertifikatais. Bet handshake procedūros metu serveris nepaprašė iš kliento sertifikato (ypatingai nes ne tokios senos web naršyklės rodo nervinančius iššokančius langus, kai prašoma sertifikato, ypač jei jie jo neturi, taigi, serveris turėtų susilaikyti ir neprašyti sertifikato, jei nėra priežasties, kodėl būtina būti įsitikinusiu, kad klientas jį turi ir žino kaip juo naudotis) • Todėl serveris pradeda naują handshake, tik šį kartą prašo sertifikato.

Įspėjimo pranešimai

Įspėjimo pranešimai – tai tiesiog įspėjimai ar klaidų pranešimai. Jie įprastai nieko nedomina, išskyrus kai jie gali būti iškraipyti kai kurių atakų (žr. toliau). Yra svarbus įspėjimo pranešimas, kuris vadinasi close_notify: tai pranešimas, kurį išsiunčia klientas ar serveris, kai nori užbaigti ryšį. Po to, kai šis pranešimas yra gaunamas, serveris ar klientas taip pat turi atsakyti close_notify pranešimu ir svarstyti apie tunelio uždarymą (bet sesija visdar galioja ir gali būti panaudota dar kartą neužilgo būsenčiame sutrumpintame handshake). Įdomu, kad šie perspėjimo pranešimai, kaip ir kiti įrašai, yra apsaugoti šifravimu ir MAC. Taigi, net tvarkingas ryšio užbaigimas taip pat slepiamas kriptografiškai. Tai yra svarbu (senojo) HTTP protokolo kontekste, kur serveris gali perduoti kažkiek duomenų be nurodyto „content-length“: duomenys siunčiami iki transporto srauto pabaigos. Senasis HTTP su SSLv2 (kuris neturėjo close_notify) leido kenkėjui priverstinai uždaryti susijungimą (TCP lygmenyje), ką klientas gali suprasti kaip normalų ryšio užbaigimą, o kenkėjas galėjo sutrumpinti duomenis ir likti nepastebėtas. Tai vienas iš SSLv2 trūkumų (galbūt net blogiausių) ir SSLv3 tai ištaisė. Reikėtų atkreipti dėmesį, kad šiuolaikinis HTTP nurodo "Content-Length" antraštėje ar/ir perdavimą gabalais (chunked encoding), kas nėra pažeidžiama tokio sutrumpinimo, netgi jei SSL lygmuo tai ir leidžia.

Kaip nulaužti SSL

Trumpai: • Tiesiog žiūrėti nešifruotus duomenis, jei vartotojas ignoruos perspėjimus apie sertifikatus • Programa gali krauti duomenis per nešifruotą kanalą (pvz. http), kuo galima pasinaudoti • Neapsaugotas prisijungimo puslapis, kuris nukreipia į HTTPS gali būti modifikuotas taip, kad nukreiptų į HTTP • Neatnaujintos (Unpatched) programos gali būti pažeidžiamos eksploitais, tokiais kaip BEAST ar CRIME; • Pasinaudoti kitais metodais, pavyzdžiui, fizine ataka.

5 pav. SSL nulaužimo modelis

Detaliau: Nėra paprasto visiems atvėjams tinkamo būdo; SSL yra saugus, kai naudojamas teisingai. Jei vartotojas mėgsta ignoruoti perspėjimus apie sertifikatus, tai to įsilaužėlis gali mielai pasinaudoti. Tokiu atveju įsilaužėliui netgi nereikia privataus rakto iš CA ir klastoti sertifikato. Jis tiesiog gali nusiųsti kažkokį betkokį sertifikatą, kuriuo naršyklė net ir nepasitikėtų – toks vartotojas tai ignoruos ir ryšys bus nesaugus – įsilaužėlis laisvai galės klausytis. Kitas būdas gali būti pasinaudojant saugumo problemos programinėje įrangoje (tiek serverio, tiek kliento pusėje). Paprastas pavyzdys tinklapiuose: jei vienas iš resursų, kuriuos naudoja tinklapis (pavyzdžiui paveiksliukas ar skriptas) yra kraunamas per HTTP, konfidencialumas nebegali būti garantuotas. Netgi jei naršyklės nesiunčia HTTP užklausos antraštėje „Referer“ eilutės, kurioje nurodoma iš kur kreipiamasi, kai kreipiamasi iš saugaus puslapio į nesaugų, vistiek kasnors gali klausytis srauto ir bandyti atspėti iš kur vartotojas kreipiasi; pavyzdžiui, jei jie žino paveiksliukus X, Y ir Z, kurie naudojami tinklapyje, jie gali atspėti iš kokio puslapio vartotojas kreipiasi, kadangi tik iš to puslapio sukuriamos užklausos į visus tris paveiksliukus iškarto. Papildomai, kai kraunamas JavaScript, visas puslapis gali būti pavojuje. Įsilaužėlis gali įvykdyti betkurį skriptą puslapyje taip, kad pakeistų asmenį, kuriam nukeliaus banko pavedimas. Kai tai nutinka (resursas užkraunamas per HTTP), naršyklė duoda perspėjimą (6 pav, 7 pav).

6 pav. Firefox naršyklės rodomas pranešimas, kai resursas užkraunamas per HTTP iš HTTPS tinklapio

7 pav. IE 9 naršyklės rodomas pranešimas, kai resursas užkraunamas per HTTP iš HTTPS tinklapio

Kitas triukas su HTTP gali būti panaudotas tada, kai prisijungimo puslapis yra neapsaugotas ir įvedus prisijungimo duomenis ir nuspaudus prisijungimo mygtuką (submit) nukreipiama į HTTPS puslapį. „Puiku,“ kūrėjas galbūt pagalvos, „dabar aš sumažinau serverio apkrovimą, o slaptažodžiai vistiek siunčiami šifruoti!“. Tačiau yra toks įrankis „sslstrip“, kuris modifikuoja nesaugų prisijungimo puslapį taip, kad jis paspaudus prisijungimo mygtuką duomenis nusiųstų kažkur kitur kur įsilaužėlis juos galėtų perskaityti. Per pastaruosius keletą metų buvo įvairių atakų, pavyzdžiui, „TLS renegotiation vulnerability“, „sslsniff“, BEAST, CRIME. Naujausios naršyklės yra apsaugotos nuo visų šių atakų, tad šioms atakoms rizikos nėra, jei naudojama naujausia naršyklės versija. Galiausia galima imtis ir kitų metodų, kad gauti informaciją, kurią SSL slepia nuo pašalinių. Galima pakeisti jo/jos .exe parsisiuntimus į keylogerį arba paprasčiausia fiziškai atakuti tą žmogų. Kriptografija gali būti pakankamai saugi, tačiau žmonės ir jų daromos klaidos visdar yra silpnoji vieta. Reminatis [12], 10% saugimo pažeidimų atliekama pasinaudojant fizinėmis atakomis, tad tai verta turėti omenyje.

SSL Atakos

Buvo daug įvairių SSL atakų. Dalis iš jų remiasi taikymo klaidom, o kitos – tikrais protokolo trūkumais. Kiekvienas privalo prisiminti, kad SSL yra vienas iš labiausia atakuojamų protokolų (nes labai plačiai taikomas), SSL taip pat yra vienas iš daugiausia taisytų protokolų. Jis laikomas labai patikimu, todėl visos žinomos transporto lygmens protokolų atakos buvo išbandytos ir per SSL ir SSL buvo taisyta kur tik prireikė.

Versijos gražinimas („Version Rollback“)

Kai tik atsirado SSLv3, SSLv2 buvo plačiai naudojamas ir todėl klientai įprastai siųsdavo su SSLv2 suderinamus ClientHello pranešimus, kuriose galėjo būti nurodyta, kad palaikoma ir SSLv3. Remiantis tuo, serveris galėjo atsakyti SSLv3+ pranešimu (išsamiau „annexe E“ iš „RFC 2246“). Kadangi SSLv2 turėjo daug trūkumų, kenkėjai buvo suinteresuoti, kad nors ir klientas, ir serveris palaiko SSLv3, jie vistiek bendrautų naudodami SSLv2. Tai vadinama „version rollback“ ataka. Koncepcija formaliai išliko ir vėlesnėse versijose. Buvo atlikti pataisymai (workarounds), kad aptikti „rollback“ bandymus. Jei norima pereiti prie SSLv2, klientas, suprantantis SSLv3+, turėjo įterpti specialius lygiavimo (padding) baitus RSA šifravimo žingsnyje (SSLv2 palaiko tiktais RSA naudojančių raktų apsikeitimą): PKCS#1 žingsnyje, duomenys, kurie bus šifruojami, turėtų būti sulygiuoti (padding) įterpiant atsitiktinius baitus; SSLv3 palaikantis klientas paskutiniems 8-iems iš šių baitų priskiria reikšmes 0x03. Serveris patikrina šiuos baitus ir jei aštuoni 0x03 baitai gale nerasti, tai „rollback“ daryti tikriausia buvo bandyta ir serveris tokį bandyma atmeta (kad tik SSLv2 palaikantis klientas naudos tokia seką papildymo baitams (padding) tikimybė lygi tik 255e-8 , taigi, klaidingo rezultato tikimybė labai maža). Siekiant galimybės pereiti („rollback“) prie senesnės SSL/TLS versijos, tačiau ne senesnės už SSLv3, buvo sukurtas kitas pataisymas: „pre-master secret“ yra 48 baitų ilgio, kurią klientas šifruoja naudodamas serverio RSA raktą, pirmi du baitai joje nėra atsitiktiniai, bet turėtų būti lygūs „maksimaliai palaikomai protokolo versijai“, kurią klientas įrašo savo ClientHello pranešime. Dėja, yra keletas klientų, kurie šios taisyklės nesilaiko, bei šis pataisymas veikia tik su apsikeitimu raktais (key exchange), kai naudojamas RSA, taigi apsauga nuo „rollback“ čia yra labai ribota. Laimei SSLv3+ turi kitą, žymiai geresnę apsaugą nuo „rollback“ – handshake pranešimai yra hešuojami kartu, kai „Finished“ pranešimas yra jau sukurtas. Tai apsaugo nuo „rollback“, nebent sena versija būtų tokia nevykusi, kad kenkėjas galėtų visiškai nulaužti visą šifravimą prieš handshake pabaigą. Tai neįvyko iki šiol.

Silpni šifravimo algoritmai (cipher suites)

Keletas standartinių šifravimo algoritmų rinkinių (cipher suites) kaip nors yra silpni savaime: • Keletas šifravimo algoritmų rinkinių (cipher suites) neturi visiškai šifravimo, tik vientisumo patikrinimą. Pavyzdžiui, TLS_RSA_WITH_NULL_SHA; • Keletas šifravimo algoritmų rinkinių (cipher suites) su 40 bitų šifravimu, pavyzdžiui, TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (šifravimo algoritmų rinkiniai turėjo atitikti griežtus Amerikos (US) eksporto reikalavimus, kurie buvo nustatyti dar praeitame amžiuje – dauguma jų panaikinti Bilo Klintono (Bill Clinton) eros (1993 – 2001 m.) pabaigoje). • Keletas šifravimo algoritmų rinkinių (cipher suites), tokių kaip TLS_RSA_WITH_DES_CBC_SHA, naudoja 56 bitų šifravimą. 56 bitų DES su šiuolaikinėmis technologijomis yra nulaužiamas, bet tai vis dar truputį sudėtinga padaryti mėgėjui (netgi nuobodžiaujančiam studentui, kuris turi galimybę naudotis keliais šimtais universiteto kompiuterių), taigi, galima laikyti, kad 56 bitų DES yra vidutinio saugumo. Visa tai suteikia galimybę vykdyti „rollback“ atakų variantą, kuomet kenkėjas priverčia klientą su serveriu susitarti dėl pažeidžiamesnio šifravimo algoritmų rinkinio (cipher suite). Tam kenkėjas modifikuoja kliento siunčiamų palaikomų ir siūlomų naudoti šifravimo algoritmų rinkinių sąrašą. Tai kenkėjas gali padaryti, jei pasirinktas šifravimo algoritmų rinkinys yra toks pažeidžiamas, kad jis jį gali nulaužti tam, kad perskaičiuotų matyt teisingą „Finished“ pranešimą. Iš tiesų MAC naudojamas SSLv3+ (netgi kai naudojamas MD5) yra pakankamai patikimas, kad nuo to apsisaugoti. Taigi, dėl to nėra ko nerimauti. Be to, tikriausia, jei koks nors realus pažeidžiamumas tokiu atveju ir būtų, tai kai klientas ar serveris iš vis sutinka susitarti dėl silpnų šifravimo algoritmų rinkinių naudojimo. Pagal nutylėjimą, šiuolaikinės Web naršyklės neleidžia naudoti tokių silpnų silpnų šifravimo algoritmų rinkinių (cipher suites)

Privataus rakto vagystė

Jei SSL susijungimo metu keičiamasi RSA raktais ir kenkėjas išsisaugo šių įrašų kopijas, tai vėliau (gal net kelis mėnesius po to, galimai, pavyzdžiui, tyrinėdamas atsargines duomenų kopijas išmestuose diskuose ar juostinėse laikmenose) gauna privataus rakto kopiją, tai jis gali atskleisti handshake ir iššifruoti duomenis [2]. Naudojant DHE šifravimo algoritmų rinkinį, tikrasis privatus raktas, kuris naudojamas handshake atskleidimui yra trumpalaikis Diffie-Hellman raktas, o ne serverio RSA (ar DSS) privatus raktas. Kadangi trumpalaikis, tai jis egzistuoja tiktais RAM atmintyje ir niekada nėra rašomas į kietąjį diską, todėl turėtų būti žymiai atsparesnis vagystei. Taigi, apibendrinant: kaip taisyklė reikėtų naudoti DHE šifravimo rinkinį kur tik įmanoma. Tačiau vis tiek reikėtų turėti omenyje duomenų aatsarginių kopijų saugojimą ir neleisti privačiam raktui patekti piktavaliui į rankas (nutekėti informacijai), DHE šią galimą rakto nutekėjimo problemą mažesne, ypač jei tai įvyksta rakto galiojimo laiko pabaigoje (t.y. atitinkamas sertifikatas kai jau nustoja galioti).

Sertifikatų bėdos

Sertifikatų naudojimas – SSL pagrindas. Techniškai SSL yra pakankamai nepriklausomas nuo X.509. Kai apsikeičiama sertifikatais, kažkuriuo metu klientas jau privalo naudoti serverio viešąjį raktą, ir laisvai gali būti įsitikinęs, kad raktas tikras. Yra specifinių atveju, kai SSL naudojamas ir klientas iš anksto žino serverio viešąjį raktą (jis nurodytas programos kode, angl. hardcoded) ir atsiųstą sertifikatą tiesiog ignoruoja. Nepaisant to, bendruoju HTTPS atveju, klientas daro serverio siunčiamo sertifikato patikrinimą, kaip kad rašoma X.509. Čia galimos įvairios atakos, pavyzdžiui: • Patikrinimo metu paaiškėja, kad sertifikatas visdar galioja. Kaip kliento kompiuteris žino dabartinę datą? Pagal jo vidinį laikrodį, o gal sužino iš NTP serverių (pakankamai neapsaugotu būdu!). Klientas gali būti išjungtas keliom minutėm, valandom, dienom ar netgi keliem metam ir, tam tikru mastu, patyręs įsilažėlis gali jį išnaudoti pasukdamas laiką naudodamas NTP pranešimus. Tai leistų kenkėjui naudoti pasenusius sertifikatus, kurie galėjo būti atskleisti prieš daugelį metų. Čia galima pastebėti tokį dalyką: SSL „client random“ ir „server random“ turi būti sudaryti iš 28 atsitiktinių baitų ir vietinės datos ir laiko (4 baitai). Šis laiko įterpimas yra pataisymas (workaround) nuo laiko atakų, tačiau dažnai tai nėra tikrinama. • Iki maždaug 2003 metų sertifikatų tikrinimo realizacija Internet Explorer naršyklėje nebuvo gera. Windows OS nedirbo teisingai su „Basic Constraints“ išplėtimu. Tad bet kas su 100$ sertifikatu galėjo veikti kaip CA ir išdavinėti sertifikatus su savo nuožiūra pasirinktais pavadinimais ir raktais. • X.509 apibrėžia ir priemonę, vadinamą atšaukimu: tai yra atšauktų sertifikatų sąrašo paviešinimas, tokių, kurie, galbūt, net kriptografiškai yra geri, tačiau jais neturėtų būti pasitikima (pvz. dėl to, kad pavogtas privatus raktas arba jie klaidingai pavadinti). Atšaukimas vyksta tik kuomet susijusios šalys (pvz. naršyklės) sutinka atsisiųsti didelius atšaukimų sarašus, kurie gali užimti net kelis megabaitus, arba prisijungti prie OCSP serverių. Šiuolaikinės naršyklės tai daro, tačiau truputį nenoriai, ir dauguma sutiks prisijungti vistiek, jei ir negaus atšaukimo būsenos informacijos per tam tikrą laiką (kadangi žmogus laukia nekantriai). Ši situacija vis gerėja, tačiau pakankamai lėtai. • Keletas root CA yra padarę praeityje keletą klaidų (pvz. „Comodo“ ir „DigiNotar“). To pasėkmė – suklastotų sertifikatų išdavimas (vardas www.microsoft.com, bet privatus raktas yra visiškai ne Microsoft kompanijos). Šios klaidos buvo pastebėtos ir sertifikatai atšaukti, bet tai visdar iškelia nepatogių klausimų (pvz., ar yra kitų CA, kurios turėjo panašių problemų, tačiau tai nutylėjo, o gal buvo ir dar blogiau – jos to net nepastebėjo?) X.509 yra labai sudėtingas algoritmų, technologijų, specifikacijų ir komitetų rinkinys ir tai labai sudėtinga yra teisingai suprasti. Bandymai dekoduoti X.509 sertifikatus „rankiniu būdu“ neapsaugotoje (unprotected) programavimo kalboje, tokioje kaip C, yra lengvas būdas gauti buferio perpildymą.

Bleichenbacher atakos

1998 metais Daniel Bleichenbacher sugalvojo įdomią ataką prieš RSA. Kai gabaliukas duomenų užšifruojamas su RSA (kaip kad daroma „ClientKeyExchange“ SSL pranešimui), duomenys, kurie bus šifruojami, privalo būti papildyti (padded), kad baitų seką padaryti tokio ilgio, kad be liekanos dalintųsi iš RSA. Užpildymas susideda daugiausia iš atsitiktinių baitų, tačiau čia galima pastebėti šiokią tokią struktūrą (verta atkreipti dėmesį, kad pirmieji du baitai po papildymo privalo būti 0x00, 0x02). Po dešifravimo (serveryje), užpildymo baitai (padding) turi būti rasti ir pašalinti. Jei taip nutinka, kad serveris dešifruoja duomenis, tačiau randa neteisingą užpildymą (nerado užpildyme 0x00 ir 0x02 baitų), tai jis, naudodamas „alert“ tipo pranešimą, perspėja (kaip nurodyta SSL specifikacijoje), o jeigu serveris gavo duomenis su teisingu užpildymu, tai tęsia handshake procedūrą. Tai yra žinoma kaip užpildymo pranašavimas(a padding oracle). Tai leidžia piktavaliui išsiųsti tam tikrą baitų seką, lyg tai būtų užšifruota „pre-master secret“ ir žinoti, ar šios sekos dešifravimo rezultatas turės teisingą užpildymą, ar ne. Nors tai būtų tik vienas bitas informacijos, tačiau to pakanka, kad išgauti privatų raktą sugeneravus kelis milijonus užklausų su gudriai „užšifruotomis“ simbolių eilutėmis. Pataisymas (Workaround): kai po dešifravimo gaunami klaidingi užpildymo baitai, serveris toliau naudoja atsitiktinę „pre-master secret“. Handshake tuomet bus laikomas nesėkmingu ir užbaigtas „Finished“ pranešimais. Taip daro visos dabartinės SSL realizacijos.

BEAST ataka

BEAST ataka yra sukurta mokslininkų T. Duong ir J. Rizzo ir tai yra yra patobulinta Philip Rogaway 2002 m. sukurtos atakos versija. Kad pagauti mintį, imkime CBC (Cipher Block Chaining). Šiame darbo režime, kiekvienam duomenų blokui pirmiausia yra pritaikoma išskirtinio ARBA (XOR) operacija su ankstesnio bloko šifravimo rezultatu ir tada gautas rezultatas užšifruojamas. Tai yra daroma tam, kad išvengti nutekėjimų, kurie pasitaiko ECB (Electronic Code Book) režime. Kadangi pirmasis blokas neturi ankstesnio bloko informacijos, tai būtinas initializacijos vektorius, kuris naudojamas pirmajam blokui vietoje ankstesniojo. Paaiškėja, kad jei kenkėjas gali valdyti dalį duomenų, kurie bus šifruojami ir taip pat gali nuspėti initializacijos vektorių (IV), kuris bus naudojamas. Tuomet jis gali išnaudoti šifruojantį kompiuterį tam, kad išgautų truputį kitų duomenų (pats piktavalis negali pasirinkti, kokių). Tačiau, kai naudojamos SSLv3 ir TLS 1.0 versijos, piktavalis gali nuspėti įrašo IV: tai ankstesnio įrašo vėliausias blokas! Taigi, kenkėjas privalo galėti įterpti kažkiek duomenų į srautą tam, kad perstumtų tuos duomenis, į kuriuos kesinasi į tą vietą, kur realizacija sukuria ir išsiunčia ankstesnį įrašą (įprastai tuomet, kai būna susikaupę 16kB duomenų), bet dar nepradėjo kurti sekančio. TLS 1.1+ yra nuo to apsaugotas, nes TLS 1.1 (ir vėlesnės versijos) kiekvienam įrašui naudoja atsitiktinį IV. SSLv3 ir TLS 1.0 šią problemą galima apeiti (workaround) siunčiant nulinio ilgio įrašus, t.y. tokius, kurių naudingieji duomenys (payload) yra nulis, tačiau naudojamas MAC, papildymas ir šifravimas, bei MAC yra skaičiuojamas slaptuoju raktu ir remiantis sekos numeriu, kas atlieka atsitiktinių skaičių generatoriaus vaidmenį. Unfortunately, IE 6.0 nesupranta nulinio ilgio įrašų. Kitos strategijos remiasi 1/n-1 skaidymu (n baitų ilgio įrašas yra siunčiamas kaip du: vieną sudaro vienas naudingų duomenų baitas, o kitą – likę n-1 naudingieji baitai). Kitas būdas apeiti problemą – visuomet versti naudoti ne-CBC režimo šifravimo algoritmų rinkinį (cipher suite), kai tik galima – serveris pasirenka tokį, kuris veikia RC4 pagrindu, jei toks yra kliento siūlomų šifravimo algoritmų rinkinių sąraše ir net tuomet, jei klientas labiau norėtų naudoti veikiantį CBC pagrindu. Trumpai tariant, BEAST yra kliento pusės ataka, tačiau, pasirinkdamas RC4 tipo pagrindu veikiantį šifravimo algoritmų rinkinį (cipher suite), serveris gali apsaugoti nerūpestingą klientą.

CRIME ataka

2012 m. T. Duong ir J. Rizzo publikavo savo tolimesnio darbo rezultatą. CRIME pasinaudojo (exploit) trūkumu, kuris teoriškai buvo nustatytas dar 2011 m., tačiau gyvai nebuvo pademonstruotas. CRIME išnaudoja (exploit) suspaudimą tokiu pat būdu, kaip ir BEAST ataka (piktavalis gali įterpti kažkiek savo duomenų į SSL srautą, kuomet perduodami įdomūs duomenys, pavyzdžiui, sausainis (cookie)) [2] SSL/TLS pasirinktinai palaiko duomenų suspaudimą. „ClientHello“ pranešime klientas pasirenka, kokį suspaudimo algoritmą nori naudoti ir serveris „ServerHello“ pranešime atsako, kokį jis naudos. Suspaudimo algoritmai yra nurodomi naudojant vieno baito identifikatorius, o TLS 1.2 (RFC 5246) palaiko tiktais „null“ suspaudimą, t.y. niekada nesuspaudinėja duomenų. Kai suspaudimas yra naudojamas, tai jis taikomas visiems perduodamiems duomenims, kaip vienam srautui. Pavyzdžiui, jei naudojamas su HTTPS, suspaudimas yra taikomas visoms HTTP užklausoms, įskaitant antraštę. DEFLATE veikia ieškodamas pasikartojančių baitų sekų. Tarkime, piktavalis naudoja JavaScript kodą tam, kad norimas užklausas į jį dominantį tinklapį (pvz, banką) ir veikia užkrėstame kompiuteryje. Naršyklė išsiųs šias užklausas su to banko vartotojo sausainiu – kenkėjo sausainio reikšmė įrašoma žemiau. Taip pat tarkime, kad piktavalis gali stebėti srautą tarp vartotojo kompiuterio ir banko (pavyzdžiui, piktavalis turi priėjimą prie to paties LAN ar Wi-Fi prieigos taško, kaip ir auka arba jis užgrobė kokį nors maršrutizatorių, esantį kelyje, labiau tikėtina prie banko serverio). Šiam pavyzdžiui laikykime, kad kiekvienoje HTTP užklausoje esantis sausainis atrodo taip: Cookie: secret=7xc89f+94/wa Kenkėjas žino tik pradžią: Cookie: secret= dalį ir nori sužinoti reikšmę. Todėl jis savo JavaScript kode sudaro užklausą, kurioje yra įtašas Cookie: secret=0. Tokiu atveju HTTP užklausa atrodo taip:

POST / HTTP/1.1 
Host: thebankserver.com 
(...) 
Cookie: secret=7xc89f+94/wa 
(...)
Cookie: secret=0

Kai DEFLATE tai pamato, jis atpažįsta pasikartojančią seką Cookie: secret= ir saugo sekančią eilutę labai trumpa reikšme (token), kuri sako, kad „ankstesnės sekos ilgis buvo 15 ir ji buvo n baitų prieš tai“. DEFLATE turės sukurti atskirą reikšmę (token) simboliui „0“. Užklausa nukeliauja į serverį. Iš šono piktavalis mato, kad klientas keičiasi duomenim su banko serveriu (duomenys šifruoti), tačiau jis gali matyti duomenų ilgį (baitų tikslumu, jei naudojamas RC4, jei CBC yra kažkoks užpildymas, bet piktavalis gali turinio ilgį pakeisti iki tokio, kad sutaptų su blokų ribom; taigi, praktiškai kenkėjas gali žinoti suspaustos užklausos ilgį).

Dabar piktavalis pabando dar kartą, su Cookie: secret=1 užklausoje. Tada su Cookie: secret=2 ir t.t. Visos šios užklausos susispaus iki tokio paties ilgio (bet nevisad, nes yra Huffman kodavimo, kurį naudoja DEFLATE, subtilybės), išskyrus vieną, kuri yra Cookie: secret=7 , kuri susispaus geriau (16 baitų ilgio pasikartojanti seka vietoje 15 baitų) ir todėl bus trumpesnė. Piktavalis tai mato. Taigi, su keliomis dešimtimis užklausų piktavalis sužinojo pirmą slaptą jam reikiamą baitą. Toliau jam tereikia kartoti šį procesą (Cookie: secret=70, Cookie: secret=71 , ir t.t.) ir taip gauti baitą po baito visą sausainio reikšmę („secret“ reikšmę) [13]. Taigi, dėl to naršyklės nustojo palaikyti SSL/TLS suspaudimą ir TLS 1.2 jo nebepalaiko.

POODLE (Padding Oracle On Downgraded Legacy Encryption) ataka

Publikuota 2014 m. spalio 14 d. Šiai atakai pažeidžiama tik SSL 3.0 versija. Tai protokolo trūkumas, o ne jo taikymo. Visaip taikant šis pažeidžiamumas išlieka. Verta pabrėžti, kad visos TLS versijos yra atsparios šiai atakai, net TLS 1.0). Ši ataka išnaudoja tik SSL 3.0 versijoje esantį trūkumą, kai naudojami CBC tipo šifravimo algoritmų rinkiniai (cipher suites) Trumpai tariant: kai SSL 3.0 naudoja blokinį šifravimą CBC režime, šifravimo metu kiekvienam įrašui naudojamas papildymas (padding), kad duomenų ilgis dalintųsi iš bloko dydžio. Pavyzdžiui, jei naudojamas 3DES, tai blokas yra 8 baitų ilgio. MAC yra apskaičiuojamas pagal įrašo duomenis (ir įrašo sekos numerį, ir kitus antraštės duomenis) ir pridedamas prie duomenų. Tada nuo 1 iki 8 baitų yra pridedama papildomai, kad įrašo ilgis dalintųsi iš 8. Be to, jei n baitų yra pridėta šiame žingsnyje, tai paskutiniai baitai turi turėti reikšmę n-1. Taip turi būti, kad būtų galima dešifruoti. Aptarkim dešifravimą tokio įrašo: jam pritaikytas 3DES-CBC šifravimas, tada paskutinis baitas patikrintas: jis turėtų turėti reikšmę nuo 0 iki 7 ir tai mums pasako, kiek dar baitų yra pridėta papildomai (padding). Šie baitai numetami ir, svarbiausia, jų turinys ignoruojamas. Tai svarbiausia: tai yra įrašo baitai, kuriuos galima pakeisti ir gavėjas to visiškai nepastebės. Poodle ataka veikia pasirinktino atviro teksto (chosen-plaintext) kontekste, kaip ir BEAST ir CRIME, atrastos prieš šią. Piktavalį domina informacija, kuri bus apsaugota naudojant SSL ir jis gali: • Įterpti savo duomenis prieš ir po slaptos reikšmės, kurią jis nori sužinoti; • įsiterpti, tyrinėti ir modifikuoti laidu perduodamus baitus. Pagrindinis ir labiausia tikėtinas dalykas, kur šios sąlygos tenkinamos – Web kontekstas: piktavalis naudoja suklastotą WiFi prieigos tašką (access point) ir įterpia truputį JavaScript į tinklapį (HTTP, o ne HTTPS), kuriame naršo auka. Nelaimingas JavaScript padaro, kad naršyklė siųstų užklausas HTTPS tinklapiui (pavyzdžiui, tarkime, banko tinklapiui), kuriam aukos naršyklė turi sausainį. Šio sausainio nori piktavalis. Ataka tai atlieka baitas po baito. Kenkėjo JavaScript kodas užklausą išdėsto taip, kad vėliausias sausainio baitas yra paskutiniame šifruoto bloko baite (vienas iš 8 baitų ilgio blokų 3DES atveju) ir taip, kad visas užklausos ilgis sutampas su pilnu bloko užpildymu. Tarkime, kad paskutiniai 8 sausainio baitai turi reikšmes c0, c1, ..., c7. Tuomet CBC veiks taip (8 pav.):

8 pav. CBC užšifravimas

Taigi, jei praeitas šifruotas blokas buvo e0, e1, ..., e7, tai 3DES pasiekia toks rezultatas: c0 XOR e0, c1 XOR e1, ..., c7 XOR e7. ei reikšmės kenkėjui yra žinomos (nes tai yra šifravimo rezultatas). Tuomet piktavalis iš išorės pakeičia šifruoto įrašo paskutinį bloką į kopiją to, kuris turi paskutinį sausainio baitą. Kad suprasti kaip tai vyksta reikia suprasti, kaip veikia CBC dešifravimas (9 pav):

9 pav. CBC dešifravimas

Paskutiniai šifruoto teksto (ciphertext) bloko baitai, kai yra dešifruojami, gaunamos reikšmės, kurios baigiasi su c7 XOR e7. Šiai reikšmei tuomet atliekama XOR operacija su ankstesniu šifruotu bloku. Jei rezultatas baigiasi baitu, kurio reikšmė yra 7 (tai veikia su tikimybe maždaug 1/256), tai tada papildymo baitų pašalinimo žingsnyje visi paskutiniai 8 papildymo baitai yra pašalinami ir lieka atviras tekstas (clear text) su MAC, kas yra reikalinga serveriui. Kitaip, jei paskutinis baitas bus ne 0..7 intervale, tai serveris ims nerimauti, ar jei paskutinio baito reikšmė bus tarp 0 ir 6 , tai serveris numes netinkamą baitų kiekį ir tuomet MAC nesutaps ir dėl to serveris ims nerimauti. Kitaip tariant, kenkėjas gali stebėti serverio reakciją ir suprasti, ar CBC dešifravimo rezultate gale buvo rasta 7, ar kas nors kita. Kai gaunama 7, tai paskutinis sausainio baitas iš karto atskleidžiamas. Kai paskutinis sausainio baitas atskleidžiamas, tai procesas kartojamas iš naujo su prieš tai esančiu baitu ir t.t. Esme: SSL 3.0 užpildymo baitus ignoruoja (išskyrus paskutinį). Šie baitai neįeina į MAC ir neturi jokios reikšmės. TLS 1.0 nėra pažeidžiamas, nes TLS 1.0 specifikacijoje yra nurodyta, kad visi užpildymo baitai turi turėti vienodą reikšmę ir bibliotekos, kuriose realizuojamas TLS, užtikrina, kad šie baitai turi tokias reikšmes, kurių tikimąsi. Taigi, kenkėjas jau nebeturi tikimybės 1/256, o tiktais 1/18446744073709551616 (2e-64), kas yra jam daug daug blogiau. [16]

Protokole SSLv3 aptikta saugumo spraga – kliento serverio komunikacijoje, naudojant SSLv3 su blokiniais šifravimo algoritmais, įsilaužėliui atsiranda galimybė surengti „Man in the middle“ ataką ir tokiu būdų iššifruoti koduotą susijungimą. Šiuo metu yra rekomenduojami trys problemos sprendimo būdai:

1. Nenaudoti SSLv3 protokolo serveriuose. Vietoje jo naudoti TLS.

2. Nenaudoti SSLv3 blokinių šifravimo algoritmų. Tokiu atveju lieka vienintelis pasirinkimas – RC4 algoritmas.

3. Atnaujinti SSLv3 serverių programinę įrangą, kad palaikytų SCSV protokolą. Tokiu atveju, prie šių serverių jungiantis klientams, kurių programinė įranga taip pat palaiko SCSV protokolą, susijungimas neturės šios saugumo spragos. Tačiau jungiantis klientams, kurie šio protokolo nepalaiko, „man in the middle“ ataka vis tiek bus įmanoma. [15].

Literatūra

1. TLS. Wikipedia The Free Encyclopedia [interaktyvus]. 2014. Wikipedia portalo straipsnių rašytojai [žiūrėta 2014 m. lapkričio 16 d.]. Prieiga per internetą: http://en.wikipedia.org/wiki/Transport_Layer_Security

2. How does SSL and TLS work? Stack exchange. Information Security [interaktyvus]. 2014. Thomas Pornin [žiūrėta 2014 m. lapkričio 16 d.]. Prieiga per internetą: http://security.stackexchange.com/questions/20803/how-does-ssl-tls-work

3. RFC2818. HTTP over TLS [interaktyvus]. 2014. Request For Comments [žiūrėta 2014 m. lapkričio 16 d.]. Prieiga per internetą: http://tools.ietf.org/html/rfc2818

4. SSL vs. TLS. What is the difference [interaktyvus]. 2014. Dr. Erik Kangas [žiūrėta 2014 m. lapkričio 16 d.]. Prieiga per internetą: https://luxsci.com/blog/ssl-versus-tls-whats-the-difference.html

5. POODLE. Wikipedia The Free Encyclopedia [interaktyvus]. 2014. Wikipedia portalo straipsnių rašytojai [žiūrėta 2014 m. lapkričio 16 d.]. Prieiga per internetą: http://en.wikipedia.org/wiki/POODLE

6. X.509. Wikipedia The Free Encyclopedia [interaktyvus]. 2014. Wikipedia portalo straipsnių rašytojai [žiūrėta 2014 m. lapkričio 16 d.]. Prieiga per internetą: http://en.wikipedia.org/wiki/X.509

7. RFC5280. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile [interaktyvus]. 2014. Request For Comments [žiūrėta 2014 m. lapkričio 16 d.]. Prieiga per internetą: https://tools.ietf.org/html/rfc5280 8. NSS tech note3 [interaktyvus] 2002. Kwilson, Sheppy [žiūrėta 2014 m. lapkričio 16 d.]. Prieiga per internetą: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/nss_tech_notes/nss_tech_note3

9. Polk, Tim; McKay, Terry; Chokhani, Santosh (April 2014). "Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations". National Institute of Standards and Technology. p. 67. Retrieved 2014-05-07.

10. How SSL and TLS works. 2012. PC Plus Issue 315. Prieiga per internetą: http://www.techradar.com/news/software/how-ssl-and-tls-works-1047412

11. RFC2246. The TLS Protocol version 1.0 [interaktyvus]. 1999. Request For Comments [žiūrėta 2014 m. lapkričio 16 d.]. Prieiga per internetą: https://tools.ietf.org/html/rfc2246

12. 2012 Data Breach Investigations Report. 2012. Prieiga per internetą: http://www.verizonenterprise.com/resources/reports/rp_data-breach-investigations-report-2012_en_xg.pdf

13. How does SSL and TLS work? Stack exchange. Information Security [interaktyvus]. 2012. Thomas Pornin [žiūrėta 2014 m. lapkričio 16 d.]. Prieiga per internetą: http://security.stackexchange.com/questions/19911/crime-how-to-beat-the-beast-successor

14. POODLE attack on SSL 3.0. Imperial Violet. 2014 [interaktyvus]. Prieiga per internetą: .https://www.imperialviolet.org/2014/10/14/poodle.html

15. Proservis. 2014. Prieiga per internetą: http://www.proservis.eu/poodle-sslv3-saugumo-spraga

16. SSL3 POODLE vulnerability. Stack exchange. 2014. [interaktyvus]. Prieiga per internetą: http://security.stackexchange.com/questions/70719/ssl3-poodle-vulnerability/70724#70724

CategoryŽodis