From Wikipedia, the free encyclopedia
Transporta slāņa drošība[1] jeb TLS (no angļu: Transport Layer Security) ir šifrēšanas protokols, kuru izmanto lai šifrētu datortīklos (piem., Internetā) pārsūtīto informāciju. Visredzamākais pielietojums ir HTTP datu plūsmas šifrēšana lietojot https protokolu. Pirmās šī protokola versijas izstrādāja Netscape un to sauca par SSL (Secure Sockets Layer), un tas nebija IETF standarts. Pēc SSL 3, tālākās versijas izstrādāja IETF un tās ir TLS. Pašreizējais standarts ir TLS, taču SSL bija ticis plaši reklamēts un joprojām ir plaši atpazīstams (plašāk nekā TLS). Mūsdienās joprojām plaši lieto SSL 3 versiju (vecākas pārlūkprogrammas darbojas arī ar nedrošo SSL 2 versiju).
Šim rakstam ir nepieciešamas atsauces uz ārējiem avotiem. Lūdzu, palīdzi uzlabot šo rakstu, pievienojot vismaz vienu atsauci. Diskusijā var parādīties dažādi ieteikumi. Vairāk lasi lietošanas pamācībā. Meklēt atsauces: "Transporta slāņa drošība" – ziņas · grāmatas · scholar · brīvi attēli |
TLS tīkla programmām nodrošina iespēju sazināties savā starpā veidā, kas novērš informācijas pārtveršanu un izmainīšanu. TLS nodrošina savienojuma gala ierīču autentifikāciju un šifrē pārsūtītos datus. TLS parasti lieto RSA asimetrisko šifrēšanas algoritmu ar 1024 vai 2048 bitu atslēgām. Visplašāk lietotajā gadījumā ar https (un lielākoties arī ar SMTP un IMAP caur TLS) TLS autentifikācija ir vienā virzienā, te autentificē tikai serveri (klients pārliecinās par servera identitāti), bet ne klientu (tas saglabājas neautentificēts). Ir iespējama arī divu virzienu autentifikācija, kad autentificē arī klientu. Tā ir drošāka, bet ķēpīgāka (katram klientam vajag tāda paša veida sertifikātu kā serverim). Sertifikātus ar atslēgu informāciju TLS parasti lieto X.509 formātā.
Pēc TLS sesijas izveidošanas klients un serveris vienojas par tālāk lietojamo simetrisko šifru. Klients aizsūta serverim visus pieejamos šifrus un serveris no tiem izvēlas labāko pieejamo.
Sākumā Netscape (pārlūkprogrammas Netscape navigator izstrādātājs) izstrādāja SSL protokolu. Tam bija 3 versijas. 1. bija nedroša un to nekur nelietoja, 2. versija iznāca 1995. gada februārī, bet drīz atklājās, ka tā arī nav droša, tāpēc izstrādāja SSL 3. versiju, kas iznāca 1996. gadā. Savietojamības dēļ daudzas pārlūkprogrammas spēj darboties ar SSL v2. TLS izstrādāja IETF kā uzlabojumu SSL v3 protokolam un TLS v1 iznāca 1999 (RFC 2246). gadā. Tas tika papildināts 2006. gadā, kad iznāca TLS 1.1 (RFC 4346) un 2008. gadā, kad iznāca TLS 1.2 (RFC 5246).
TLS parasti iekapsulē lietojumslāņa protokolus, tādus kā HTTP, FTP, SMTP, IMAP un citus. TLS savus datus sūta caur transporta slāņa protokolu, parasti TCP. Vēlāk izstrādāja TLS paveidu, kas darbojas caur UDP (DTLS). 5 slāņu TCP/IP modelī TLS atrodas starp transporta slāni un lietojumslāni. 7 slāņu OSI modelī TLS atrodas pasniegšanas slānī (6. slānis).
Plašāk pazīstamais TLS pielietojums ir HTTP datu plūsmas šifrēšana HTTPS protokolā, kuru lieto interneta bankas un interneta veikali (un visi citi, kas negrib lai to datus jebkurš, kas tiek klāt, varētu pārtvert vai izmainīt). Otrs nozīmīgākais pielietojums ir e-pasta datu plūsmas šifrēšana starp e-pasta programmu un serveri (lai mēstuļotājiem būtu grūtāk tikt pie lietotāju parolēm), taču šis ir krietni mazāks kā HTTPS. Šajos gadījumos ar sertifikātiem parasti autentificē tikai serveri.
Liela daļa klientu un serveru satur TLS moduli un var sazināties caur TLS, kā ir. Tiem, kam TLS nav iebūvēts, var lietot atsevišķas programmas (piem. Stunnel), kas TCP savienojumu pārvērš TLS savienojumā.
TLS var izmantot arī lai tunelētu veselu tīkla saskarni izveidojot VPN, tā kā OpenVPN. Šī ir viena no trim nozīmīgākajām VPN izveidošanas metodēm.
TLS ir klients-serveris veida protokols. Izveidojot TLS savienojumu, tas gals, kas aizsūta ClientHello, ir klients. Lai arī klients parasti ir gals, kas uzsāk TCP savienojumu, tas nav obligāti. Vienkāršākajā variantā TLS savienojuma izveidošana notiek šādi:
Tālākos pārsūtāmos datus sasmalcina paketēs (tādā izmērā kā TCP paketes), aprēķina katrai paketei hash, kuru pieliek datiem, nošifrē ar simetrisko algoritmu un sūta prom. Pirms šifrēšanas paketi var sakompresē, izmantojot servera akceptēto kompresijas metodi. Ļoti bieži kompresiju nelieto (kompresijas metode null).
Tas process šādi notiek kādos vairāk kā 50% gadījumos, kad lieto TLS. Šajā gadījumā:
Izveidojot TLS savienojumu, to var izveidot uzreiz kā TLS (nekad netiek pārsūtīti nešifrēti lietojumslāņa protkola dati), vai arī var sākt ar nešifrētu lietojumslāņa protokola savienojumu un sākt TLS šifrēšanu pēc kādas komandas izpildes, šajā gadījumā, līdz TLS šifrēšans ieviešanai pārsūtītie dati ir nešifrēti. Pirmais variants ir implicit TLS un to lieto kopā ar http (gandrīz vienmēr) un var lietot kopā ar IMAP, SMTP un FTP. Otrais variants ir explicit TLS un to parasti lieto kopā ar SMTP un FTP. To varētu lietot arī ar http, bet šī metode ir ļoti nepopulāra, jo te ir sliktāka drošā servera identificējamība. Implicit TLS gadījumā ir nepieciešams atsevišķs ports šifrētajām komunikācijām (ja paralēli grib lietot arī nešifrētās), HTTP gadījumā tas ir 443 un FTP - 991. Explicit TLS gadījumā šifrētajām un nešifrētajām komunikācijām var lietot vienu un to pašu portu.
TLS protokols lieto 2 apakšslāņus: record protocol, kas šifrē un autentificē paketes un vairākus augšējā slāņa apakšprotokolus, kas vai nu nokonfigurē šifrēšans atslēgas (handshake), ieslēdz šifrēšanu (changecipherspec), nes informāciju par kļūdām un citiem negaidītiem incidentiem (alert), vai arī nes derīgos datus (application).
+ | Baits +0 | Baits +1 | Baits +2 | Baits +3 | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Baits 0 |
satura tips | |||||||||||||||||||||||||||||||
Baiti 1..4 |
Versija | Garums | ||||||||||||||||||||||||||||||
(Major) | (Minor) | (biti 15..8) | (biti 7..0) | |||||||||||||||||||||||||||||
Baiti 5..(m-1) |
Protokola dati | |||||||||||||||||||||||||||||||
Baiti m..(p-1) |
MAC (neobligāti) | |||||||||||||||||||||||||||||||
Baiti p..(q-1) |
Padding (tikai bloku šifriem) |
Hex | Dec | Type |
---|---|---|
0x14 | 20 | ChangeCipherSpec |
0x15 | 21 | Alert |
0x16 | 22 | Handshake |
0x17 | 23 | Application |
Major versija | Minor versija | vienā gabalā |
---|---|---|
3 | 0 | SSL 3.0 |
3 | 1 | TLS 1.0 |
3 | 2 | TLS 1.1 |
3 | 3 | TLS 1.2 |
TLS lieto tikai definētas simetrisko un asimetrisko kriptogrāfisko algoritmu kombinācijas (ciphersuite) (t.i., nevar izvēlēties kombināciju kās nav iepriekš definēta, pat ja ir pieejami visi nepieciešamie komponenti). Oficiālo ciphersuite saraksts atrodas .
Ciphersuite ir kombinācija no autentifikācijas metodes (Au), atslēgu apmaiņas metodes (Kx), šifrēšanas metodes (cipher) un ziņojumu autentifikācijas metodes (HMAC).
Au lieto asimetrisko kriptogrāfiju lai autentificētu serveri. Plašāk lietotās metodes ir:
RSA var lietot gan šifrēšanai, gan parakstīšanai. DSA (DSS) un ECDSA algoritmus var lietot tikai parakstīšanai. Vēl ir bijuši mēģinājumi lietot ntru algoritmus (nodrošina līdzīgu funkcionalitāti kā RSA, bet darbojas ātrāk), bet šie mēģinājumi nebeidzās ar standartu.
Kx lieto asimetrisko kriptogrāfiju lai abos galos uzģenerētu vienādas simetriskās šifrēšanas atslēgas. To var panākt 2 veidos:
TLS ir definēti daudzi simetriskie šifrēšanas algoritmi. Plašāk lietotie ir 3DES, RC4, AES. Agrāk mēdza lietot arī RC2, DES un IDEA. 21.gs. 1. dekādē tika definēti arī CAMELLIA un SEED (CAMELLIA šad tad parādās). ECC ciphersuites ir definētas tikai ar 3DES, RC4 un AES, tāpēc ECDHE-ECDSA-CAMELLIA-SHA neeksistē, pat ja visi komponenti ir pieejami. Vienīgai plaši lietotais plūsmas šifrs (stream cipher) ir RC4. Ir bijuši neveiksmīgi mēģinājumi standartizēt HC128. Pārējie plašāk lietotie šifri ir bloku šifri. Simetriskās šifrēšanas algoritmus lieto pārsūtāmo datu šifrēšanai. Ir iespējami arī varianti, kad datus nešifrē (algoritms NULL). Šādā gadījumā TLS sesija nodrošina tikai to ka datus neviens nevar izmainīt (bet izlasīt var jebkurš).
HMAC nodrošina pārsūtāmo datu autentifikāciju (lai varētu pamanīt jebkādas no malas izdarītas izmaiņas). HMAC ir hash, kas aprēķināts no autentificējamajiem datiem un slepena datu bloka (atslēgas). Par hash funkcijām lieto MD5 un SHA1. TLS1.2 pārādās dažas ciphersuites, kas lieto SHA256.
Piemēri: RSA-RC4-MD5 - Au un Kx ir RSA (apvienots), šifrēšanas algoritms ir RC4 un HMAC ir bāzēts uz MD5. Šī kombinācija nodrošina mazu procesora noslodzi, tāpēc ir populāra (lai arī visiem komponentiem ir kaut kādā merā šaubīga drošiba). ECDHE-RSA-AES128-SHA - Kx ir ECDHE, Au ir RSA (RSA paraksts), šifrēšanas algoritms ir AES ar 128 bitu atslēgu un HMAC ir bāzēts uz SHA1.
Parasti TLS autentificē tikai serveri, bet ir iespējams autentificēt gan serveri, gan klientu. Ja lietot neautentificētu serveri (ADH, AECDH), tad klientu sertifikātu autentifikācija nav iespējama. Klienta sertifikāta privāto atslēgu lieto tikai parakstīšanai (serverim varēja būt vai nu atšifrēšana (RSA), vai parakstīšana (pārējie)). Jebkurā gadījumā simetriskās šifrēšanas atslēgas ir atkarīgas tikai no servera sertifikāta (tāpat kā ssh)(vai nu iegūtas no ar servera publisko atslēgu nošifrētā premaster secret, vai arī no ar servera parakstītās DH atslēgas). Klients sertifikātu aizsūta pirms ir ieslēgta šifrēšana, tāpēc to var pārtvert. Tas nedod iespēju izlikties par klientu, bet ļauj identificēt klientu. Klienta sertifikāts var saturēt personīgu informāciju. Tas ierobežo TLS klientu sertifikātu autentifikācijas pielietojumus. SSH ir pieejama līdzīga funkcionalitāte, bet tur klienta sertifikātu (publisko atslēgu) aizsūta pēc šifrēšanas ieslēgšanas.
HTTPS gadījumā ir problēmas ar virtuālajiem hostiem, t.i., ja http serveris uztur vairākas interneta lapas ar dažādiem nosaukumiem uz vienas IP adreses (piem., ja ir adrese 10.234.112.65 un DNS www.aaa.lv, www.aaa1.lv, www.ccc.lv). Interneta pārlūkprogrammas HTTP pieprasījums satur servera adresi (piem. www.aaa.lv) un no tā serveris zin, ka jāaizsūta faili, kas atbilst www.aaa.lv, nevis kādi citi. TLS protokols normāli atrodas zem HTTP un klients, kas pieslēdzas šajā stadijās nedod nekādu informāciju par viņam vajadzīgo lapu, tāpēc serveris var aizūtīt tikai noklusēto servera sertifikātu, kas visticamāk netbilst pieprasītajai lapai (kas mūsdienu pārlūkprogrammās uztaisa brīdinājumu pa visu ekrānu). Šī iemesla dēļ katrai HTTPS lapai vajag savu IP adresi un virtuālie hosti te nedarbojas.
Viens no risinājumiem ir TLS pielikt informāciju par vajadzīgo hostu. Tas darbojas, taču liels daudzums interneta pārlūkprogrammu šo TLS paplašinājumu neatbalsta. Lai nodotu informāciju par servera vārdu, lieto SNI paplašinājumu (server name indication), kas var saturēt līdz 64 baitu garu DNS vārdu.
Daudzas sākotnējās SSL implementācijas lietoja simetrisko šifrēšanu ar 40 bitu atslēgām. Tās vienmēr bija bijušas nedrošas un tika lietotas tikai ASV kriptogrāfijas eksporta ierobežojumu dēļ. Kādu laiku (20. gadsimta 90. gadu beigās) 128 bitu šifrēšana eksporta pārlūkprogrammās bija pieejama tikai ar specifiskiem server gated cryprography sertifikātiem, kurus izsniedza tikai viena CA un tikai bankām un citām finansu iestādēm. Tad, kad šos eksporta ierobežojumus samazināja, visi sāka lietot parasto 128+ bitu simetrisko šifrēšanu.
TLS (SSL) ir pieejams visās plašāk lietotajās pārlūkprogrammās:
Visos nozīmīgākajos https serveros ir pieejams TLS1.2 (vismaz jaunākajās versijās). Tajos visos arī ir pieejams SNI. SNI ir pieejams visās jaunākajās datoru pārlūkprogrammu versijās, bet nav pieejams vecās viedtelefonu pārlūkprogrammu versijās un tur tās pārlūkprogrammas parasti nav iespējams nomainīt uz jaunākām.
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.