Dok svakodnevno pretražujemo internet , u pozadini radi mnoštvo mehanizama, osmišljenih da spriječe bilo koga da špijunira naše aktivnosti. Jedan od najvažnijih, iako često zanemaren, je TLS. Ako koristite online bankarstvo, kupujete online ili upravljate Windows serverima, željet ćete razumjeti šta je to, kako funkcioniše i, prije svega, kako ga pravilno konfigurirati.
U modernim Windows okruženjima, od desktop računara do servera , TLS nije samo tehnički detalj: to je temelj na kojem se grade privatnost, integritet podataka i usklađenost s propisima. Nadalje, Windows uključuje Schannel, .NET Framework, WCF, registar, grupne politike, ECC krivulje… donekle složen ekosistem koji ima koristi od pristupa poput Zero Trust-a . Ispitajmo ovo detaljno, ali bez daljnjeg odlaganja.
Šta je TLS i zašto je toliko važan?
TLS (Transport Layer Security) je kriptografski protokol koji štiti komunikaciju koja putuje preko mreže, obično preko TCP-a. Njegova svrha je šifriranje podataka, sprječavanje neovlaštenih izmjena i osiguravanje da klijent tačno zna s kim komunicira.
TLS možemo zamisliti kao digitalni sef između dvije tačke: preglednika i web stranice, klijenta i API-ja, dva servera koji razmjenjuju datoteke, email klijenta poput Thunderbirda na Windowsu sa svojim SMTP/IMAP serverom... Sadržaj putuje preko interneta, koji je potpuno nesigurna mreža, ali zahvaljujući TLS-u postaje nerazumljiv tekst za svakoga ko pokuša da ga špijunira.
Glavni cilj protokola je da ponudi tri garancije : povjerljivost (šifriranje), integritet (da se podaci ne diraju) i autentifikaciju (poznavanje s kim komunicirate). U mnogim aplikacijama, server se autentifikuje pomoću certifikata, a opcionalno i klijent.
TLS ne šifrira podatke "u mirovanju" ili ono što radite unutar aplikacije ; fokusira se na zaštitu puta od jednog kraja komunikacije do drugog. Druge komplementarne tehnike se koriste za šifriranje diskova, baza podataka ili memorije koja se koristi.
Kako TLS funkcioniše korak po korak
Iako je unutrašnji rad TLS-a prilično sofisticiran , možemo ga sažeti u nekoliko vrlo jasnih faza. Sigurna komunikacija se gradi na početnom procesu koji se naziva rukovanje, a zatim se za razmjenu podataka koristi simetrično šifriranje.
TLS rukovanje
Sve počinje kada klijent otvori vezu sa serverom i pošalje poruku "ClientHello". U njoj navodi TLS verziju koju podržava, šifre koje poznaje i parametre potrebne za pregovaranje o sigurnosti.
Server odgovara sa „ServerHello“ , birajući verziju protokola i šifrirni paket koji će se koristiti tokom sesije. Također šalje svoj digitalni certifikat, koji sadrži njegov javni ključ i podatke o identitetu koje je validirao autoritet za izdavanje certifikata (CA).
Sljedeća je provjera certifikata . Klijent provjerava da li je certifikat potpisao pouzdani CA, da li mu je istekao rok važenja, da li je opozvan i da li se naziv certifikata podudara s domenom ili identifikatorom na koji se povezuje.
Ako se sve poklapa, klijent i server vrše razmjenu ključeva (koristeći RSA, Diffie-Hellman, ECDHE, itd.) kako bi dobili simetrični ključ sesije, koji će samo oni znati. Ovaj ključ se više ne šalje u otvorenom tekstu: izračunava se iz dijeljenih materijala šifriranih tokom pregovora.
Šifriranje, integritet i zatvaranje sesije
Nakon što se uspostavi ključ sesije , sva sljedeća komunikacija se šifrira korištenjem brzih simetričnih algoritama (npr. AES), a poruke su zaštićene MAC-om ili AEAD-om kako bi se osigurao integritet. Ako neko presretne promet, vidjet će samo nasumične podatke.
TLS također uključuje mehanizme koji osiguravaju da se poruke ne mijenjaju . Uključeni su kodovi za autentifikaciju poruka (MAC) ili oznake za autentifikaciju, tako da se svaka promjena sadržaja odmah otkrije.
Kada jedna strana odluči prekinuti komunikaciju , šalju se poruke o zatvaranju i taj ključ sesije se odbacuje. Čak i ako bi napadač kasnije ukrao privatni ključ servera, prethodne sesije sa savršenom tajnošću unaprijed (PFS) ostale bi neprobojne.
Evolucija TLS-a: Od SSL-a do TLS-a 1.3
Prije TLS-a postojao je SSL (Secure Sockets Layer) , koji je kreirao Netscape 90-ih. SSL 2.0 i 3.0 uveli su ideju šifriranja web komunikacije, ali vremenom su pronađene ozbiljne ranjivosti i danas se smatraju potpuno zastarjelim.
Godine 1999, TLS 1.0 je standardiziran na osnovu SSL 3.0 . To je bio korak naprijed, ali je na kraju kompromitovan napadima poput BEAST i CRIME. Kasnije je došao TLS 1.1 i, posebno, TLS 1.2, koji je dugi niz godina bio de facto standard u produkcijskim okruženjima.
TLS 1.2 je uveo značajna poboljšanja u algoritmima šifriranja, robusniju podršku za autentifikaciju i, što je najvažnije, mogućnost korištenja savršene tajnosti unaprijed s ECDHE-om, drastično smanjujući utjecaj hipotetičkog dugoročnog curenja ključa.
TLS 1.3, objavljen 2018. godine, predstavlja veliku reviziju protokola . Eliminiše nesigurne funkcije i zastarjele šifre, pojednostavljuje rukovanje na jedno rundno putovanje, pa čak i omogućava nastavke sa 0-RTT u vrlo specifičnim scenarijima. Podrazumevano je mnogo sigurniji i brži.
Stoga se danas toplo preporučuje onemogućavanje SSL 2.0/3.0, TLS 1.0 i 1.1, te korištenje barem TLS 1.2, po mogućnosti TLS 1.3 gdje je to moguće.
Gdje se TLS koristi u praksi?
Najvidljivija primjena TLS-a je pregledavanje weba pomoću HTTPS-a . Svaki put kada vidite katanac u adresnoj traci, vaš preglednik koristi TLS kako bi zaštitio podatke koje šaljete na web stranicu i primate s nje.
Izvan preglednika, TLS se masovno koristi u e-pošti : SMTP, IMAP i POP3 su enkapsulirani u TLS kako bi se spriječilo trećim stranama da čitaju ili mijenjaju poruke ili priloge tokom prenosa između servera i klijenata.
Sigurni prijenosi datoteka koriste protokole poput FTPS-a (FTP preko TLS-a) ili rješenja zasnovana na šifriranim tunelima koji koriste TLS za osiguranje veze. Ovo je ključno prilikom premještanja osjetljivih podataka, sigurnosnih kopija ili korporativnih informacija.
Moderni API-ji i web servisi gotovo uvijek se oslanjaju na HTTPS/TLS . I interni mikroservisi i integracije s trećim stranama (platni sistemi, CRM-ovi, usluge u oblaku itd.) zavise od TLS-a kako bi se osiguralo da podaci koji teku između aplikacija nisu izloženi.
TLS je također ključan za razmjenu poruka u stvarnom vremenu i VPN-ove . Prilagođene verzije poput DTLS-a omogućavaju zaštitu prometa preko UDP-a (glas, video, online igre), a mnogi moderni VPN-ovi oslanjaju se na TLS za uspostavljanje šifriranih tunela između korisnika i korporativne mreže.
Prednosti TLS-a za korisnike i organizacije
Iz perspektive krajnjeg korisnika, TLS štiti lične i finansijske podatke . Brojevi kartica, pristupni podaci, medicinske informacije ili bilo koji drugi osjetljivi podaci putuju šifrirano, što napadaču čini nepraktičnim da ih iskoristi čak i ako presretne promet.
Za preduzeća, TLS je ključna komponenta digitalnog povjerenja i sigurnosti od zlonamjernog softvera i hakovanja . Web stranica koja ispravno koristi HTTPS, s važećim certifikatom i modernim protokolima, prenosi kredibilitet i smanjuje rizik od phishinga ili napada lažnog predstavljanja.
U reguliranim sektorima kao što su bankarstvo, zdravstvo i e-trgovina , TLS pomaže u usklađivanju s propisima poput PCI DSS, GDPR i HIPAA, koji zahtijevaju siguran kanal za obradu određenih vrsta informacija. Nepravilna upotreba starijih protokola može dovesti do neusklađenosti i kazni.
Što se tiče ofanzivne sigurnosti, TLS ublažava nekoliko vrsta napada : pasivno prisluškivanje, manipulisanje tokom prenosa, napade tipa "čovjek u sredini" (MitM) i mnoge pokušaje ubrizgavanja sadržaja. Nije čarobni štapić, ali je ključni sloj.
Nadalje, sa SEO perspektive, pretraživači poput Googlea smatraju HTTPS pozitivnim signalom . Neposjedovanje TLS-a ne sprječava rangiranje, ali vas stavlja u jasan nepovoljan položaj u odnosu na konkurente koji nude isti sadržaj na sigurnoj web stranici.
Razlike između TLS-a i SSL-a (i zašto se još uvijek nazivaju "SSL certifikati")
U praksi, kada govorimo o "SSL certifikatima", gotovo uvijek mislimo na TLS . Termin SSL se zadržao u popularnom jeziku i marketingu, baš kao što bilo koju maramicu nazivamo "Kleenex", čak i ako je zapravo druge marke.
SSL je bio originalni protokol koji je utro put TLS-u , ali se sada smatra nesigurnim. TLS je trenutni standard, s preporučenim verzijama 1.2 i 1.3, i on je onaj koji zapravo koriste serveri i preglednici.
Razlog zašto trgovine i provajderi i dalje koriste izraz "SSL certifikati" je isključivo komercijalan i zasnovan na navici. Tehnički, ovi certifikati su X.509 certifikati za upotrebu sa TLS-om, iako je marketinški termin zastario.
Za administratora nije toliko važna komercijalna oznaka , već da certifikat izdaje pouzdani CA, da je važeći za domenu, da koristi moderne algoritme (npr. RSA s odgovarajućim ključanjem ili ECC) i da je kombinovan s robusnom TLS konfiguracijom.
Vrste TLS certifikata prema nivou validacije
TLS certifikati se razlikuju prvenstveno po nivou verifikacije koju vrši certifikacijsko tijelo prije njihovog izdavanja. Ovo ne mijenja vrstu enkripcije, ali utiče na stepen povjerenja koji nude u vezi s identitetom vlasnika.
Certifikati za validaciju domene (DV) samo potvrđuju da osoba koja traži certifikat kontrolira domenu. Validiraju se pomoću adrese e-pošte, DNS zapisa ili datoteke na web stranici. Brzi su i jeftini (neki su čak i besplatni, poput Let's Encrypt), ali ne pružaju nikakve informacije o kompaniji koja stoji iza stranice.
Certifikati za validaciju organizacije (OV) dodaju verifikaciju entiteta: pravni naziv, adresu, registraciju preduzeća... Certifikat uključuje ove podatke, tako da kupci mogu znati ko zaista stoji iza web stranice.
Certifikati s proširenom validacijom (EV) čine provjeru još temeljitijom. Godinama su prikazivali istaknutu zelenu traku u preglednicima; danas je vizualni indikator pojednostavljen, ali proces izdavanja ostaje najrigorozniji.
Postoje i posebni certifikati kao što su SAN (Subject Alternative Name) ili Wildcard certifikati , koji vam omogućavaju da zaštitite nekoliko domena ili poddomena istim certifikatom, što je vrlo korisno u složenim infrastrukturama.
Kompatibilnost sa TLS-om u Windowsu i .NET Frameworku
U Windowsu, implementacija TLS-a se oslanja na Schannel (Secure Channel) , dobavljača operativnog sistema koji nudi protokole i pakete šifriranja svim aplikacijama koje ga koriste, uključujući .NET Framework i mnoge sistemske usluge.
.NET Framework ne uključuje vlastiti nezavisni TLS stek ; umjesto toga, oslanja se na Schannel. To znači da dostupne i pregovaračke verzije TLS-a zavise i od verzije Windowsa i od konfiguracije sistema.
Maksimalna TLS verzija koju .NET aplikacija može koristiti zavisi od kombinacije Windowsa i ciljne verzije .NET Frameworka. Na primjer, na Windowsu 10 sa .NET 3.5, tipičan maksimum je TLS 1.2, dok na Windowsu 11 sa .NET 4.8 ili 4.8.1, već može koristiti TLS 1.3.
Za TLS 1.3, preporučuje se ciljanje projekata sa .NET Frameworkom 4.8 ili novijim kada se radi o klasičnim aplikacijama, i u svakom slučaju, prepustiti operativnom sistemu da sam odluči o optimalnom protokolu za svaku vezu.
Najbolje prakse TLS-a u .NET-u, HttpClient-u, SslStream-u i WCF-u
Jedna od najvažnijih preporuka u .NET-u nije forsiranje određenih TLS verzija u vašem kodu . Ako počnete ručno specificirati TLS 1.0, 1.1 ili čak 1.2, možete spriječiti sistem da automatski pregovara o TLS 1.3 kada postane dostupan.
Umjesto ručnog odabira protokola, najbolje je pustiti da sistemske postavke odluče . Zbog toga se u API-jima poput ServicePointManager.SecurityProtocol preporučuje zadržavanje SecurityProtocolType.SystemDefault, bez mijenjanja ičega osim ako nije apsolutno neophodno.
Ako koristite SslStream preopterećenja koja prihvataju SslProtocols , najbolje je proslijediti SslProtocols.None ili SslProtocols.SystemDefault, ali nikada SslProtocols.Default, jer ovo drugo forsira starije pakete (SSL 3.0/TLS 1.0) i onemogućava TLS 1.2 i novije verzije.
U WCF aplikacijama, počevši od .NET 4.7.1, platforma koristi konfigurirane vrijednosti operativnog sistema kao referencu, osim ako nije drugačije navedeno u konfiguracijskoj datoteci ili kodu. Korištenje `SslProtocols.None` u NetTcp povezivanjima i prilagođenim konfiguracijama omogućava vam da ovu odluku prepustite sistemu.
Za starije verzije, kao što su .NET 3.5 ili 4.6.2 , ako protokol mora biti eksplicitno naveden, najmanje loša opcija je odabrati TLS 1.2, a u okruženjima gdje je podržan TLS 1.3, odlučite se za njega u modernijim okvirima. Microsoft čak dokumentira "proširenja" za dodavanje konstanti Tls12 i Tls13 u starijim verzijama okvira koristeći specifične numeričke vrijednosti.
AppContext i Windows Registry za kontrolu TLS-a
U .NET Frameworku 4.6.2 i novijim verzijama postoji nekoliko AppContext prekidača koji vam omogućavaju da utičete na ponašanje mrežnih API-ja u odnosu na TLS bez dodirivanja koda aplikacije.
Prekidač `Switch.System.Net.DontEnableSchUseStrongCrypto` , kada je postavljen na `false`, nalaže upotrebu "jake kriptografije": omogućava TLS 1.1 i 1.2 i onemogućava zastarjele protokole. U novijim verzijama okvira, ova sigurna postavka je obično zadana, ali ako aplikacija cilja starije verzije, preporučljivo ju je primijeniti.
Prekidač `Switch.System.Net.DontEnableSystemDefaultTlsVersions` , za koji se također preporučuje da bude `false`, označava da se trebaju koristiti TLS verzije koje operativni sistem smatra zadanim. Ako se ostavi na `true`, .NET nameće vlastitu internu listu protokola, koja može biti zastarjela.
U WCF-u postoje slični prekidači , kao što su Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols i Switch.System.ServiceModel.DontEnableSystemDefaultTlsVersions, koji određuju da li će se koristiti sistemski protokoli, oni konfigurisani u ServicePointManager-u ili verzije najvišeg nivoa kao što je TLS 1.0/1.2.
Kada se AppContext prekidači ne mogu koristiti (na primjer, u .NET 3.5 ili scenarijima bez pristupa konfiguracijskim datotekama), ključevi registra kao što su SchUseStrongCrypto i SystemDefaultTlsVersions u HKLM\SOFTWARE\Microsoft\.NETFramework (i njegovoj varijanti Wow6432Node) mogu se koristiti za nametanje upotrebe jake kriptografije i zadanih verzija sistema.
Konfigurisanje TLS protokola i šifrirnih paketa u Windowsu
Pored .NET-a, Windows omogućava vrlo preciznu kontrolu nad protokolima i šiframa koje Schannel nudi , i za klijente i za servere. To se prvenstveno radi putem registra i grupnih politika.
Za omogućavanje ili onemogućavanje određenih TLS verzija koristi se grana HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols. U okviru ove grane mogu se kreirati podključevi kao što su TLS 1.2, TLS 1.3 itd., a unutar svakog od njih, podključevi Client i Server mogu se postaviti na DWORD vrijednosti Enabled i DisabledByDefault za fino podešavanje ponašanja.
Redoslijed i odabir šifri je također moguće konfigurirati . Korištenjem grupnih pravila (Konfiguracija računara > Administrativni predlošci > Mreža > Vrijednosti konfiguracije SSL-a > Redoslijed SSL šifri), možete definirati tačnu listu i njen prioritet.
U Windowsu 10 i novijim verzijama, možete čak i prilagoditi redoslijed eliptičnih krivulja (ECC) neovisno o redoslijedu šifriranja. To se postiže registracijom ili brisanjem krivulja pomoću certutil.exe (korištenjem naredbi kao što su -displayEccCurve, -addEccCurve, -deleteEccCurve), a zatim korištenjem grupnih politika za distribuciju tih krivulja i njihovog redoslijeda preferencija.
Za napredniju i automatiziraniju administraciju , Windows također nudi PowerShell cmdlets specifične za TLS module koji vam omogućuju upite, omogućavanje i onemogućavanje šifri bez direktnog dodirivanja registra.
Ponovno pregovaranje, napadi i ranjivosti u TLS-u
Iako TLS nudi vrlo robustan okvir, nije bez rizika . Jedna od najproblematičnijih karakteristika historijski gledano bila je ponovno pregovaranje: mogućnost ponovnog pregovaranja o kriptografskim parametrima unutar već uspostavljene sesije.
Ranjivosti poput CVE-2009-3555 iskorištavale su nesigurna ponovna pregovaranja kako bi ubrizgale zlonamjerni promet ili infiltrirale naizgled legitimne HTTPS sesije. To je omogućilo napade tipa "čovjek u sredini" (MitM) u osjetljivim kontekstima kao što je online bankarstvo.
Nadalje, ponovno pregovaranje ima visoke računalne troškove za server . Neki distribuirani napadi uskraćivanja usluge (DDoS) sastojali su se od pokretanja mnogih uzastopnih ponovnog pregovaranja, iscrpljujući CPU i memoriju servera zahtjevima koji su vrlo jeftini za napadača.
Da bi ublažio ove probleme, TLS 1.3 direktno eliminira klasično ponovno pregovaranje i zamjenjuje ga sigurnijim i efikasnijim mehanizmima kao što je nastavak sesije korištenjem PSK-a i 0-RTT-a.
Druge poznate SSL/TLS ranjivosti uključuju FREAK, Logjam i napade snižavanja verzije šifriranja, koji su prisiljavali korištenje slabih ključeva ili starijih verzija protokola. Rješenje uključuje onemogućavanje naslijeđenih protokola, korištenje samo jakih paketa za šifriranje s PFS-om i pažljivo praćenje konfiguracije servera.
Najbolje prakse za TLS konfiguraciju na serverima i web stranicama
Stvarna efikasnost TLS-a uveliko zavisi od toga kako je konfigurisan . Server koji održava stare verzije ili slabe šifre može biti laka meta čak i ako ima važeći certifikat.
Prvi korak je osigurati da su omogućeni samo TLS 1.2 i 1.3 , a onemogućiti TLS 1.0, 1.1 i naravno svaki trag SSL 2.0/3.0. Ovo je već zahtjev u standardima kao što je PCI DSS, a moderni preglednici označavaju stranice koje se oslanjaju na starije protokole kao nesigurne.
Zatim, preporučljivo je ograničiti šifre na robusne skupove s modernim algoritmima i PFS-om (na primjer, ECDHE s AES-GCM-om). Alati poput GlobalSign-ovog SSL Server Testa ili Mozillinih generatora konfiguracije pomažu u provjeri i generiranju preporučenih konfiguracija.
Također je ključno dobro upravljati certifikatima : koristiti dovoljno duge privatne ključeve ili ECC, obnavljati ih prije isteka, opozvati ih ako se posumnja na kompromitiranje i idealno ih pohraniti u hardverske sigurnosne module (HSM) ili barem sa strogom kontrolom pristupa.
Dodatne mjere poput HSTS-a (HTTP Strict Transport Security) pomažu u sprječavanju napada degradacije HTTP-a sprječavajući preglednik da prihvati nešifrirane veze s domenom koji bi uvijek trebao koristiti HTTPS.
Uobičajeni izazovi pri implementaciji TLS-a u organizacijama
Ozbiljna implementacija TLS-a u srednjoj ili velikoj organizaciji nije samo pitanje "instaliranja certifikata i to je to". Postoje izazovi kompatibilnosti, performansi, upravljanja i praćenja koji se moraju uzeti u obzir.
Što se tiče kompatibilnosti, održavanje samo modernih TLS protokola može isključiti vrlo stare klijente (zastarjele preglednike, naslijeđene sisteme, ugrađene uređaje). Mora se donijeti odluka o tome u kojoj mjeri se kompatibilnost žrtvuje u korist sigurnosti.
Utjecaj na performanse je posebno primjetan na serverima s velikim prometom , jer rukovanje i enkripcija troše CPU. Troškovi su obično prihvatljivi, ali za kritične servise preporučljivo je prilagoditi parametre, omogućiti HTTP/2 ili HTTP/3 i pravilno dimenzionirati infrastrukturu.
Upravljanje životnim ciklusom certifikata postaje složeno u velikim razmjerima . Bez automatizacije (na primjer, korištenje ACME-a za izdavanje i obnavljanje), lako je završiti s isteklim certifikatima koji ruše servise ili održavaju zastarjele konfiguracije iz straha da će se "nešto pokvariti".
Konačno, šifrirani promet komplicira inspekciju i praćenje . IDS/IPS i drugi sigurnosni alati zahtijevaju dodatne tehnike kao što su TLS terminacija na proxyjima, kontrolirano zrcaljenje prometa ili specifična rješenja za inspekciju TLS-a bez narušavanja privatnosti ili slabljenja sigurnosti.
Temeljno razumijevanje TLS-a, načina na koji ga Windows implementira i kako se integrira sa .NET-om, WCF-om i ostatkom paketa je ključno za maksimiziranje njegovih prednosti i minimiziranje rizika. Kombinacija modernih protokola (TLS 1.2/1.3) , pažljiva konfiguracija, stalna ažuriranja i dobro upravljanje certifikatima čini svu razliku između "naizgled sigurne" infrastrukture i one koja je zaista otporna na trenutne prijetnje.
