Secure Sockets Layer

»SSL« se preusmerja sem. Za druge pomene glej SSL (razločitev).

Secure Sockets Layer (kratica SSL) in njegov naslednik Transport Layer Security (TLS) sta kriptografska protokola, ki omogočata varno komunikacijo na medmrežju, na primer pri brskanju po spletu in e-poštnim ter instantnim komuniciranjem. Med protokoloma obstajajo majhne razlike, vendar sta v principu enaka.

Protokol SSL je zelo razširjen povsod, kjer se pojavlja potreba po prenosu podatkov zaupne narave (npr. osebni podatki in številke kreditnih kartic), Torej pri spletnih trgovinah, spletnemu bančništvu, ipd. Precej prezrto ostaja dejstvo, da SSL pred vdorom ščiti podatke le med pošiljanjem, ne pa tudi po tem, ko prispejo na ciljni računalnik.

Zgodovina

SSL 1.0, 2.0 in 3.0

Protokol SSL je razvil Netscape. Različica 1.0 ni bila nikoli javno izdana; različica 2.0 je bila izdana leta 1994, vendar je vsebovala mnoge varnostne pomanjkljivosti, kar je vodilo do razvoja SSL različice 3.0 leta 1996, ki je bila v bistvu v celoti na novo spisana. Novejše verzije SSL/TLS protokola slonijo na verziji 3.0. Osnutek SSL 3.0 je bil objavljen s strani IETF kot zgodovinsko gradivo v RFC 6101.

TLS 1.0

TLS 1.0 je bil prvič definiran januarja 1999 v RFC 2246 kot nadgradnja SSL verzije 3.0. Kot navaja RFC, razlike med SSL 3.0 in TLS 1.0 niso velike, so pa zadostne za medsebojno neoperabilnost med TLS 1.0 in SSL 3.0. TLS ne vključuje mehanizma, ki bi omogočal degradacijo komunikacije na SSL 3.0 in s tem zmanjšal varnost.

TLS 1.1

TLS 1.1 je bil definiran aprila 2006 v RFC 4346 kot nadgradnja TLS 1.0. Znatne spremembe so predvsem:

• Dodana zaščita pred napadi s t.im. veriženjem šifrirnih blokov Cipher block chaining
  • Implicit IV Initialization Vector je zamenjan z eplicitnim IV
  • Spremembe v obvladovanju padding errors
• Podpora ragistraciji parametrov za IANA

TLS 1.2

TLS 1.2 je bil definiran v RFC 5246 avgusta 2008 in je seveda nadgradnja TLS 1.1. Nadalje je bil marca 2011 ponovno definiran v RFC 6176, kjer je bila odstranjena kompatibilnost z SSL tako, da TLS seja ne more nikoli vzpostaviti SSL seje verzije 2.0.

TLS 1.3

TLS 1.3 je bil definiran avgusta 2018. Je tudi nazaj kompatibilen z verzijo 1.2.

Potek komunikacije

Uporabnikov brskalnik pošlje zahtevo za spletno stran z varovanim prenosom SSL (ali TLS). Strežnik se predstavi z javnim ključem. Ta proces uporablja enkripcijo z javnim ključem in digitalnim potrdilom. Tako strežnik potrdi da je, kar trdi, da je. Ko se strežnik predstavi, brskalnik ustvari ključ za enkripcijo s simetričnim ključem, ga zakodira s strežnikovim javnim (public) ključem, in mu ga pošlje. Strežnik prejme ključ, ga dekodira s privatnim ključem. Od tu naprej poteka povezava prek veliko hitrejše enkripcije. To je enkripcija s simetričnim ključem. Je bistveno hitrejša za kodiranje in dekodiranje podatkov, hitro pa lahko odkrije tudi, če so bili podatki med prenosom spremenjeni. Strežnik včasih zahteva tudi uporabnikovo predstavitev. Ta se (podobno kot strežnik) predstavi z digitalnim potrdilom / certifikatom.

Enkripcija s simetričnem ključem (Symmetric-Key Encryption)

Pri tej enkripciji je ključ za kodiranje lahko izračunan na podlagi ključa za dekodiranje in obratno. Pri večini primerov te enkripcije se za kodiranje in dekodiranje uporablja isti ključ. Uporaba enkripcije s simetričnim ključem je lahko učinkovita, saj je procesorsko nezahtevna in zato uporabniki ne zaznajo prekinitve procesa kot posledico (de)kodiranja. Ta način do neke mere omogoča tudi preverjanje, s kom komunikacija v resnici poteka, zakaj podatke zakodirane z enim ključem lahko dekodira le oseba s tem istim ključem. Torej dokler je ključ znan le dvema stranema, sporočila med njima ne morajo biti dekodirana z nobenim drugim ključem. Torej je ta enkripcija efektivna le, če je ključ skrit pred ostalimi potencialnimi prisluškovalci. Oseba s pridobljenim ključem lahko ne le dekodira sporočila, temveč tudi zakodira nova,spremenjena, ter jih pošlje kot bi jih poslal nekdo izmed pravih lastnikov ključev. Enkripcija s simetričnim ključem igra pomembno vlogo v protokolu SSL.

Enkripcija z javnim ključem (Public-Key Encryption)

Enkripcija z javnim ključem vključuje par ključev: zasebni ključ (private key) in javni ključ (public key). Javni ključ je znan vsem in je objavljen, medtem ko je zasebni ključ znan le osebi (strežniku) in mora ostati skrit. Podatki zakodirani z javnim ključem so lahko dekodirani le s pripadajočim privatnim ključem. V splošnem, pri pošiljanju podatkov prejemniku, zakodiramo podatke z njegovim javnim ključem, prejemnik pa ga dekodira s svojim privatnim ključem. V primerjavi z enkripcijo s simetričnim ključem ta enkripcija zahteva več procesorskega časa in je zato manj primerna za pošiljanje večjih količin podatkov. Zato se običajno s to enkripcijo varuje le prenos ključev za simetrično enkripcijo. Ta način uporablja tudi protokol SSL. Deluje pa tudi obratna smer namreč: z javnim ključem se da odkleniti podatke zakodirane z zasebnim ključem. Tak način prenašanja podatkov pa ni zaceljen, saj lahko vsak, ki pozna pošiljateljev javni ključ dekodira poslane podatke. Vseeno se ta metoda uporablja in namreč za preverjanje pošiljatelja. Pošiljatelj torej podatke zaklene najprej s svojim privatnim ključem, nato pa še s prejemnikovim javnim. Edini, ki lahko odpre pošiljko je prejemnik s svojim privatnim ključem in nato še s pošiljateljevem javnim (tega je lahko zaklenil edinole pošiljatelj).

Problem z IP-naslovi

Do nedavnega je lahko en SSL certifikat ščitil le eno spletno stran na enem javnem IP naslovu. Razširitev tej omejitvi so t.im. "Wildcard" SSL certifikati, ki lahko vsebujejo več pod-domen (npr. www.domena.com, mapa1.domena.com, mapa2.domena.com itd.), vendar je omejitev še vedno vse skupaj na enem javnem IP naslovu.

Tej omejitvi se pripravlja konec, kajti že Apache v2.2.12 in OpenSSL v0.9.8j podpirata TLS z razširitvijo Server Name Indication SNI. Problem pred to razširitvijo je v dejstvu, da si klient in strežnik izmenjata podatke o zahtevani domeni šele po vzpostavljeni HTTPS povezavi, pred tem pa strežnik še nima informacije, katero spletno stran bo klient zahteval. Zato se je omejeval na IP naslov in je lahko stregel le eno spletno stran preko HTTPS protokola na enem javnem IP naslovu.

SNI pa rešuje problem tako, da pošlje informacijo o zahtevani domeni že znotraj TLS pogajalske seje in je potemtakem strežnik obveščen, katero domeno in posledično kateri certifikat mora uporabiti še preden dejansko vzpostavi varno SSL oz. TLS sejo.

Zunanje povezave

• Pogosta vprašanja o SSL certifikatih Arhivirano 2013-02-10 na Wayback Machine.