Turvalisus pole enam valikuline, vaid kohustuslik kursus igale internetitehnoloogia spetsialistile. HTTP, HTTPS, SSL, TLS – kas sa tõesti mõistad, mis kulisside taga toimub? Selles artiklis selgitame tänapäevaste krüpteeritud sideprotokollide põhiloogikat nii tavainimesele kui ka professionaalile arusaadaval viisil ning aitame sul visuaalse vooskeemi abil mõista "lukkude taga" peituvaid saladusi.
Miks on HTTP "ebaturvaline"? --- Sissejuhatus
Mäletate seda tuttavat brauseri hoiatust?
"Teie ühendus pole privaatne."
Kui veebisait ei kasuta HTTPS-i, edastatakse kogu kasutaja teave võrgus tavalise tekstina. Häkker võib jäädvustada teie sisselogimisparoolid, pangakaardi numbrid ja isegi privaatsed vestlused. Selle peamiseks põhjuseks on HTTP krüptimise puudumine.
Kuidas siis HTTPS ja selle taga olev „väravavaht“ TLS võimaldavad andmetel turvaliselt internetis liikuda? Vaatleme seda kiht kihi haaval.
HTTPS = HTTP + TLS/SSL --- Struktuur ja põhikontseptsioonid
1. Mis on HTTPS sisuliselt?
HTTPS (turvaline hüperteksti edastusprotokoll) = HTTP + krüpteerimiskiht (TLS/SSL)
○ HTTP: See vastutab andmete edastamise eest, kuid sisu on nähtav lihttekstina
○ TLS/SSL: Pakub HTTP-suhtlusele „krüptimise lukustust“, muutes andmed mõistatuseks, mida saavad lahendada ainult õigustatud saatja ja saaja.
Joonis 1: HTTP ja HTTPS andmevoog.
Brauseri aadressiribal olev „Lukk” on TLS/SSL-i turvalipp.
2. Milline on TLS-i ja SSL-i seos?
○ SSL (Secure Sockets Layer): Varaseim krüptograafiline protokoll, millel on leitud tõsiseid haavatavusi.
○ TLS (transpordikihi turvalisus): SSL-i, TLS 1.2 ja täiustatud TLS 1.3 järeltulija, mis pakub olulisi edusamme turvalisuse ja jõudluse osas.
Tänapäeval on "SSL-sertifikaadid" lihtsalt TLS-protokolli implementatsioonid, millele on antud ainult laiendid.
Sügavale TLS-i: HTTPS-i taga peituv krüptograafiline maagia
1. Käepigistuse voog on täielikult lahendatud
TLS-i turvalise suhtluse aluseks on käepigistus seadistamise ajal. Vaatleme standardset TLS-i käepigistuse voogu:
Joonis 2: Tüüpiline TLS-i käepigistuse voog.
1️⃣ TCP-ühenduse seadistamine
Klient (nt brauser) algatab serveriga TCP-ühenduse (standardne port 443).
2️⃣ TLS-i käepigistuse faas
○ Klient Tere: Brauser saadab toetatud TLS-i versiooni, šifri ja juhusliku numbri koos serveri nime indikaatoriga (SNI), mis annab serverile teada, millisele hostinimele see juurde soovib pääseda (võimaldades IP-aadressi jagamist mitme saidi vahel).
○ Serveri tere ja sertifikaadi väljastamine: server valib sobiva TLS-i versiooni ja šifri ning saadab tagasi oma sertifikaadi (avaliku võtmega) ja juhuslikud numbrid.
○ Sertifikaadi valideerimine: brauser kontrollib serveri sertifikaatide ahelat kuni usaldusväärse juursertifitseerimisasutuseni, et veenduda selle võltsimise puudumises.
○ Eelvõtme genereerimine: brauser genereerib eelvõtme, krüpteerib selle serveri avaliku võtmega ja saadab serverile. Kaks osapoolt lepivad seansivõtme üle läbirääkimisi: mõlema osapoole juhuslike numbrite ja eelvõtme abil arvutavad klient ja server sama sümmeetrilise krüpteerimise seansivõtme.
○ Käepigistuse lõpetamine: Mõlemad pooled saadavad teineteisele teate „Lõpetatud” ja sisenevad krüpteeritud andmeedastuse faasi.
3️⃣ Turvaline andmeedastus
Kõik teenuseandmed krüpteeritakse sümmeetriliselt ja tõhusalt kokkulepitud seansivõtmega, isegi kui need keskelt kinni püütakse, on see lihtsalt hunnik "moonutatud koodi".
4️⃣ Seansi taaskasutamine
TLS toetab taas seanssi, mis võib oluliselt parandada jõudlust, võimaldades samal kliendil tüütu käepigistuse vahele jätta.
Asümmeetriline krüptimine (näiteks RSA) on turvaline, kuid aeglane. Sümmeetriline krüptimine on kiire, kuid võtmete jagamine on tülikas. TLS kasutab "kaheastmelist" strateegiat – esmalt asümmeetrilist turvalist võtmevahetust ja seejärel sümmeetrilist skeemi andmete tõhusaks krüptimiseks.
2. Algoritmi areng ja turvalisuse parandamine
RSA ja Diffie-Hellmani meetod
○ Lõuna-Aafrika Vabariik
Seda kasutati esmakordselt laialdaselt TLS-käepigistuse ajal seansivõtmete turvaliseks levitamiseks. Klient genereerib seansivõtme, krüpteerib selle serveri avaliku võtmega ja saadab selle nii, et ainult server saaks selle dekrüpteerida.
○ Diffie-Hellman (DH/ECDH)
Alates TLS 1.3-st ei kasutata võtmevahetuseks enam RSA-d, vaid eelistatakse turvalisemaid DH/ECDH algoritme, mis toetavad edasisaladust (PFS). Isegi kui privaatvõti lekib, ei saa ajaloolisi andmeid ikkagi avada.
| TLS-versioon | Võtmevahetuse algoritm | Turvalisus |
| TLS 1.2 | RSA/DH/ECDH | Kõrgem |
| TLS 1.3 | ainult DH/ECDH jaoks | Rohkem kõrgemale |
Praktilised nõuanded, mida võrgustikutöö praktikud peaksid omandama
○ Kiirema ja turvalisema krüptimise tagamiseks uuendage prioriteetselt TLS 1.3-le.
○ Luba tugevad šifrid (AES-GCM, ChaCha20 jne) ja keela nõrgad algoritmid ja ebaturvalised protokollid (SSLv3, TLS 1.0);
○ Konfigureerige HSTS, OCSP klammerdamine jne, et parandada üldist HTTPS-kaitset;
○ Uuendage ja vaadake regulaarselt üle sertifikaadiahela, et tagada usaldusahela kehtivus ja terviklikkus.
Kokkuvõte ja mõtted: Kas teie ettevõte on tõesti turvaline?
Alates lihttekstiga HTTP-st kuni täielikult krüpteeritud HTTPS-ini on turvanõuded iga protokolliuuendusega kaasas käinud. Tänapäevaste võrkude krüpteeritud suhtluse nurgakivina täiustab TLS end pidevalt, et tulla toime üha keerukama rünnakukeskkonnaga.
Kas teie ettevõte juba kasutab HTTPS-i? Kas teie krüptokonfiguratsioon on kooskõlas valdkonna parimate tavadega?
Postituse aeg: 22. juuli 2025
