Transporta slāņa drošība

Transporta slāņa drošība 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).

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.

Vēsture

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).

Pielietojumi

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.

Drošība

• Klients var lietot sertifikātu izsniedzēja (CA) publisko atslēgu lai pārbaudītu viņa (CA) digitālo parakstu servera sertifikātā.
• Klients parasti pārbauda vai sertifikāta izsniedzējs ir uzticamo CA sarakstā.
• Klients pārbauda servera sertifikāta derīguma termiņu, ja tas ir beidzies (vai vēl nav sācies), autentifikācija nobrūk.
• Dažās programmās klients vai serveris var atteikties turpināt, ja otram galam nav pieejami pietiekoši droši autentifikācijas un simetriskās šifrēšanas algoritmi.
• Autentifikācijas beigās abi gali apmainās ar ziņojumiem, kas satur visu autentifikācijas sesijā apmainīto paziņojumu hash.

Darbība

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:

• Sākumā klients pieslēdzas pie servera un aizsūta ClientHello paketi, kas satur:
  • sarakstu ar savā galā pieejamajām šifru, jaucējfunkciju (hash) un autentifikācijas metožu kombinācijām (ciphersuite);
  • jaunāko atbalstīto TLS versiju;
  • gadījumskaitli (kuru tālāk lieto atslēgu ģenerēšanai);
  • sarakstu ar kompresijas metodēm.
• Serveris atbils ar ServerHello, kas satur:
  • no klienta saraksta izvēlētā labākā, serverim pieejamā, ciphersuite;
  • servera TLS versiju (versija, kuru lietos tālākajai TLS sesijai);
  • sesijas ID;
  • gadījumskaitli;
  • izvēlēto kompresijas metodi.
• Serveris vēl aizsūta savu sertifikātu, tas satur servera vārdu (https gadījumā tas ir domain name) un publisko atslēgu. Dažām ciphersuite, sertifikātu nelieto, tādā gadījumā šo paketi nesūta.
• Serveris aizsūta ServerHelloDone, kas norāda, ka vairāk sertifikātu nebūs.
• Klients šajā stadijā pārbauda servera sertifikāta derīgumu (var sazināties ar sertifikāta izsniedzēju, lai pārbaudītu vai nav atsaukts, bet parasti to nedara). Lai varētu uzģenerēt tālāk lietojamās simetriskās šifrēšanas atslēgas, klients izvēlas lielu gadījumskaitli (random number)(šajā gadījumā tas ir PreMasterSecret), nošifrē to ar servera publisko atslēgu (no sertifikāta) un aizsūta serverim (ClientKeyExchange izmantojot RSA autentifikāciju). Ja servera privātā atslēga ir pieejama tikai serverim (bet nekur citur), tad to gadījumskaitli var atšifrēt tikai serveris. No šī skaitļa abi gali ģenerē simetriskās šifrēšanas atslēgas.
• Klients aizsūta ChangeCipherSpec, kas norāda, ka visas tālākās paketes no klienta būs šifrētas (lietojot iepriekšējā stadijā uzģenerētās simetriskās atslēgas).
• Klients aizsūta šifrētu Finished, kas satur visu iepriekš sūtīto pakešu hash (sākot no ClientHello). Šī pakete jau ir šifrēta.
  • Serveris šajā stadijā mēģina atšifrēt klienta pēdējo atsūtīto paketi (Finished) un ja tas neizdodas, savienojums pārtrūkst.
• Serveris aizsūta tādas pašas ChangeCipherSpec un Finished. Ja klienta vai servera saņemtajā Finished paketē esošais hash neatbilst tam, kādu iegūst uz vietas aprēķinot hash no attiecīgajām saņemtajām paketēm, tad ir skaidrs, ka kāds mēģina jaukties pa vidu un savienojumu pārtrauc.

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ā:

• Tika atvērts jauns savienojums (nevis atjaunots jau iepriekš lietots),
  • Atjaunojot iepriekš lietotu sesiju, klienta ClientHello satur atjaunojamās sesijas ID. (Izveidojot jaunu sesiju tas ir 0). Ja serverim ir saglabājušies sesijas parametri, tas atsūta ServerHello ar to pašu sesijas ID un pārējiem parametriem, tā kā simetriskās atslēgas ir saglabājušās, klients var uzreiz sūtīt ChangeCipherSpec. Ja serverim nav saglabājušies sesijas parametri, tas atsūta citu sesijas ID un tad veido jaunu sesiju kā parasti.
  • Iepriekš lietotu sesiju var atjaunot arī lietojot session tickets paplašinājumu. Lietojot sesijas ID, serverim ir savā galā jāuzglabā sesijas atslēga. Session tickets gadījumā serveris nošifrē sesijas datus (atslēga, ciphersuite, klienta sertifikāts (ja tāds ir)) ar simetrisku atslēgu un nosūta glabāšanā klientam. Klientam ir jāuzglabā sesijas atslēgu (un citus parametrus) un šo session ticket. Atjaunojot sesiju klients to aizsūta serverim. To šifrēšanai lietoto simetrisko atslēgu serveris var lietot daudzām nesaistītām sesijām ilgā laika periodā (starp servera restartiem), tāpēc tā atslēga aizņem mazāk vietas kā visu iespējamo atjaunojamo sesiju atslēgas lietojot session ID.
• Lietoja ciphersuite ar RSA atslēgu apmaiņu (Tas ir ātrāk nekā ar DHE-RSA, jo jāapmainās ar mazāk paketēm un ir mazāka CPU noslodze, bet ja kāds nozog servera privāto RSA atslēgu, tas var atšifrēt visas pārtvertās sesijas);
  • Lietojot DHE-RSA, serveris pēc ServerHello un sertifikāta aizsūta arī parakstītus DH parametrus (P,G un Y_servera), pēc tam klients pārbauda vai paraksts atbilst sertifikātam, uzģenerē savu Y_klienta, kuru aizsūta ar ClientKeyExchange. Simetrisko atslēgu ģenerē no DH aprēķinātā s. Pārējais ir kā parasti.
  • Vēl DH atslēgu apmaiņu lieto, ja servera sertifikāts satur publisko atslēgu, kuru nav iespējams lietot šifrēšanai (DSA).
• Netika lietota klienta autentifikācija (TLS var autentificēt klientu izmantojot tādus pašus sertifikātus kā serverim);
  • Ja lieto klienta autentifikāciju, tad serveris pēc sertifikāta aizsūta CertificateRequest, kas pieprasa no klienta sertifikātu. Tālākais notiek kā parasti, tikai klients pēc ClientKeyExchange aizsūta CertificateVerify, kas satur visu līdz šim no klienta sūtīto datu bloku parakstu izmantojot klienta sertifikāta privāto atslēgu.
• Netika izmainīti esošas sesijas parametri (renegotiation). (TLS ir iespējams izmainīt esošas sesijas parametrus (ciphersuite), izejot cauri līdzīgam procesam kā izveidojot jaunu sesiju).
• Serveri autentificēja ar sertifikātu. (ir iespējams izveidot arī neautentificētu sesiju, kad nelieto nekādus sertifikātus, bet to lieto ļoti reti).

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.

Pakešu struktūra

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)

satura tips

Šis lauks identificā šajā paketē ielikto augšējā līmeņa subprotokolu

satura tipi

Hex	Dec	Type
0x14	20	ChangeCipherSpec
0x15	21	Alert
0x16	22	Handshake
0x17	23	Application

Versija

Šis lauks identificē lietoto TLS protokola veriju. TLS Clienthello paketei te lieto lielāko klienta atbalstīto versiju.

Versijas

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

Garums

Protokola datu garums paketē. Tas nevar būt lielāks par 2¹⁴ baitiem (16KiB).

Protokola dati

Paketē pārsūtāmie dati. Application subprotokola gadījumā tie ir pārsūtāmie dati. Citiem subprotokoliem tie ir to subprotokolu dati. Tie dati var būt šifrēti.

MAC un Padding

MAC ir message authentication code, tas ir hash, kur hešojamajiem datiem ir piekabināti slepeni dati (simetriskā atslēga), būtībā tas ir simetriskais digitālais paraksts. Šis lauks var būt šifrēts kopā ar protokola datiem (padding vispār ir vajadzīgs tikai lai nodrošinātu šifrēšanas algoritmu darbību, t.i., ja reāli pārsūtāmie dati ir mazāk kā ielien veselā skaitā bloku šifra bloku). Izveidojot savienojumu, kad vēl nav šifrēšanas, šos abus neliek. (tad nav zināmas nekādas simetriskās atslēgas un nav iespējams izveidot arī MAC). Šos sāk lietot tikai pēc ChangeCipherSpec nosūtīšanas.

ciphersuite jēdziens

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 [1].

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 - klients ģenerē premaster secret un nošifrē ar servera publisko RSA atslēgu. Tā kā to var atšifrēt tikai ar privāto atslēgu, sesija veiksmīgi izveidosies tikai ja serverim ir pieejama tā privātā atslēga. Šī metode apvieno Au ar Kx. Šī ir visplašāk lietotā metode, bet ja kāds nozog servera privāto atslēgu, tas var atšifrēt visas pirms tam ar šo atslēgu šifrētās sesijas (te nav perfect forward secrecy). Šī metode ir populāra tāpēc, ka te ir relatīvi maza procesora noslodze.
• DHE-RSA - serveris paraksta savu publisko īstermiņa DH atslēgu ar savu ilgtermiņa RSA atslēgu. Klients pārbauda to parakstu. Ja paraksts ir derīgs, tas nozīmē ka tā DH atslēga nāk no servera. Šī metode ir relatīvi plaši pieejama, bet tai ir lielāka procesora noslodze kā RSA metodei (te vajag 3 asimetriskās operācijas: DH atslēgas ģenerēšana; RSA parakstīšana; DH shared secret aprēķināšana. RSA metodei vajadzēja tikai 1: RSA atšifrēšana). Šai metodei ir perfect forward secrecy.
• DH-RSA - servera sertifikāts satur statisku DH publisko atslēgu un CA ir parakstījis to izmantojot RSA atslēgu. Šī metode nav pieejama nevienā no plaši lietotajiem TLS moduļiem (openssl, gnutls, nss, schannel), tāpēc to tikpat kā nekur nelieto. Te nav perfect forward secrecy, jo shared secret var aprēķināt no nosūtītas klienta publiskās atslēgas un servera privātās DH atslēgas.
• DHE-DSS (DHE-DSA) - tieši tas pats kas ar DHE-RSA, tikai te servera sertifikāts satur DSA atslēgu, nevis RSA atslēgu. Šai metodei bija lielāka nozīme tad, kad vēl nebija beidzies RSA patents, jo te varēja iztikt bez RSA. Šī metode ir pieejama, bet to lieto reti.
• DH-DSS - tas pats kas DH-RSA, tikai CA sertifikāts satur DSA atslēgu. Arī nekur nav pieejams.
• ECDHE-RSA - tas pats kas DHE-RSA tikai DH vietā lieto ECDH.
• ECDH-RSA - tas pats kas DH-RSA, tikai DH vietā lieto ECDH. Arī nav plaši pieejams.
• ECDHE-ECDSA - tas pats kas DHE-DSS, tikai DH vietā lieto ECDH un DSA vietā lieto ECDSA. Ja servera sertifikāts satur ECC atslēgu, šī ir biežāk izvēlētā metode.
• ECDH-ECDSA - tas pats kas DH-DSS, tikai DH vietā lieto ECDH un DSA vietā lieto ECDSA. Lieto reti.
• ADH - anonīmais DH. Serveri neautentificē vispār.
• AECDH - tas pats kas ADH tikai lietojot ECDH.

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:

• RSA - uzģenerē atslēgu klienta galā un nošifrē ar servera publisko atslēgu.
• DH (un ECDH) - serveris uzģenerē DH atslēgu pāri, paraksta publisko atslēgu, nosūta publisko atslēgu un DH parametrus klientam, klients no tiem pašiem parametriem uzģenerē savu atslēgu pāri, publisko atslēgu nosūta serverim. Klients un serveris no savas privātās atslēgas un otra gala publiskās atslēgas aprēķina shared secret, ko lieto par simetriskās atslēgas izejvielu.
  • DHE - serveris katrai (vai gandrīz katrai) sesijai ģenerē jaunu atslēgu pāri. Nosūtāmo publisko atslēgu paraksta ar servera sertifikātam atbilsotošo privāto atslēgu, lietojot atbilstošu elektroniskā paraksta algoritmu (tas ir atkarīgs no servera sertifikāta atslēgas veida). Servera sertifikāts var būt RSA, DSA vai ECDSA. Viss tas pats attiecas arī uz ECDHE, tikai te DH vietā lieto ECDH.
  • DH (statiskais DH) - servera sertifikāts satur DH publisko atslēgu un DH parametrus. Šis sertifikāts nevar būt pašparakstīts. Tas attiecas arī uz statisko ECDH.
  • ADH (un AECDH) - te nelieto servera sertifikātu un serveris ir neautentificēts. Visādi citādi tas pats, kas DHE, tikai servera publisko atslēgu neparaksta, jo nav ar ko parakstīt.

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.

Klientu sertifikātu autentifikācija

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.

Implementācijas un problēmas

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:

• Mozilla Firefox, sākot no 24. versijas, ir pieejams TLS 1.2, bet ir atslēgts pēc noklusējuma;
• Opera, sākot no 10. versijas, ir pieejams TLS 1.2, bet atslēgts pēc noklusējuma, 17. versija ir pieejams un ieslēgts;
• Internet Explorer, sākot no 8. versijas uz windows 7, ir pieejams TLS 1.2, bet 8-10 versijām ir atslēgts;
• Chromium (un Google chrome) lieto tādu pašu TLS moduli kā Mozilla Firefox, tāpēc ir pieejams 1.2, bet te tas ir ieslēgts pēc noklusējuma.

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.

Skatīt arī

• HTTPS