Maailm liigub TLS 1.3, mis on väga hea asi! See artikkel pakub kõrgetasemelist ülevaadet TLS 1.3 ja arutelu selle uute funktsioonide tõhususe üle.
Transport Layer Security
Transpordikihi turvalisus või TLS, on krüptoprotokoll, mis kaitseb arvutivõrgu kaudu vahetatavaid andmeid. TLS on kuulsaks saanud kui S in HTTPS. Täpsemalt, TLS kasutatakse veebikasutajate andmete kaitsmiseks võrgurünnakute eest.
TLS kavandati turvalisemaks alternatiiviks eelkäijale Secure Sockets Layer (SSL). Aastate jooksul on turvauurijad avastanud hulgaliselt SSL-i mõjutavaid haavatavusi, mis motiveeris IETF-i kujundama TLS püüdes neid leevendada.
Irooniline on see, et TLS neid mõjutasid ka ohtlikud haavatavused, mis lõpuks viisid TLS 1.2 (st tööstusespetsialistide soovitatud vaikeversioon).
Enamik teadaolevaid protokolli haavatavusi leevendati aastal TLS 1.2, kuid see turvalisuse tase oli ikkagi vigase kujunduse peal olevate plaastrite seeria tulemus.
Vastuseks TLS 1.3 koostati nullist, et kujundada tänapäevane ja turvaline kujundus TLS protokoll. Viis aastat hiljem testimist on see lõpuks heaks kiidetud ja on nüüd peaaegu vaikimisi kasutatava Interneti-turvalisuse standardi lähedal.
TLS versioonid ja nende vastavad RFC-dokumendid leiate järgmisest loendist:
- TLS 1.0 avaldati kui RFC 2246 aastal 1996
- TLS 1.1 avaldati kui RFC 4346 aastal 2006
- TLS 1.2 avaldati kui RFC 5246 aastal 2008
- TLS 1.3 avaldati kavandatud standardina XNUMX RFC 8446 aastal 2018.
Kuidas vanemaks TLS versioonid töötavad?
Tõhusalt arutada programmi eeliseid TLS 1.3, peame kõigepealt rääkima sellest, kuidas vanemad TLS versioonid töötavad (ja kuidas nad ei tööta).
TLS on hübriid krüptosüsteem, mis tähendab, et see kasutab mõlemat asümmeetriline (avalik võti) ja sümmeetriline (parooli / fraasipõhine) krüptimine. See on tingitud asümmeetriline krüptograafia olles suurusjärkude võrra aeglasem kui tema sümmeetrilised ekvivalendid.
Järelikult TLS kasutab ainult avalikke võtmeid, et kliendid ja serverid saaksid sümmeetrilist võtit turvaliselt vahetada. Seda võtit saab seejärel kasutada kõigi järgnevate kommunikatsioonide krüptimiseks, vältides asümmeetrilise krüptimisega kaasnevaid jõudluskulusid.
TLS 1.2 toetab mitut võtmevahetuse algoritmi (nt RSA, DH jne) koos mitme algoritmiga (tuntud ka kui salakirjad) kasutatakse sõnumite krüptimiseks ja dekrüptimiseks. See suur hulk alternatiivseid võimalusi nõuab klientidelt ja serveritelt läbirääkimisi, nii et kõik osapooled kasutaksid sama TLS parameetrid.
See läbirääkimine on standardiseeritud protokollis, mida nimetatakse käepigistus. Kui te ei ole sellega tuttav, lugege palun Käesoleva artikli rohkem informatsiooni.
Mis siis viga on TLS 1.2?
Kuigi TLS 1.2 on osutunud enamikul juhtudest hästi toimivaks, muret tekitab üldine turvalisuse ja privaatsuse tase, mida see pakub pärast aastatepikkust lappimist ja muudatusi.
Lisaks turvakaalutlustele TLS 1.2 paneb ka ebavajaliku jõudluse ja võrgu üldkulud.
TLS 1.2i turvaküsimused
Aastate jooksul on teadlased (ja ründajad) paljudes avastanud haavatavuse TLS 1.2 komponendid, sealhulgas võtmevahetuse algoritmid, šifrid ja digitaalallkirjad. Mõned neist olid rakendusvead, millest olete ehk kuulnud, näiteks heartbleed or BERserk. Mõned olid siiski protokolli nõrgad kohad - see tähendab, et nad kasutavad varasemates aegades halbu kujundusotsuseid TLS versioonid (st enne TLS 1.2).
Ehkki suurem osa rakendamisest ja muud vead olid parandatud TLS 1.2, kahjuks ei saa protokolli ülesehituse haavatavusi heita ainult tarkvaraparanduse abil. Nagu selgub, pidi IETF selleks täielikult ümber kujundama käepigistuse protokolli TLS 1.3.
Muresid on olnud palju TLS turvalisus, kuid üks mõjukamaid oli selle mõistmine TLS 1.2 (ja kõik varasemad versioonid, sealhulgas SSL) on alandatud versioonide rünnakute suhtes haavatav, kuna selle käepigistusprotokolli kujunduses on viga. Täpsemalt, TLS 1.2 ei kasuta digitaalseid allkirju käepigistuse terviklikkuse kaitsmiseks. Allkirjad kaitsevad osa käepigistusest alles pärast šifrikomplekti läbirääkimist.
Selle tagajärjel saavad ründajad manipuleerida kõigi kolmandate osapoolte šifrikomplekti läbirääkimistega, mis toimuvad samas arvutivõrgus (nt lennujaama wifi), ja sundida kasutama ebaturvalist šifrit. Seejärel saavad nad selle haavatava šifri murda ja saada põhjendamatu juurdepääsu kogu vestlusele.
TLS 1.2 tulemuslikkuse probleemid
Lisaks neile turvalisuse kaalutlustele TLS 1.2 vajadus pidada läbirääkimisi paljude vahel TLS parameetrid võivad kehtestada HTTPS-le (või muule funktsioonile) jõudluse üldkulud TLS kaitstud) side.
TLS 1.2 neljaetapiline käepigistus nõuab kahte edasi-tagasi vahetust, esmalt šifripaketi valimiseks ning seejärel sertifikaatide ja sümmeetriliste võtmete (või võtmejagude) vahetamiseks.
See tähendab, et iga TLS ühendus luuakse, kaks täiendavat tehingut koos serveriga on kohustuslikud. Tulemusena, TLS ühendused vajavad rohkem ribalaiust ja võimsust kui (krüptimata) HTTP, mis võib olla eriti kulukas asjade Interneti (IoT) rakendustele, kus madal energiatarve ja ribalaiuse tarbimine on rasked piirangud.
TLS 1.2 privaatsusega seotud probleemid
Lõpuks TLS 1.2 on kritiseeritud veebikasutajate privaatsuse kahjustamise eest.
Täpsemalt, TLS pakub laiendit, mida tuntakse Serveri nime tähis või SNI. SNI lubab serveri hosti nime lisada algsesse SSL-käepigistusse. Seda laiendust kasutatakse virtuaalse majutuse jaoks, kus serverid võivad teenida mitut domeeni samal IP-aadressil ja pordil, esitades samal ajal iga domeeni jaoks erineva sertifikaadi.
In TLS 1.2, SNI-d saadetakse krüptimata, nii et hoolimata HTTPS-i kasutamisest, võib võrguründaja levitada seda teavet ja jälgida veebilehti, mida kasutaja külastab.
Kuidas TLS 1.3 lahendada kõik?
TLS 1.2 (ja varasemad versioonid) keskendusid tagumise ühilduvuse säilitamisele. Kõik versioonid tuginesid varasematele versioonidele koos väikeste parandustega, püüdes kõrvaldada vahemikus avaldatud turvaauke TLS versioonid.
Kahetsusväärselt tähendas see ka seda, et uuemates versioonides päriti ka halbu protokolli kujundamise otsuseid (nt kaitsmata käepigistus).
TLS 1.3 loobub tagasiulatuvast ühilduvusest korraliku turvakujunduse kasuks. See on loodud nullist, et pakkuda funktsioone, mis on sarnased (kuid ei ühildu) TLS 1.2, kuid oluliselt parema jõudluse, privaatsuse ja turvalisusega.
TLS 1.3i turvalisus
Tuumikpõhimõte TLS 1.3 on lihtsus. Uues versioonis kõik võtmevahetuse algoritmid, välja arvatud Diffie-Hellman (DH) võtmevahetus eemaldati. TLS 1.3 on määratlenud ka proovitud ja testitud DH parameetrite komplekti, mis välistab vajaduse parameetritega serveriga läbi rääkida.
Mis veel, TLS 1.3 ei toeta enam tarbetuid või haavatavaid šifreid, näiteks CBC-režiim ja RC4 šifr. Need šifrid on teadaolevalt vastuvõtlikud rünnakutele, kuid enamikus toetati neid ikkagi TLS pärandi ühilduvuse rakendused. Õnneks on hiljutine varajastust mõjutavate madalamate rünnakute kiirustamine TLS versioonid motiveerisid IETF-i sellised šifrid täielikult eemaldama TLS 1.3.
Lisaks TLS 1.3 nõuab, et serverid allkirjastaksid kogu käepigistuse krüptograafiliselt, sealhulgas šifriläbirääkimised, mis takistab ründajatel muutmast kõiki käepigistuse parameetreid. See tähendab seda TLS 1.3 on arhitektuuriliselt läbitungimatu varem alandatud rünnakutele TLS versioonid.
Lõpuks parandati ka allkirju ise uue standardi, nn RSA-PSS. RSA-PSS allkirjad on immuunsed krüptograafiliste rünnakute vastu, mis mõjutasid varasemaid allkirjastamisskeeme TLS versioonid.
TLS Etendus puudub
Lisaks paremale turvalisusele on vähendatud parameetrite kogumit ja lihtsustatud käepigistust TLS 1.3 aitab kaasa ka üldise jõudluse paranemisele. Kuna on ainult üks võtmevahetuse algoritm (koos sisseehitatud parameetritega) ja vaid käputäis toetatud šifreid, on absoluutne ribalaius vajalik TLS 1.3 kanalit on varasemate versioonidega võrreldes tunduvalt vähem.
Lisaks TLS 1.3 toetab nüüd uut käepigistusprotokolli, nn 1-RTT režiim. 1-RTT-s saab klient esimeses käepigistussõnumis saata DH-võtme jagamist, kuna serveri parameetrites võib olla üsna kindel. Harvadel juhtudel, kui server neid ei toeta, võib see põhjustada tõrke, nii et klient saadab teistsuguse konfiguratsiooni.
Selle asemel, et kõigepealt läbi rääkida parameetrid ja seejärel vahetada võtmeid või võtmeosasid, TLS 1.3 võimaldab kliendil seadistada a TLS kanal ainult ühe edasi-tagasi tehinguga (kahe asemel, nagu varem tehti). Sellel võib olla suur kumulatiivne mõju töötlemis-, toite- ja võrguressurssidele, mis on vajalikud kliendil serveriga suhtlemiseks. TLS 1.3.
Toimivuse optimeerimine ei peatu siin, kuid teine TLS 1.3 funktsioon, mida nimetatakse 0-RTT jätkamise režiim. Kui brauser külastab serverit esimest korda ja täidab a TLS käepigistuse korral saavad nii klient kui ka server salvestada eeljagatud krüptimisvõtme kohapeal.
Kui brauser külastab serverit uuesti, saab ta seda taastamisvõtit kasutada oma esimeses sõnumis krüptitud rakenduse andmete saatmiseks serverisse. Sellel latentsus on sama kui krüptimata HTTP-l, kuna esialgsed käepigistused pole vajalikud.
Tuleb märkida, et teatavat turvalisust on olnud muresid umbes 0-RTT režiimi kohta minevikus.
TLS 1.3 privaatsus
Mineviku vigadest õppimine, TLS 1.3 pakub nüüd laiendamine mis krüpteerib SNI-teabe. Õigel kasutamisel takistab see laiendus ründajatel kaugserveri domeeninime lekitamist, mistõttu neil pole HTTPS-i kasutajaloo jälgimise viisi. See funktsioon pakub Interneti-kasutajatele suuremat privaatsust kui eelmised versioonid TLS.
Järeldus
Kui TLS 1.2 on kõiki neid aastaid auväärselt teeninud, TLS 1.3 on ilmselt turvalisem ja tõhusam. TLS 1.3 on brauseri eksperimentaalsetes rakendustes laialdaselt testitud ja see on nüüd asendamiseks valmis TLS 1.2 kui valitud võrguturbeprotokoll. Kirjastamine TLS 1.3 on suur samm lähemale kiirema ja turvalisema Interneti jaoks kõigile.
Täname, et valisite SSL.com, kus usume a ohutum Internet on a parem Internet.
