b'\n_START_ARTICLE_\nSecure Sockets Layer\n_START_PARAGRAPH_\nSecure Sockets Layer (kratica SSL) in njegov naslednik Transport Layer Security (TLS) sta kriptografska protokola, ki omogo\xc4\x8data varno komunikacijo na medmre\xc5\xbeju, na primer pri brskanju po spletu in e-po\xc5\xa1tnim ter instantnim komuniciranjem. Med protokoloma obstajajo majhne razlike, vendar sta v principu enaka._NEWLINE_Protokol SSL je zelo raz\xc5\xa1irjen povsod, kjer se pojavlja potreba po prenosu podatkov zaupne narave (npr. osebni podatki in \xc5\xa1tevilke kreditnih kartic), Torej pri spletnih trgovinah, spletnemu ban\xc4\x8dni\xc5\xa1tvu, ipd. Precej prezrto ostaja dejstvo, da SSL pred vdorom \xc5\xa1\xc4\x8diti podatke le med po\xc5\xa1iljanjem, ne pa tudi po tem, ko prispejo na ciljni ra\xc4\x8dunalnik.\n_START_SECTION_\nSSL 1.0, 2.0 in 3.0\n_START_PARAGRAPH_\nProtokol SSL je razvil Netscape. Razli\xc4\x8dica 1.0 ni bila nikoli javno izdana; razli\xc4\x8dica 2.0 je bila izdana leta 1994, vendar je vsebovala mnoge varnostne pomanjkljivosti, kar je vodilo do razvoja SSL razli\xc4\x8dice 3.0 leta 1996, ki je bila v bistvu v celoti na novo spisana. Novej\xc5\xa1e 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.\n_START_SECTION_\nTLS 1.0\n_START_PARAGRAPH_\nTLS 1.0 je bil prvi\xc4\x8d 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\xc4\x8duje mehanizma, ki bi omogo\xc4\x8dal degradacijo komunikacije na SSL 3.0 in s tem zmanj\xc5\xa1al varnost.\n_START_SECTION_\nTLS 1.2\n_START_PARAGRAPH_\nTLS 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.\n_START_SECTION_\nTLS 1.3\n_START_PARAGRAPH_\nTLS 1.3 je bil definiran avgusta 2018. Je tudi nazaj kompatibilen z verzijo 1.2.\n_START_SECTION_\nPotek komunikacije\n_START_PARAGRAPH_\nUporabnikov brskalnik po\xc5\xa1lje zahtevo za spletno stran z varovanim prenosom SSL (ali TLS). Stre\xc5\xbenik se predstavi z javnim klju\xc4\x8dem. Ta proces uporablja enkripcijo z javnim klju\xc4\x8dem in digitalnim potrdilom. Tako stre\xc5\xbenik potrdi da je, kar trdi, da je. Ko se stre\xc5\xbenik predstavi, brskalnik ustvari klju\xc4\x8d za enkripcijo s simetri\xc4\x8dnim klju\xc4\x8dem, ga zakodira s stre\xc5\xbenikovim javnim (public)  klju\xc4\x8dem, in mu ga po\xc5\xa1lje. Stre\xc5\xbenik prejme klju\xc4\x8d, ga dekodira s privatnim klju\xc4\x8dem. Od tu naprej poteka povezava prek veliko hitrej\xc5\xa1e enkripcije. To je enkripcija s simetri\xc4\x8dnim klju\xc4\x8dem. Je bistveno hitrej\xc5\xa1a za kodiranje in dekodiranje podatkov, hitro pa lahko odkrije tudi, \xc4\x8de so bili podatki med prenosom spremenjeni. Stre\xc5\xbenik v\xc4\x8dasih zahteva tudi uporabnikovo predstavitev. Ta se (podobno kot stre\xc5\xbenik) predstavi z digitalnim potrdilom / certifikatom.\n_START_SECTION_\nEnkripcija s simetri\xc4\x8dnem klju\xc4\x8dem (Symmetric-Key Encryption)\n_START_PARAGRAPH_\nPri tej enkripciji je klju\xc4\x8d za kodiranje lahko izra\xc4\x8dunan na podlagi klju\xc4\x8da za dekodiranje in obratno. Pri ve\xc4\x8dini primerov te enkripcije se za kodiranje in dekodiranje uporablja isti klju\xc4\x8d. Uporaba enkripcije s simetri\xc4\x8dnim klju\xc4\x8dem je lahko u\xc4\x8dinkovita, saj je procesorsko nezahtevna in zato uporabniki ne zaznajo prekinitve procesa kot posledico (de)kodiranja. Ta na\xc4\x8din do neke mere omogo\xc4\x8da tudi preverjanje, s kom komunikacija v resnici poteka, zakaj podatke zakodirane z enim klju\xc4\x8dem lahko dekodira le oseba s tem istim klju\xc4\x8dem. Torej dokler je klju\xc4\x8d znan le dvema stranema, sporo\xc4\x8dila med njima ne morajo biti dekodirana z nobenim drugim klju\xc4\x8dem. Torej je ta enkripcija efektivna le, \xc4\x8de je klju\xc4\x8d skrit pred ostalimi potencialnimi prislu\xc5\xa1kovalci. Oseba s pridobljenim klju\xc4\x8dem lahko ne le dekodira sporo\xc4\x8dila, temve\xc4\x8d tudi zakodira nova,spremenjena, ter jih po\xc5\xa1lje kot bi jih poslal nekdo izmed pravih lastnikov klju\xc4\x8dev. Enkripcija s simetri\xc4\x8dnim klju\xc4\x8dem igra pomembno vlogo v protokolu SSL.\n_START_SECTION_\nEnkripcija z javnim klju\xc4\x8dem (Public-Key Encryption)\n_START_PARAGRAPH_\nEnkripcija z javnim klju\xc4\x8dem vklju\xc4\x8duje par klju\xc4\x8dev: zasebni klju\xc4\x8d (private key) in javni klju\xc4\x8d (public key). Javni klju\xc4\x8d je znan vsem in je objavljen, medtem ko je zasebni klju\xc4\x8d znan le osebi (stre\xc5\xbeniku) in mora ostati skrit. Podatki zakodirani z javnim klju\xc4\x8dem so lahko dekodirani le s pripadajo\xc4\x8dim privatnim klju\xc4\x8dem._NEWLINE_V splo\xc5\xa1nem, pri po\xc5\xa1iljanju podatkov prejemniku, zakodiramo podatke z njegovim javnim klju\xc4\x8dem, prejemnik pa ga dekodira s svojim privatnim klju\xc4\x8dem. V primerjavi z enkripcijo s simetri\xc4\x8dnim klju\xc4\x8dem ta enkripcija zahteva ve\xc4\x8d procesorskega \xc4\x8dasa in je zato manj primerna za po\xc5\xa1iljanje ve\xc4\x8djih koli\xc4\x8din podatkov. Zato se obi\xc4\x8dajno s to enkripcijo varuje le prenos klju\xc4\x8dev za simetri\xc4\x8dno enkripcijo. Ta na\xc4\x8din uporablja tudi protokol SSL._NEWLINE_Deluje pa tudi obratna smer namre\xc4\x8d: z javnim klju\xc4\x8dem se da odkleniti podatke zakodirane z zasebnim klju\xc4\x8dem. Tak na\xc4\x8din prena\xc5\xa1anja podatkov pa ni zaceljen, saj lahko vsak, ki pozna po\xc5\xa1iljateljev javni klju\xc4\x8d dekodira poslane podatke. Vseeno se ta metoda uporablja in namre\xc4\x8d za preverjanje po\xc5\xa1iljatelja. Po\xc5\xa1iljatelj torej podatke zaklene najprej s svojim privatnim klju\xc4\x8dem, nato pa \xc5\xa1e s prejemnikovim javnim. Edini, ki lahko odpre po\xc5\xa1iljko je prejemnik s svojim privatnim klju\xc4\x8dem in nato \xc5\xa1e s po\xc5\xa1iljateljevem javnim (tega je lahko zaklenil edinole po\xc5\xa1iljatelj).\n_START_SECTION_\nProblem z IP-naslovi\n_START_PARAGRAPH_\nDo nedavnega je lahko en SSL certifikat \xc5\xa1\xc4\x8ditil le eno spletno stran na enem javnem IP naslovu. Raz\xc5\xa1iritev tej omejitvi so t.im. "Wildcard" SSL certifikati, ki lahko vsebujejo ve\xc4\x8d pod-domen (npr. www.domena.com, mapa1.domena.com, mapa2.domena.com itd.), vendar je omejitev \xc5\xa1e vedno vse skupaj na enem javnem IP naslovu._NEWLINE_Tej omejitvi se pripravlja konec, kajti \xc5\xbee Apache v2.2.12 in OpenSSL v0.9.8j podpirata TLS z raz\xc5\xa1iritvijo Server Name Indication [SNI]. Problem pred to raz\xc5\xa1iritvijo je v dejstvu, da si klient in stre\xc5\xbenik izmenjata podatke o zahtevani domeni \xc5\xa1ele po vzpostavljeni HTTPS povezavi, pred tem pa stre\xc5\xbenik \xc5\xa1e 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._NEWLINE_SNI pa re\xc5\xa1uje problem tako, da po\xc5\xa1lje informacijo o zahtevani domeni \xc5\xbee znotraj TLS pogajalske seje in je potemtakem stre\xc5\xbenik obve\xc5\xa1\xc4\x8den, katero domeno in posledi\xc4\x8dno kateri certifikat mora uporabiti \xc5\xa1e preden dejansko vzpostavi varno SSL oz. TLS sejo.'