Objavljeno:

Postavitev varnega HTTPS strežnika

V tokratnem prispevku si bomo pogledali kako postaviti varen HTTPS strežnik. Razkritja Edwarda Snowdna so pokazala, da je ameriška tajna služba NSA sposobna izvajati različne napredne napade s katerimi uspešno prestreza tudi šifriran internetni promet. Tako NSA s pomočjo QUANTUM strežnikov izvaja napade s posrednikom (tim. MITM napade), s pomočjo programa BULLRUN izvaja dešifriranje šifriranega internetnega prometa, itd.

Vendar pa pozorno branje Snowdnovih razkritij kaže tudi, kako se je pred takšnim nadzorom mogoče zaščititi. Kot kaže ena izmed prosojnic, ki opisujejo zmogljivosti programa MUSCULAR, ki ga skupaj z NSA izvaja še britanska tajna služba GCHQ, je HTTPS šifriran promet v določenih primerih lahko trd oreh tudi za NSA.

NSA: SSL added and removed here :-)

NSA: SSL added and removed here 🙂

Konec koncev to dokazuje tudi dogajanje okrog ponudnika varne elektronske pošte Lavabit, od katerega je FBI leta 2013 zahteval kopijo zasebnega ključa HTTPS strežnika (uporabnik njihovih poštnih storitev je bil tudi Edward Snowden). Dejstvo, da so zahtevali kopijo strežniškega šifrirnega ključa namreč dokazuje, da so kriptoanalitične zmogljivosti ameriških obveščevalnih agencij vendarle omejene.

Seveda pa se je pomembno zavedati, da mora biti šifrirna zaščita ustrezna, oziroma, da mora biti šifriranje izvedeno na ustrezen način. Dejstvo, da pravilno implementirani šifrirni sistemi delujejo, je potrdil tudi Edward Snowden:

Šifriranje deluje. Pravilno implementirani močni šifrirni sistemi so ena izmed maloštevilnih stvari na katere se lahko zanesete. Žal pa so varnostni mehanizmi zaključnih točk na omrežju tako strahovito slabi, tako da NSA pogosto najde obvode okrog njih.

[“Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it.”]

–Edward Snowden

V nadaljevanju si bomo zato pogledali kateri so nekateri najbolj nevarni napadi na HTTPS protokol ter kako pravilno implementirati HTTPS zaščito na spletnih strežnikih.

Nekaj teorije

HTTPS (HyperText Transfer Protocol Secure) je protokol za šifrirano spletno komunikacijo. Če za navadno spletno komunikacijo (HTTP) velja, da privzeto poteka preko TCP vrat 80, HTTPS privzeto uporablja TCP vrata 443. Šifriranje poteka preko SSL (Secure Sockets Layer) ali TLS (Transport Layer Security) kriptografskega protokola, pri samem šifriranju pa se uporabljajo različni šifrirni algoritmi z različnimi dolžinami ključev. Na področju varnosti HTTPS je bilo v zadnjih letih odkritih kar nekaj ranljivosti in narejenih kar nekaj izboljšav, zato je za varnost HTTPS povezav zelo pomembno, da HTTPS strežnik ustrezno nastavimo. Seveda pa je varnost odvisna tudi od odjemalcev – več o tem na koncu prispevka.

Nekateri napadi na HTTPS protokol

V nadaljevanju si bomo pogledali nekatere najbolj nevarne napade na HTTPS protokol.

Ponovno pogajanje za vzpostavitev HTTPS seje s strani odjemalca (ang. client-initiated session renegotiation attack)

Kriptografski protokoli SSL 3 in TLS 1.0 do 1.2 so ranljivi na tim. ponovno pogajanje za vzpostavitev SSL seje s strani odjemalca (ang. client-initiated session renegotiation).  Izvedba napada poteka tako, da napadalec prestreže začetek HTTPS seje, vzpostavi šifrirano povezavo s strežnikom, spletnemu strežniku pošlje šifriran spletni zahtevek, nato pa sproži ponovno pogajanje za vzpostavitev šifrirane seje in komunikacijo prepusti žrtvi. Prometa žrtve sicer nato ne bo uspel dešifrirati, bo pa spletni strežnik začetni promet, poslan s strani napadalca, razumel kot promet žrtve. Iz tega razloga opisani napad ni čisto pravi napad s posrednikom (tim. MITM napad), ima pa podobne posledice.

Napad torej izgleda takole. Najprej napadalec vzpostavi šifrirano sejo z HTTPS strežnikom in pošlje npr. naslednji spletni zahtevek:

GET /index.php?narocilo=burek&vrsta=sirni&naslov=napadalcev%20naslov HTTP/1.1 
X-Ignore-This:

Zadnjo vrstico pusti nezaključeno (brez znaka “enter“). Nato sproži zahtevek za ponovno pogajanje za vzpostavitev HTTPS seje in komunikacijo prepusti odjemalcu žrtve. Žrtev napada nato pošlje naslednji (pravi) zahtevek, skupaj s sejnim piškotkom:

GET /index.php?narocilo=burek&vrsta=mesni&naslov=zrtvin%20naslov HTTP/1.1 
Cookie: zrtvin_piskotek

Oba spletna zahtevka pa spletni strežnik (dešifrirana) vidi takole:

GET /index.php?narocilo=burek&vrsta=sirni&naslov=napadalcev%20naslov HTTP/1.1
X-Ignore-This: GET /index.php?narocilo=burek&vrsta=mesni&naslov=zrtvin%20naslov HTTP/1.1 
Cookie: zrtvin_piskotek

Posledica: spletni strežnik upošteva spletni zahtevek napadalca in sejni piškotek žrtve. Povedano drugače – podjetje bo na naslov napadalca poslalo sirni burek, naročilo žrtve se ne bo upoštevalo, upoštevala pa se bo njegova identifikacija s piškotkom, torej bo račun pa poravnala žrtev napada.

Več o napadu, od koder je tudi povzet zgornji prikaz, si je mogoče prebrati v članku Understanding the TLS Renegotiation Attack.

Zaščita pred napadom je – kot določa priporočilo RFC 5746 – takšna konfiguracija HTTPS strežnika, ki ne dovoli ponovnega pogajanja za vzpostavitev HTTPS seje.

Napad z vsiljevanjem šibkejše različice protokola (ang. version rollback attack).

V primeru tega napada, se napadalec postavi med strežnik in odjemalca ter odjemalca prepriča, da strežnik podpira samo starejše, ranljive različice HTTPS protokola. Hkrati pa tudi strežnik prepriča, da odjemalec podpira samo starejše, ranljive različice HTTPS protokola. Komunikacija je zato sicer šifrirana, a steče s pomočjo ranljivega protokola. Namesto šibkejšega protokola, npr. SSL v2, lahko napadalec uporabi šibkejše šifrirne algoritme ali šibkejše algoritme za izmenjavo šifrirnih ključev.

BEAST napad

BEAST (Browser Exploit Against SSL/TLS) sta leta 2011 prikazala varnostna raziskovalca Thai Duong in Juliano Rizzoplet. Gre za napad s pomočjo tim. znanega čistopisa (ang. known plaintext) oz. vnaprej izbranega čistopisa (ang. chosen-plaintext attack), kjer napadalec s pomočjo JavaScript vstavka preko brskalnika strežniku pošilja vnaprej znane podatke (čistopis), hkrati pa te podatke prestreže tudi v šifrirani obliki (kriptogram). Na podlagi čistopisa in kriptograma nato izvede kriptoanalizo ter s tem rekonstruira sejni ključ. S tem podatkom nato lahko npr. ukrade spletni piškotek žrtve s čimer žrtvi ukrade identiteto.

Že pred tem, je podobno ranljivost leta 2002 predstavil Phillip Rogaway, že leta 1999 pa sta David Wagner in Bruce Schneier v svoji analizi SSL v3 protokola (Analysis of the SSL 3.0 protocol) opozorila na to, da SSL vsebuje veliko tim. znanega čistopisa (ang. known plaintext). Opisana ranljivost je bila sicer odpravljena v TLS 1.1.

CRIME in BREACH napadi

Ista raziskovalca, ki sta leta 2011 prikazala BEAST napad, sta kasneje predstavila še CRIME napad (Compression Ratio Info-Leak Mass Exploitation), Gluck, Harris in Prado pa so leta 2013 predstavili še BREACH napade (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext; pri BREACH napadih gre za serijo ranljivosti in ne en sam napad). Oba napada napadalcu omogočata kriptoanalizo šifriranih podatkov oz. rekonstrukcijo spletnih piškotkov v primeru, da je pri šifriranju uporabljena kompresija podatkov. S pomočjo BREACH napada, je HTTPS šifrirano sejo mogoče ugrabiti v manj kot minuti.

Rešitev pred napadom je izklop kompresije šifriranih podatkov.

Napadi na bitno zapolnjevanje

Napad z ugibanjem bitnega zapolnjevanja (ang. padding oracle attack) je napad, ki izkorišča ugibanje vsebine tim. bitnega zapolnjevanja (ang. padding) pri šifriranju sporočil (gre za dodajanje bitov, ki ne nosijo informacije, v podatkovni niz, z namenom, da se zagotovi zvezni bitni tok). Ranljivi so navadno ECB (Electronic Code Book; vsak blok sporočila šifriramo z istim ključem) in CBC (Cipher Block Chaining; začetni blok sporočila ter naključno število imenovano inicializacijski vektor (IV) seštejemo z operacijo XOR, vsak naslednji blok sporočila seštejemo s šifriranim prejšnjim blokom in ga zašifriramo) načini šifriranja.

Eden bolj znanih napadov na bitno zapolnjevanje je Lucky 13 napad. Gre za tim. časovni napad (ang. timing attack) na TLS protokol, podrobnosti so bile objavljene leta 2013.

Napadi na RC4

RC4 je leta 1987 razvil znani ameriški kriptolog Ronald Rivest. Uporablja se v številne namene, med drugim tudi v WEP šifriranju brezžičnih komunikacij, ki so ga uspešno zlomili že leta 2001. Problem RC4 je, da je v določenih načinih uporabe zelo ranljiv. Zlasti je problematično, če se pri šifriranju z RC4 uporablja ne-naključne šifrirne ključe oziroma če se isti šifrini ključi uporabijo večkrat.

Varnostne ranljivosti v RC4 so raziskovalci začeli odkrivati že leta 1995, resnejši napadi proti RC4 pa so bili odkriti leta 2001 in 2005. V letu 2013 je kriptoanaliza Information Security Group iz University of London pokazala, da so praktični napadi na RC4 že povsem mogoči, zato je podjetje Microsoft konec leta 2013 priporočilo, da se RC4 preneha uporabljati.

Kljub temu, da se je RC4 v preteklosti celo priporočal kot možna obramba pred BEAST napadom, bi bilo uporabo RC4 na strežniški strani danes priporočljivo onemogočiti. Težava je žal v tem, da s tem onemogočimo dostop nekaterim starejšim spletnim brskalnikom, zato je priporočljivo RC4 ponuditi v uporabo, a le kot skrajno možnost in še to zgolj tistim brskalnikom, ki boljših šifrirnih algoritmov ne podpirajo. Potrebno je tudi vedeti, da napadi na RC4 postanejo uporabni v praksi šele takrat, ko ima napadalec na voljo dovolj veliko količino prestreženih šifriranih podatkov. Zato varnost ob uporabi RC4 zelo povečamo z uporabo tim. poudarjene zaupnosti (ang. perfect forward secrecy; o tem nekoliko več kasneje).

Napadi na kriptografsko implementacijo

Močna kriptografija sicer močno pripomore k varnosti, vendar pa do večine napak pride pri implementaciji. S pomočjo napak v implementaciji je mogoče odkriti notranje stanje kriptografskega sistema, kar napadalcu v končni fazi lahko omogoči celo rekonstrukcijo dešifriranih podatkov ali šifrirnih ključev.

Na napake v implementaciji sicer nimamo vpliva, lahko pa poskrbimo, da bo programska oprema na našem sistemu vedno posodobljena.

V začetku aprila 2014 so tako varnostni raziskovalci odkrili eno izmed resnejših napak v implementaciji kriptografske knjižnice OpenSSL. Gre za tim. Heartbleed ranljivost, ki omogoča napad na SSL/TLS šifriranje. Ranljivost je poimenovana Heartbleed (heartsrce, bleedkrvavitev) zato, ker se je pojavila v OpenSSL implementaciji TLS/DTLS razširitvi RFC6520, ki se imenuje Heartbeat (heartbeat – srčni utrip) razširitev.

Ranljivost omogoča branje vsebine pomnilnika napadenega sistema komurkoli in to preko interneta. S pomočjo napada je mogoče rekonstruirati vsebino šifrirnih ključev (oziroma X.509 certifikatov), posledično pa napadalec lahko dešifrira šifriran promet ali izvede krajo identitete (tim. impersonacijo) strežnika ali odjemalca. (Če pa Heartbeat ranljivost vsebuje odjemalec, pa lahko vsebino njegovega pomnilnika bere strežnik, zato je potrebno varnostno posodobiti tudi odjemalce.)

Ranljivost je v OpenSSL pojavila decembra 2011. Odpravljena je bila v OpenSSL različici 1.0.1g. Naj omenimo, da uporaba tim. poudarjene zaupnosti ščiti pretekle komunikacije pred kasnejšim dešifriranjem s strani napadalca, kljub temu pa se priporoča, da na ranljivih sistemih po odkriti ranljivosti zamenjamo šifrirne ključe. Po nekaterih prvotnih ocenah naj bi bila kraja šifrirnih ključev z izkoriščanjem te ranljivosti sicer težko izvedljiva, vendar so varnostni raziskovalci v relativno kratkem času uspeli dokazati, da je tudi praktično mogoča. Ranljivost svojih sistemov na omenjeni napad lahko preverimo na http://filippo.io/Heartbleed/.

Napad s posrednikom

Pri napadu s posrednikom (tim. man-in-the-middle napad) napadalec najprej postavi med odjemalca in strežnik, kjer prestreza komunikacijo med njima. Nato se obema prične lažno predstavljati – strežniku se predstavi kot odjemalec, odjemalcu pa kot strežnik. Na ta način odjemalec vzpostavi sicer šifrirano povezavo, a z napadalčevim lažnim strežnikom, strežnik pa prav tako vzpostavi drugo šifrirano povezavo, vendar ne s pravim odjemalcem, pač pa z napadalčevim lažnim odjemalcem. Na tej vmesni točki pa se promet dešifrira in napadalec ga lahko prestreže v nešifrirani obliki.

Shematski prikaz napada s posrednikom.

Shematski prikaz napada s posrednikom.

Ker napadalec na lažnem strežniku uporabi svoje lastno digitalno potrdilo, je rešitev pred tem napadom načeloma zelo enostavna – uporabnik mora le preveriti ali je digitalno potrdilo HTTPS strežnika s katerim je vzpostavil povezavo pravo ali ne. Načeloma je takšno preverjanje razmeroma enostavno če imamo opravka z tim. overjenimi digitalnimi potrdili, torej strežniškimi digitalnimi potrdili, ki jih je podpisal eden izmed zaupanja vrednih overiteljev (CA, Certificate Authority). Bolj problematično je to pri spletnih straneh, ki uporabljajo samopodpisana digitalna potrdila.

Vendar pa varnost overjenih digitalnih potrdil temelji predpostavki zaupanja v tim. zaupanja vredno tretjo stranko, torej v overitelja. Problem nastopi, če overitelj ni zaupanja vreden – bodisi zato, ker je zlonameren, bodisi zato ker je malomaren ali pa samo prisiljen sodelovati s kakšno izmed tajnih služb. V tem primeru celoten opisani varnostni model pade.

Žal varnost tim. zaupanja vrednih overiteljev ni vedno samoumevna, to dokazuje tudi dogodek iz leta 2008, ko je bilo enega izmed zaupanja vrednih overiteljev mogoče preslepiti in prepričati, da je podpisal HTTPS digitalno potrdilo za poljubno domeno. Avtor tega prispevka si je takrat izdal lažna, a veljavna (torej overjena) digitalna potrdila kar za nekaj slovenskih spletnih bank… 🙂 (Obvestilo: potrdila nikoli niso bila uporabljena za izvedbo kakršnegakoli napada na spletno bančništvo ali za izvedbo ali poskus izvedbe kakršnegakoli kaznivega dejanja!).

Kasneje se je tudi izkazalo, da je mogoče podpise overiteljev na digitalnih potrdilih tudi ponarediti. V letu 2008 so namreč številni overitelji za digitalno podpisovanje digitalnih potrdil še vedno uporabljali algoritem MD5, v katerem so raziskovalci pred tem že našli kolizije. Skupina raziskovalcev je tako na CCC konferenci leta 2008 pokazala, kako je s pomočno kolizij v MD5 algoritmu mogoče izdelati ponarejene a veljavno podpisane digitalna potrdila za katerokoli spletno stran.

Naj na tem mestu omenimo, da obstaja tudi obramba pred tovrstnimi napadi. Več o tem pa na koncu tega prispevka.

Ukrepi za povečanje HTTPS varnosti

Na kratko si oglejmo nekaj pomembnih ukrepov in mehanizmov s katerimi zagotovimo višjo stopnjo varnosti HTTPS povezave.

Varnost strežniških digitalnih potrdil

**Strežniška digitalna potrdila naj bodo dolga vsaj 2048 bitov, še bolje pa je, če so dolžine 4096 bitov. Smiselno je, da ne uporabljamo samopodpisanih potrdil, pač pa da naše strežniško potrdilo podpiše eden izmed tim. zaupanja vrednih overiteljev, da se vzpostavi tim. veriga zaupanja (ang. chain of trust). Na ustrezno verigo zaupanja je potrebno paziti tudi v primeru uporabe tim. vmesnih potrdil (ang. intermediate certificates). Zasebni ključ digitalnega potrdila je na strežniku potrebno ustrezno varovati

Kriptografski protokoli

Pri uporabi kriptografskih protokolov je pomembno, da onemogočimo uporabo protokola SSL v2, saj je zelo ranljiv. Smiselno je tudi onemogočiti SSL v3, saj ima tudi ta protokol resne varnostne ranljivosti. Potrebno pa je omogočiti uporabo TLS protokolov, zlasti najnovejšega TLS 1.2.

Kriptografski algoritmi

Za šifriranje v okviru HTTPS povezave skrbijo različni kriptografski algoritmi, uporabljene pa so lahko različne dolžine šifrirnih ključev. Smiselno je, da omogočimo take algoritme, ki so dovolj varni, uporabo ranljivih algoritmov pa na strežniški strani onemogočimo. Prav tako je na strežniku smiselno nastaviti preferenčni seznam algoritmov. Res je sicer, da lahko z onemogočanjem določenih algoritmov (podobno velja tudi za kriptografske protokole) onemogočimo povezovanje nekaterim starejšim spletnim brskalnikom. Kljub temu pa je z ustreznimi nastavitvami HTTPS strežnika, zlasti s preferenčnim seznamom algoritmov mogoče brskalnikom, ki podpirajo boljše algoritme “vsiliti” vzpostavitev HTTPS povezave na bolj varen način, hkrati pa starejšim brskalnikom še vedno omogočiti povezovanje, pa čeprav bo kriptografska kvaliteta povezave nekoliko slabša.

Dodatni mehanizmi za zaščito HTTPS

S pomočjo ustreznih nastavitev je na strežniški strani mogoče onemogočiti BEAST, CRIME in BREACH napade. Smiselno je omogočiti tudi tim. poudarjeno zaupnost (ang. perfect forward security oz. forward secrecy). Poudarjena zaupnost pomeni, da se šifrirni ključi samodejno spreminjajo vsako novo sejo oz. na določeno časovno obdobje. Če napadalec uspe razbiti enega izmed šifrirnih ključev, bo lahko dešifriral le promet, ki je bil šifriran v dani seji. Poudarjena zaupnost pa ščiti šifrirane komunikacije celo če napadalec kdaj kasneje uspe pridobiti strežniško digitalno potrdilo.

Smiselno je tudi omogočiti tim. Strict Transport Security (strežnik nastavimo tako, da brskalniku pošlje HTTP Strict-Transport-Security vzglavje), razmisliti pa velja tudi o tem, da na spletnem strežniku povsem onemogočimo HTTP promet in vse zahtevke brskalnikov preusmerimo na HTTPS protokol.

Paziti je potrebno tudi na problematiko tim. ponovnega vzpostavljanja SSL seje. Zlasti je problematično tim. ponovno pogajanje za vzpostavitev SSL seje s strani odjemalca (SSL client-initiated session renegotiation), saj ta napaka v konfiguraciji omogoča tim. napad s posrednikom (MITM napad). Da bi se temu izognili, mora biti strežnik nastavljen v skladu s priporočilom RFC 5746 in ne sme dovoliti ponovnega pogajanja za vzpostavitev SSL seje. Problematična sta tudi tim. Secure ter Insecure Client-Initiated Renegotiation, saj omogočata napad z onemogočanjem storitve (tim. DoS napad).

Smiselno je še preveriti ali ima strežnik nastavljeno tim. netoleranco previsoke TLS različice (ang. TLS version intolerance). To je sicer v osnovi bolj problematika neupoštevanja TLS standarda oziroma neustreznih odgovorov strežnika na HTTPS zahtevke za povezavo z neobstoječimi različicami TLS protokolov, vendar pa bi bili neustrezno nastavljeni strežniki v prihodnosti lahko neodporni na napad z vsiljevanjem šibkejše različice protokola (ang. version rollback attack). Posebej pomembno je tudi, da vedno uporabljamo posodobljene zaledne kriptografske knjižnice. S tem se na primer izognemo najnovejšim napadom, npr. Lucky 13 napadu.

Optimizacija HTTPS povezave

Da bi uporabnikom zagotovili kar najboljšo uporabniško izkušnjo, je HTTPS povezavo smiselno še nekoliko optimizirati. V tokratnem prispevku si bomo pogledali kako vključiti nadaljevanje SSL seje (tim. session resumption) – gre za vrsto optimizacije, ki pohitri kasnejše (ponovno) vzpostavljanje HTTPS povezave – ter kako omogočiti tim. OCSP pripenjanje (ang. OCSP stapling) – gre za optimizacijo oz. pohitritev preverjanja veljavnosti digitalnega potrdila preko OCSP strežnikov (Online Certificate Status Protocol je poseben protokol, ki omogoča preverjanje veljavnosti izdanih digitalnih potrdil).

V nadaljevanju si bomo ogledali kako te teoretične napotke implementirati v praksi. Pri tem bomo uporabili odprtokodna orodja (OpenSSL ter spletna strežnika Nginx ter Apache2).

Ustvarjanje in podpisovanje digitalnih potrdil

V prvem koraku si bomo ogledali kako ustvariti digitalna potrdila za HTTPS strežnik. Pomembno: pri ustvarjanju digitalnega potrdila moramo biti pozorni na vpis podatkov v polje “Common Name” (ime domene oz. FQDN). Digitalno potrdilo za HTTPS spletni strežnik bo veljavno eno leto, velikost ključa bo 4096 bitov.

Na voljo imamo dve možnosti. Prva je, da ustvarimo samopodpisano digitalno potrdilo (v obeh primerih bomo takoj po ustvarjanju parov ključev dostop do zasebnega strežniškega ključa omejili z ukazom chmod). To storimo z ukazom:

openssl req -days 365 -new -newkey rsa:4096 -x509 -nodes -out web-server.crt -keyout web-server.key
chmod 600 web-server.key

Druga možnost je, da ustvarimo zahtevek za podpisovanje digitalnega potrdila (tim. digital certificate signing request), naše digitalno potrdilo pa nato podpiše eden izmed zaupanja vrednih overiteljev (CA). Overitelji sicer za digitalno podpisovanje zahtevajo plačilo, obstajajo pa tudi overitelji, ki overjanje opravijo brezplačno. Eden takih je tudi StartSSL, kjer se najprej registriramo s svojim e-naslovom, nato pa potrdimo še lastništvo domene. Ustvarjanje zahtevka za podpisovanje digitalnega potrdila:

openssl req -days 365 -new -newkey rsa:4096 -nodes -out web-server.csr -keyout web-server.key
chmod 600 web-server.key

Sedaj vsebino CSR datoteke posredujemo svojemu overitelju digitalnih potrdil:

cat web-server.csr

Vsebina datoteke izgleda približno takole:

-----BEGIN CERTIFICATE REQUEST-----
MIIE6TCCAtECAQAwgaMxCzAJBgNVBAYTAlNJMRIwEAYDVQQIDAlTbG92ZW5pamEx
...
...
zZ3L/DvToC+vK6rQICAYFiouUoIrOY/L5ivoldWYy39yqOLF4s+BiM1JtzMeyj8t
QOGPolvnhmGr5SG7TA==
-----END CERTIFICATE REQUEST-----

Ko overitelj potrdilo overi, nam posreduje podpisan javni ključ, ki ga shranimo v datoteko web-server.crt:

nano web-server.crt

Vsebino, digitalni prstni odtis ter overitelje našega podpisanega digitalnega potrdila lahko pogledamo z ukazom:

openssl x509 -noout -fingerprint -text -in web-server.crt

Iz izpisa vidimo SHA-1 digitalni prstni odtis digitalnega potrdila…

SHA1 Fingerprint=F8:1F:1E:27:43:77:69:45:83:C7:EC:8B:86:9B:9A:7E:54:4C:ED:9C

…serijsko številko digitalnega potrdila…

Serial Number: 905335 (0xdd077)

…ter overitelje našega digitalnega potrdila in podatek o OCSP strežniku:

Authority Information Access: 
  OCSP - URI:http://ocsp.startssl.com/sub/class1/server/ca
  CA Issuers - URI:http://aia.startssl.com/certs/sub.class1.server.ca.crt

Uporaba vmesnih potrdil

Če overitelja za digitalno overjanje uporablja tim. vmesna potrdila (ang. intermediate certificate), imamo na voljo dve možnosti. Če spletni strežnik podpira uporabo vmesnih potrdil, lahko vmesno potrdilo dodamo z ustreznim parametrom v konfiguraciji spletnega strežnika. Če pa ne, pa moramo to vmesno potrdilo “pripeti” našemu overjenemu digitalnemu potrdilu. S tem se vzpostavi tim. veriga zaupanja (ang. chain of trust).

Vmesna potrdila so potrdila, ki so sicer overjena z overiteljevim korenskim potrdilom, se pa ne nahajajo v brskalnikovi shrambi zaupanja vrednih potrdil. Pripenjanje vmesnega potrdila pomeni, da le-tega dodamo v datoteko, kjer se nahaja naše overjeno digitalno potrdilo. Pri tem je pomemben vrstni red – vmesno potrdilo se mora nahajati za našim strežniškim potrdilom. Primer pridobivanja in pripenjanja vmesnega potrdila overitelja StartSSL (za druge overitelje je postopek potrebno smiselno prilagoditi):

wget http://www.startssl.com/certs/sub.class1.server.ca.pem
cat web-server.crt sub.class1.server.ca.pem > web-server-chained.crt

Diffie-Hellmanovi parametri

Na koncu nastavimo še Diffie-Hellmanov parameter velikosti 4096 bitov za zagotavljanje poudarjene zaupnosti (ang. perfect forward secrecy). Diffie-Hellmanovi parametri so namreč osnova za EDH/DHE (Ephemeral Diffie-Hellman)ključe, ki omogočajo implementacijo poudarjene zaupnosti.  Ustvarjanje Diffie-Hellmanovega parametra:

openssl dhparam -out dhparam_4096.pem -rand /dev/urandom 4096

S tem smo končali ustvarjanje kriptografskih ključev.

Mimogrede, na tem mestu preverimo še ali uporabljamo najnovejšo različico OpenSSL. Od različice 1.0.1 je v OpenSSL podpora za TLS 1.2, priporočljivo pa je uporabiti OpenSSL 1.0.1d ali kasnejšo različico, saj so razvijalci s to različico odpravili ranljivost na tim. Lucky 13 napad. Trenutno nameščeno različico OpenSSL pogledamo z ukazom:

dpkg -l | grep openssl

Izpis, ki kaže, da imamo nameščeno različico 1.0.1e (ki ni ranljiva ne na Lucky 13, ne na Heartbleed napad):

ii  openssl   1.0.1e-2+deb7u5   amd64   Secure Socket Layer (SSL) binary and related cryptographic tools

Naj še omenimo, da je včasih potrebno počakati nekaj časa, preden lahko začnemo uporabljati s strani CA podpisana digitalna potrdila. Brskalniki namreč s pomočjo OCSP strežnikov preverjajo ali je digitalno potrdilo veljavno ali je morda preklicano. OCSP oziroma Online Certificate Status Protocol je poseben protokol, ki omogoča preverjanje veljavnosti izdanih digitalnih potrdil. Dokler se OCSP strežniki ne “seznanijo” z našim novim potrdilom (to lahko traja do 12 ur), namreč sodobnejši spletni brskalniki obiskovalcem javljajo OSCP napako.

HTTPS konfiguracija spletnega strežnika Nginx

Za prikaz konfiguracije varne HTTPS povezave bomo uporabili spletni strežnik Nginx na Debian Wheezy operacijskem sistemu. Gre za zmogljiv in varen spletni strežnik, ki ga je priporočljivo uporabiti za varnostno kritične in visoko obremenjene sisteme. Na tem mestu se ne bomo ukvarjali z nameščanjem različnih dodatkov oz. razširitev za spletne strežnike, kot npr. PHP, itd., Nginx pa bomo nastavili tako, da bomo upoštevali vse zgoraj opisane teoretične usmeritve. Konkretno:

  • vse spletne zahtevke bomo preusmerili na HTTPS protokol;
  • omogočili bomo samo varne HTTPS protokole (TLS 1, TLS 1.1, TLS 1.2);
  • omogočili bomo varne šifrirne algoritme z ustrezno dolžino ključev in sicer na način, da bo preferenco teh algoritmov določil spletni strežnik in ne spletni brskalnik;
  • vključili bomo poudarjeno zaupnost (PFS) na HTTPS sejah;
  • aktivirali bomo zaščito pred BEAST napadom na strežniški strani ter onemogočili CRIME in BREACH napade;
  • vključili bomo tim. nadaljevanje SSL seje (ang. session resumption);
  • vključili bomo tim. Strict Transport Security;
  • na koncu pa bomo omogočili še OCSP pripenjanje.

Nginx namestimo z ukazom:

sudo apt-get install nginx

Nginx smo postavili na operacijskem sistemu Debian Wheezy. Privzeta različica v Debian skladiščih programskih paketov je bila v času pisanja tega prispevka 1.2.1. Če želimo namestiti novejšo različico strežnika Nginx, ki podpira tim. OCSP stapling (to zmožnost podpira Nginx od različice 1.3 dalje) jo je potrebno namestiti iz tim. backports skladišč programskih paketov. V /etc/apt/sources.list najprej dodamo opis backports skladišča:

nano /etc/apt/sources.list

Na konec datoteke dodamo:

# Najnovejsa razlicica Nginx
deb http://ftp.arnes.si/pub/packages/debian/ wheezy-backports main

Nato namestimo najnovejšo različico aplikacije (v času pisanja tega prispevka je bila to 1.4.4):

sudo apt-get update
sudo apt-get upgrade
apt-get -t wheezy-backports install nginx-full

Sledi nastavljanje Nginx konfiguracijske datoteke, ki se nahaja v /etc/nginx/sites-enabled/default. Uporabili bomo naslednje parametre:

  • za samodejno preusmeritev vseh HTTP zahtevkov na HTTPS: ukaz rewrite;
  • za vklop HTTPS šifriranja: ukaz ssl on;

    za nastavitev digitalnih potrdil: ukaza ssl_certificate ter ssl_certificate_key;

  • za nastavitev Diffie-Hellmanovih parametrov: ukaz ssl_dhparam;
  • za vklop nadaljevanja SSL seje (tim. session resumption): ukaza ssl_session_cache ter ssl_session_timeout;
  • za nastavitev preferenc šifrirnih algoritmov: ukaz ssl_ciphers, pri čemer sta zelo pomembna nabor in zaporedje podanih parametrov (!);
  • za dodajanje STS vzglavja: ukaz add_header.

Vsebina nastavitvene datoteke bo torej naslednja:

# HTTP streznik
server {
    listen 80 default_server;

    server_name moj.streznik.si;

    # Samodejna preusmeritev na HTTPS
    rewrite ^ https://moj.streznik.si$request_uri? permanent;
}

# HTTPS streznik
server {
        listen 443 ssl;

    server_name moj.streznik.si;

    ssl on;
    ssl_certificate /etc/nginx/web-server-chained.crt;
    ssl_certificate_key /etc/nginx/web-server.key;
    ssl_dhparam /etc/nginx/dhparam_4096.pem;
    # Vklop nadaljevanja SSL seje (tim. session resumption)
    ssl_session_cache    shared:SSL:10m;
    ssl_session_timeout  10m;

    # Uporabimo sodobne sifrirne protokole ter Perfect Forward Secrecy, zascita pred BEAST napadom
    ssl_prefer_server_ciphers on;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

    ssl_ciphers EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:RC4-SHA:RC4:HIGH:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS;
    # OPOMBA:
    # - ce zelimo, lahko omogocimo RC4 samo z novejšimi brskalniki (v tem primeru BEAST napad ni onemogočen s strani streznika (server side mitigation)):
    # :+RC4:RC4;
    # - ce zelimo, lahko onemogocimo RC4 (v tem primeru BEAST napad ni onemogočen s strani streznika (server side mitigation)):
    # :!RC4;

    # Lokacija spletnih datotek
    root /usr/share/nginx/www;
    index index.html index.htm;

    # Dodajanje STS vzglavja
    add_header Strict-Transport-Security max-age=31536000;

    location / {
        # First attempt to serve request as file, then
        # as directory, then fall back to displaying a 404.

        try_files $uri $uri/ /index.html;
    }

}

Po zaključeni konfiguraciji je potrebno spletni strežnik ponovno zagnati:

service nginx restart

Vsebino spletne strani (HTML datoteke), ki jo želimo prikazati, zapišemo v podimenik /usr/share/nginx/www. Spletni HTTPS strežnik sedaj že deluje. Sledi še optimizacija z OCSP pripenjanjem.

Optimizacija HTTPS povezave – OCSP pripenjanje

OCSP pripenjanje (ang. OCSP stapling) je optimizacija oz. pohitritev preverjanja veljavnosti digitalnega potrdila preko OCSP strežnikov (Online Certificate Status Protocol je poseben protokol, ki omogoča preverjanje veljavnosti izdanih digitalnih potrdil). V primeru vklopa OCSP pripenjanja bo preverjanje verige zaupanja digitalnih potrdil hitrejše, saj spletnim brskalnikom uporabnikov ne bo treba pošiljati dodatnih zahtevkov na OCSP strežnike, kar povzroča zakasnitev pri vzpostavljanju povezave z našim spletnim strežnikom, pač pa bodo OSCP overitvene podatke dobili neposredno od našega strežnika. Seveda ta postopek lahko uporabimo samo pri tistih overiteljih, ki podpirajo preverjanje digitalnih potrdil preko OSCP protokola.

Postopek konfiguracije je načeloma enostaven. V konfiguracijsko datoteko Nginx strežnika (npr. za mestom, kjer smo dodali STS vzglavja) dodamo:

ssl_stapling on;

Nato nekajkrat osvežimo HTTPS povezavo do našega strežnika in OCSP pripenjanje deluje. Vendar ne vedno. Problem nastopi pri nekaterih overiteljih, npr. StartSSL, kjer je potrebno uporabiti nekaj drugačnih prijemov.

Prvi korak pri tem je identifikacija vseh overovitvenih digitalnih potrdil našega strežniškega potrdila.

Implementacija preverjanja OCSP odgovorov s strani strežnika

Najprej moramo iz svojega digitalno podpisanega potrdila pridobiti tim. verigo zaupanja, torej podatke o overiteljih (vmesnih in končnih), nato pa na svoj računalnik prenesti pa overiteljska potrdila. Prikazan bo primer za overitelja StartSSL, ki je tudi podpisnik našega potrdila. Mimogrede, potrdilo lastnega HTTPS strežnika lahko pridobimo tudi “od zunaj”, z naslednjim ukazom:

openssl s_client -showcerts -connect web.server.si:443 </dev/null 2>/dev/null|openssl x509 -outform PEM >web-server.pem

Podpisnika našega digitalnega potrdila pogledamo z ukazom:

openssl x509 -noout -fingerprint -text -in web-server.pem

Iz izpisa vidimo SHA-1 digitalni prstni odtis digitalnega potrdila:

SHA1 Fingerprint=F8:1F:1E:27:43:77:69:45:83:C7:EC:8B:86:9B:9A:7E:54:4C:ED:9C

Vidimo tudi serijsko številko digitalnega potrdila:

Serial Number: 905335 (0xdd077)

Vidimo tudi overitelje našega digitalnega potrdila ter podatek o OCSP strežniku:

Authority Information Access:
  OCSP - URI:http://ocsp.startssl.com/sub/class1/server/ca
  CA Issuers - URI:http://aia.startssl.com/certs/sub.class1.server.ca.crt

Iz slednje vrstice vidimo lokacijo digitalnega potrdila overitelja. To potrdilo prenesemo na svoj računalnik in si ga ogledamo. Ker je v formatu DER (Distinguished Encoding Rules), moramo pri OpenSSL uporabiti parameter -inform der. Digitalno potrdilo nato pretvorimo v PEM obliko. Ukazi so naslednji; pridobitev:

wget http://aia.startssl.com/certs/sub.class1.server.ca.crt

Vmesno digitalno potrdilo pretvorimo v PEM obliko:

openssl x509 -inform der -in sub.class1.server.ca.crt -outform PEM >sub.class1.server.ca.pem

Pogledamo podpisnika vmesnega digitalnega potrdila:

openssl x509 -noout -fingerprint -text -inform der -in sub.class1.server.ca.crt

Iz izpisa je razvidno:

Authority Information Access: 
  OCSP - URI:http://ocsp.startssl.com/ca
  CA Issuers - URI:http://www.startssl.com/sfsca.crt

Pridobimo to digitalno potrdilo:

wget http://www.startssl.com/sfsca.crt

To digitalno potrdilo spet pretvorimo v PEM obliko:

openssl x509 -inform der -in sfsca.crt -outform PEM >sfsca.pem

Na spletni strani overitelja digitalnih potrdil StartSSL so še navodila za pridobitev drugega glavnega digitalnega potrdila (ca.pem):

wget http://www.startssl.com/certs/ca.pem

Ko imamo lokalno shranjena vsa digitalna potrdila overiteljev (vmesna in korenska) jih shranimo v posebno skupno datoteko:

cat ca.pem >> web-server-trusted.crt
cat sfsca.pem >> web-server-trusted.crt
cat sub.class1.server.ca.pem >> web-server-trusted.crt

V našem primeru smo tako v datoteko web-server-trusted.crt dodali dve korenski StartSSL-jevi potrdili ter StartSSL-jevo vmesno potrdilo.

Nato pogledamo serijsko številko našega overjenega strežniškega potrdila. Kot smo videli v poglavju o ustvarjanju digitalnih potrdil, je le-ta 0xdd077.

Nato z OpenSSL preko OSCP protokola preverimo veljavnost našega strežniškega potrdila:

openssl ocsp -no_nonce -CAfile /etc/nginx/vpn-web-server-trusted.crt -issuer /etc/nginx/sub.class1.server.ca.pem -url http://ocsp.startssl.com/sub/class1/server/ca/ -serial 0xdd077 -header "HOST" ocsp.startssl.com

Hitra razlaga glavnih parametrov:

  • no_nonce: parameter povzroči, da OSCP strežnik v odgovoru ne doda tim. nonce vrednosti (gre za naključno generirano število; če parametra ne dodamo, nam OpenSSL izpiše opozorilo, da odgovor ne vsebuje nonce vrednosti);
  • __CAfile: datoteka, kjer se nahajajo overiteljeva digitalna potrdila;
  • issuer: potrdilo overitelja, ki neposredno (dejansko) overja naše strežniško potrdilo;
  • url: URL povezava do OCSP strežnika;
  • serial: serijska številka (našega)potrdila, ki ga preverjamo;
  • parameter header “HOST” pri komunikaciji z OSCP strežnikom omogoči uporabo HTTP 1.1.

Dobimo približno naslednji odgovor:

Response verify OK
0xdd077: good
    This Update: Jan 24 12:06:38 2014 GMT
    Next Update: Jan 26 12:06:38 2014 GMT

Sedaj ta odgovor OCSP strežnika s pomočjo parametra -respout zapišemo v datoteko, ki jo bo nato spletni strežnik priložil odjemalcu s pomočjo OCSP pripenjanja:

openssl ocsp -no_nonce -CAfile /etc/nginx/web-server-trusted.crt -issuer /etc/nginx/sub.class1.server.ca.pem -serial 0xdd077 -url http://ocsp.startssl.com/sub/class1/server/ca -header "HOST" ocsp.startssl.com -respout /etc/nginx/web-server.ocsp

Ta ukaz nato dodamo v cron in nastavimo, da se izvaja npr. dvakrat dnevno (v našem primeru ob 1:00 ponoči in opoldan, ob 12:00):

crontab -e

Dodamo:

0 1,12 * * * /usr/bin/openssl ocsp -no_nonce -CAfile /etc/nginx/web-server-trusted.crt -issuer /etc/nginx/sub.class1.server.ca.pem -serial 0xdd077 -url http://ocsp.startssl.com/sub/class1/server/ca -header "HOST" ocsp.startssl.com -respout /etc/nginx/web-server.ocsp

Vsebino crona sicer pogledamo z ukazom:

crontab -l

Sedaj v konfiguracijsko datoteko Nginx strežnika (npr. za mestom, kjer smo dodali STS vzglavja) dodamo:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/web-server-trusted.crt;
ssl_stapling_file /etc/nginx/web-server.ocsp;

S tem je implementacija OSCP pripenjanja končana.

HTTPS konfiguracija spletnega strežnika Apache2

V nadaljevanju si bomo na hitro ogledali še glavne korake in parametre za ustrezno HTTPS nastavitev spletnega strežnika Apache 2. Spodnji opis predpostavlja, da ustvarjena digitalna potrdila shranimo v podimenik (pred tem ga seveda ustvarimo) /etc/apache2/ssl.

Najprej je potrebno omogočiti Apachejev SSL modul. To storimo z ukazom:

a2enmod ssl

Nato naložimo še modul za HTTP vzglavja (mod-headers.so):

cp -arp /etc/apache2/mods-available/headers.load  /etc/apache2/mods-enabled/headers.load

Na tem mestu je potreben ponoven zagon Apache2 strežnika:

/etc/init.d/apache2 restart

Nato v /etc/apache2/sites-enabled uredimo datoteko z opisom strežnika. Podajamo samo ključne parametre konfiguracijske datoteke:

<VirtualHost *:443>
 ServerAdmin admin@server.si
 ServerName  server.si
 ServerAlias www.server.si

 ...

 # Vkljucimo HTTPS
 SSLEngine On

 # Dolocimo lokacijo digitalnih potrdil, vkljucimo tudi tim. vmesno potrdilo
 SSLCertificateFile /etc/apache2/ssl/server.si.crt
 SSLCertificateKeyFile /etc/apache2/ssl/server.si.key
 SSLCertificateChainFile /etc/apache2/ssl/sub.class1.server.ca.pem

 # Od Apache razlicice 2.4.2 dalje je omogocena uporaba DH parametrov.
 SSLDHParametersFile /etc/apache2/ssl/dhparam_4096.pem

 # Izkljucimo manj varne protokole
 SSLProtocol All -SSLv2 -SSLv3

 # Dolocimo, da se uposteva preferencni vrstni red sifrirnih algoritmov streznika in ne odjemalcev
 SSLHonorCipherOrder On

 # Za preprecitev CRIME in BREACH napada je potrebno izkljuciti SSL kompresijo.
 # Parameter je mogoce uporabiti v Apache razlicicah od 2.2.24 dalje.
 SSLCompression off

 # Dodamo HSTS vzglavje
 Header add Strict-Transport-Security "max-age=31536000"

 # Preferencni vrstni red sifrirnih algoritmov
 SSLCipherSuite 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA'

 # Resevanje HTTPS tezav z brskalnikom Internet Explorer
 # Vec o tem na: https://httpd.apache.org/docs/2.2/ssl/ssl_faq.html
 SetEnvIf User-Agent ".*MSIE.*" \
   nokeepalive ssl-unclean-shutdown \
   downgrade-1.0 force-response-1.0
...
</VirtualHost>

Opomba: pozornejši bralci boste opazili, da je preferenčni vrstni red šifrirnih algoritmov (parameter SSLCipherSuite) nekoliko drugačen kot v primeru spletnega strežnika Nginx. Temu je tako namenoma.

Sledi ponovno nalaganje nastavitev spletnega strežnika:

service apache2 reload

Kot omenjeno, je za preprečitev CRIME in BREACH napada potrebno izključiti SSL kompresijo. Parameter SSLCompression je mogoče uporabiti v Apache različicah od 2.2.24 dalje. Če pa uporabljamo kakšno izmed starejših različic spletnega strežnika Apache, je v datoteko /etc/apache2/envvars na konec potrebno dodati:

export OPENSSL_NO_DEFAULT_ZLIB=1

Nato pa je seveda treba ponovno zagnati spletni streznik Apache.

Če na koncu želimo vse spletne povezave preusmeriti na HTTPS, dodamo še naslednje pravilo:

RewriteEngine On
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R=permanent]

Kot rečeno, smo si v tem poglavju zgolj na hitro ogledali glavne korake in parametre za ustrezno HTTPS nastavitev spletnega strežnika Apache 2, za podrobnejše nastavitve in morebitno optimizacijo pa je seveda potrebno pogledati Apache dokumentacijo.

Preverjanje kvalitete HTTPS postavitve

Kvaliteto postavitve svojega HTTPS strežnika lahko nato preverimo preko spletne storitve SSL Labs. Če naše HTTPS digitalno potrdilo ni overjeno s strani zaupanja vrednega izdajatelja digitalnih potrdil (CA), bo konfiguracija HTTPS strežnika ocenjena z najnižjo oceno (F), kljub temu pa lahko ustrezno nastavimo podporo varnim protokolom (ang. protocol support), izmenjavo šifrirnih ključev (ang. key exchange) ter kvaliteto uporabljenih šifrirnih algoritmov  (ang. cipher strength).

Rezultati SSL testa našega testnega strežnika, ki teče na Nginx.

Rezultati SSL testa našega testnega strežnika, ki teče na Nginx.

Posebej pomembno je, da uporabljamo čim bolj posodobljeno programsko opremo, zlasti to velja za OpenSSL. Kot je razvidno iz zgornje slike, je naša testna postavitev HTTPS strežnika, ki teče na Nginx in Debian Wheezy ocenjena z najvišjo možno oceno, stran pa je dostopa tudi nekoliko starejšim brskalnikom.

Žal pa HTTPS postavitev spletnega mesta kjer berete ta prispevek, ni optimalna (trenutno je ocenjena z A-). Razlog je v tem, da spletna stran gostuje na enem izmed zakupljenih strežnikov, na katerih teče nekoliko starejša programska oprema. Lastnik strežnika ima trenutno tehnične težave z nadgradnjo sistema, zato v konfiguraciji spletnega strežnika ne moremo uporabiti vseh željenih nastavitev.

HTTPS in spletni brskalnik

Varnost HTTPS povezave je seveda odvisna tudi od odjemalcev. Starejši odjemalci (npr. Internet Explorer 6.0, itd.) se na dovolj varno nastavljeno HTTPS spletno stran morda sploh ne bodo mogli povezati. Poseben problem predstavlja uporaba šifrirnega algoritma RC4. Zaradi številnih ranljivosti se uporaba tega algoritma odsvetuje, a če ga onemogočimo, uporabniki s starejšimi brskalniki ne bodo mogli na našo spletno stran. Odločitev ali RC4 omogočiti ali ne zato včasih ni enostavna.

Žal podpora naprednejšim TLS algoritmom (npr. TLS 1.2) tudi v novejše spletne brskalnike prihaja z zamudo. Tipičen primer je npr. brskalnik Firefox, ki je privzeto podporo za TLS 1.2 dobil šele pred kratkim z različico 27.

Kako dobro HTTPS povezave podpira naš brskalnik (zlasti ali podpira TLS 1.2), lahko preverimo preko spletne storitve https://www.howsmyssl.com/.

Preprečitev napadov s posrednikom

Kot povedano na začetku, gre pri napadu s posrednikom (tim. man-in-the-middle napad) za to, da se napadalec postavi med odjemalca in strežnik, kjer prestreza komunikacijo med njima, obema pa se tudi lažno predstavlja.

Zato je zelo pomembno preverjanje ali je digitalno potrdilo HTTPS strežnika s katerim vzpostavljamo povezavo pravo ali ne. Eden izmed mehanizmov za zaščito pred tovrstnimi napadi je uporaba overjenih digitalnih potrdil. Overjena digitalna potrdila so tisti, ki jih podpiše eden izmed zaupanja vrednih overiteljev (CA, Certificate Authority). Iz tega razloga uporaba samopodpisanih digitalnih potrdil, torej digitalnih potrdil, ki jih podpišemo sami, ni priporočljiva.

Kot rečeno pa varnost overjenih digitalnih potrdil temelji predpostavki zaupanja v tim. zaupanja vredno tretjo stranko, torej v overitelja. Problem nastopi, če overitelj ni zaupanja vreden in overi lažno potrdilo, mu nekdo ukrade digitalni ključ za podpisovanje ali pa uporablja slabo varnost, ki napadalcu omogoča lažno overjanje.

Na srečo obstaja tudi obramba pred tovrstnimi napadi, in sicer preverjanje digitalnega prstnega odtisa strežniškega digitalnega potrdila.

Idealno bi bilo, da bi uporabnik najprej iz neodvisnega vira izvedel in si zabeležil digitalni prstni odtis strežniškega digitalnega potrdila, nato pa bi ga preveril ob vsakem obisku HTTPS šifrirane spletne strani. V praksi je takšno preverjanje zamudno in uporabniku neprijazno, zato se za reševanje tega problema uporabljajo različni pristopi.

Omenjene tehnike preverjanja digitalnih potrdil se imenujejo pripenjanje digitalnih potrdil (ang. certificate pinning). V osnovi gre pri pripenjanju digitalnih potrdil za to, da zaupanje ne temelji več na overjanju oziroma overoviteljski verigi zaupanja, pač pa zaupamo samo točno določenim digitalnim potrdilom (takšnim s točno določenim digitalnim prstnim odtisom) oziroma digitalnim potrdilom, ki jih je izdal zgolj točno določen overitelj. Identiteto (kontrolno vsoto potrdila) brskalniku sporoči HTTPS strežnik preko posebnega HTTP vzglavja, veljavnost potrdila pa je časovno določena – če se torej potrdilo predčasno spremeni, je to pri brskalniku znak za alarm oz. sum, da je morda prišlo do zlorabe.

V letu 2013 sta varnostna strokovnjaka Moxie Marlinspike in Trevor Perrin predlagala posebno TLS razširitev TACK (ang. Trust Assertions for Certificate Keys oz. Public Key Pinning Extension). Gre za razširitev s pomočjo katere bi TLS strežnik omogočil podporo pripenjanju digitalnih potrdil na samoizbran šifrirni ključ namenjen digitalnemu podpisovanju potrdil.

Ena izmed možnosti preverjanja digitalnih potrdil je tudi TOFU/POP pristop. Pri TOFU (ang. Trust-On-First-Use) oz. POP (ang. Persistence Of Pseudonym) gre za to, da si odjemalec ob prvi povezavi do HTTPS strežnika zapomni digitalni prstni odtis njegovega digitalnega potrdila. Ob ponovnem (kasnejšem) obisku nato odjemalec preveri ali je digitalni podpis enak, ali pa se je spremenil. V slednjem primeru uporabniku prikaže obvestilo oz. opozorilo.

Ta pristop uporablja Firefox dodatek Certificate Patrol. Dodatek si ob prvem obisku zapomne vsebino in digitalni prstni odtis HTTPS digitalnega potrdila, ko pa se le-ta spremeni, o tem opozori uporabnika. Po namestitvi se splača nekoliko podrobneje pregledati nastavitve. Podrobnosti o “zapomnjenih” digitalnih potrdilih pa se shranijo v Firefoxov Upravitelj digitalnih potrdil.

Dodatek Certificate Patrol.

Dodatek Certificate Patrol.

CertificatePatrol je zaznal spremembo digitalnega potrdila.

Certificate Patrol je zaznal spremembo digitalnega potrdila.

Za spletni brskalnik Firefox je bil pred časom na voljo tudi dodatek Pet Name Tool. Dodatek se žal ne razvija več in ga novejše različice Firefoxa ne podpirajo, je pa omogočal, da si je uporabnik v posebno okence za vsako HTTPS spletno stran zapisal njeno identifikacijo (okence je v tem primeru postalo zeleno). Če se je digitalno potrdilo te spletne strani spremenilo, se je okence obarvalo rdeče.

Čisto na koncu velja omeniti še dodatek HTTPS Everywhere. Dodatek je na voljo za brskalnike Firefox, Chrome in Opera, vsebuje pa seznam spletnih strani, ki podpirajo HTTPS povezave. Seznam je že predizpolnjen, lahko pa dodajamo tudi svoje lastne strani. Ko skušamo obiskati eno izmed spletnih strani iz seznama, nas brskalnik samodejno preusmeri na HTTPS povezavo.

Dodatek vsebuje tudi tim. SSL Observatorij. Gre za sistem, ki omogoča izmenjavo in preverjanje digitalnih prstnih odtisov digitalnih potrdil (nekakšen naprednejši TOFU pristop torej). SSL Observatorij omogoča tudi beleženje v katerem omrežju smo skušali dostopiti do HTTPS šifrirane spletne strani (če mu izrecno dovolimo zabeleži ASN številko omrežja). Na podlagi tega avtorji dodatka (avtorji so člani organizacije Electronic Frontier Foundation) skušajo ugotoviti katera omrežja oz. katere države izvajajo MITM napade.

HTTPS Everywhere in SSL Observatory.

HTTPS Everywhere in SSL Observatory.

Zaključek

Kot smo pokazali v tem prispevku, postavitev ustrezno varnega HTTPS strežnika nikakor ni trivialno opravilo. Posebej pomembno je, da vsaj v osnovi razumemo elemente HTTPS varnosti, predvsem pa je potrebno področje varnosti HTTPS protokolov stalno spremljati in slediti novostim. Nikakor tudi ne smemo pozabiti na redno posodabljanje programske opreme. Le tako bomo našim uporabnikom lahko vedno zagotavljali najboljšo mogočo varnost pred napadi.

Kategorije: Informacijska tehnologija, Informacijska varnost
Ključne besede: HTTPS, šifriranje