Varnost povezav HTTPS
Čeprav se varne spletne povezave HTTPS v današnjih časih že razmeroma široko uporabljajo, zagotavljanje ustrezne ravni varnosti HTTPS nikakor ni trivialno opravilo.
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 ob pomoči strežnikov QUANTUM izvaja napade s posrednikom (t. i. napade MITM), ob pomoči programa BULLRUN dešifriranje šifriranega internetnega prometa itd.
A pozorno branje Snowdnovih razkritij kaže tudi, kako se je pred takšnim nadzorom mogoče zaščititi. Kot je namreč razkrila ena izmed predstavitev programa MUSCULAR, ki ga skupaj z NSA izvaja še britanska tajna služba GCHQ, je HTTPS šifriran promet v določenih primerih – na predstavitvi je bilo prikazano Googlovo omrežje – lahko trd oreh tudi za NSA.
Da je šifriran promet HTTPS lahko dejansko ovira za tajne službe, dokazuje tudi dogajanje okrog ponudnika varne elektronske pošte Lavabit. Od ponudnika varne elektronske pošte Lavabit, katerega uporabnik je bil tudi znani žvižgač Edward Snowden, je FBI julija 2013 zahteval kopijo zasebnega šifrirnega ključa strežnika HTTPS. Lastnik Lavabita, Ladar Levison, ključev HTTPS FBIju sprva ni želel izročiti, a je bil v to kasneje sodno prisiljen, zato je strežnik avgusta istega leta ugasnil. Kakorkoli že, dejstvo, da je FBI zahteval kopijo strežniškega šifrirnega ključa, nakazuje, da so kriptoanalitične zmogljivosti ameriških obveščevalnih agencij vendarle omejene. Je pa seveda treba poudariti, da mora biti šifrirna zaščita ustrezno implementirana. Zato si bomo v nadaljevanju ogledali nekatere glavne napade na protokol HTTPS in pravila za ustrezno implementacijo zaščite HTTPS v spletnih strežnikih. Pri tem pa naj ne bo odveč zavedanje, da varnost ni izdelek, torej nekaj, kar kupimo in postavimo »v kot«, temveč gre za proces. Tako kot na drugih področjih varnosti tudi na tem področju velja, da je treba varnost HTTPS neprestano spremljati in izboljševati.
HTTPS (HyperText Transfer Protocol Secure) je protokol za šifrirano spletno komunikacijo. Če za navadno spletno komunikacijo (HTTP) velja, da privzeto poteka prek vrat TCP 80, HTTPS privzeto uporablja vrata TCP 443. Šifriranje poteka prek SSL (Secure Sockets Layer) ali TLS (Transport Layer Security) kriptografskega protokola. Pri samem šifriranju podatkov pa se uporabljajo različni šifrirni algoritmi z različnimi dolžinami ključev.
Kaj je HTTPS
HTTPS (HyperText Transfer Protocol Secure) je protokol za šifrirano spletno komunikacijo. Če za navadno spletno komunikacijo (HTTP) velja, da privzeto poteka prek vrat TCP 80, HTTPS privzeto uporablja vrata TCP 443. Šifriranje poteka prek kriptografskega protokola SSL (Secure Sockets Layer) ali TLS (Transport Layer Security). Pri samem šifriranju podatkov pa se uporabljajo različni šifrirni algoritmi z različno dolgimi ključi.
Vnovično pogajanje za sejo HTTPS
Kriptografski protokoli SSL 3 in TLS 1.0 do 1.2 so ranljivi za t. i. vnovično pogajanje za vzpostavitev seje SSL s strani odjemalca (angl. client-initiated session renegotiation). Izvedba napada poteka tako, da napadalec prestreže začetek seje HTTPS, vzpostavi šifrirano povezavo s strežnikom, spletnemu strežniku pošlje šifriran spletni zahtevek, nato pa sproži vnovično pogajanje za vzpostavitev šifrirane seje in komunikacijo prepusti žrtvi. Prometa žrtve mu sicer ne bo uspelo 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 (t. i. napad MITM), ima pa podobne posledice.
Napad je torej videti takole. Najprej napadalec vzpostavi šifrirano sejo s strežnikom HTTPS 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 nekončano (brez znaka »enter«). Nato sproži zahtevek za vnovično pogajanje za vzpostavitev seje HTTPS 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 za burek poravnala žrtev napada.
Zaščita pred napadom je v ustreznih nastavitvah strežnika HTTPS, ki ne dovoli vnovičnega pogajanja za vzpostavitev seje HTTPS.
Napad z vsiljevanjem šibkejše različice protokola
Ob tem napadu, v angleščini se imenuje version rollback attack, se napadalec postavi med strežnik in odjemalca ter odjemalca prepriča, da strežnik podpira samo starejše, ranljive različice protokola HTTPS. Obenem pa tudi strežnik prepriča, da odjemalec podpira samo starejše, ranljive različice protokola HTTPS. Komunikacija je zato resda šifrirana, a steče ob pomoči 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.
Tudi v tem primeru je mogoča zaščita, in sicer tako na strani strežnika kot na strani odjemalca. Nastavimo ju tako, da ne podpirata ranljivih različic protokolov.
Napad BEAST
BEAST (Browser Exploit Against SSL/TLS) sta leta 2011 prikazala varnostna raziskovalca Thai Duong in Juliano Rizzoplet. Gre za napad ob pomoči t i. znanega čistopisa (angl. known plaintext) oz. vnaprej izbranega čistopisa (angl. chosen-plaintext attack), kjer napadalec ob pomoči javascriptnega vstavka prek brskalnika strežniku pošilja vnaprej znane podatke (čistopis), obenem pa te podatke prestreže tudi v šifrirani obliki (kriptogram). Na podlagi čistopisa in kriptograma nato izvede kriptoanalizo in s tem rekonstruira sejni ključ. S tem podatkom nato lahko npr. ukrade spletni piškotek žrtve, s tem pa žrtvino identiteto. Treba je tudi poudariti, da je napad BEAST mogoč zaradi ranljivosti odjemalca, ga je pa mogoče otežiti ob pomoči ustreznih nastavitev v strežniku.
Že pred tem je podobno ranljivost leta 2002 predstavil Phillip Rogaway, že leta 1999 pa sta David Wagner in Bruce Schneier v svoji analizi protokola SSL v3 opozorila na to, da SSL vsebuje veliko t. i. znanega čistopisa. Opisana ranljivost je bila sicer odpravljena v TLS 1.1.
Napadi CRIME in BREACH
Ista raziskovalca, ki sta leta 2011 prikazala napad BEAST, sta kasneje predstavila še napad CRIME (Compression Ratio Info-Leak Mass Exploitation), Gluck, Harris in Prado pa so leta 2013 predstavili še napade BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext; pri napadih BREACH 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 nepravilno uporabljeno stiskanje podatkov. Ob pomoči napada BREACH je HTTPS šifrirano sejo mogoče ugrabiti v manj kot minuti.
Rešitev pred temi napadi je izklop stiskanja šifriranih podatkov v konfiguraciji strežnika.
Napadi na bitno zapolnjevanje
Napad z ugibanjem bitnega zapolnjevanja (angl. padding oracle attack) je napad, ki izkorišča ugibanje vsebine t. i. bitnega zapolnjevanja (angl. 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 načini šifriranja 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).
Eden bolj znanih napadov na bitno zapolnjevanje je napad Lucky 13. Zaščita pred temi napadi je sicer redno posodabljanje zalednih kriptografskih knjižnic, zlasti OpenSSL.
Napadi na RC4
RC4 je leta 1987 razvil znani ameriški kriptolog Ronald Rivest. Uporablja se v številne namene, med drugim se je uporabljal tudi v šifriranju brezžičnih komunikacij WEP, a 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 nenaključne šifrirne ključe, oziroma če se isti šifrirni 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 v letih 2001 in 2005. Leta 2013 je kriptoanaliza Information Security Group z 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 neha uporabljati.
Kljub temu da so RC4 v preteklosti celo priporočali kot možno obrambo pred napadom BEAST, je 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. Treba 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 lahko varnost ob uporabi RC4 zelo povečamo z uporabo t. i. poudarjene zaupnosti (angl. perfect forward secrecy; o tem nekoliko več kasneje).
Napadi na kriptografsko implementacijo
Močna kriptografija sicer krepko pripomore k varnosti, a do večine napak pride pri implementaciji. Ob pomoči 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.
Tipičen zgled napake v kriptografski implementaciji je zadnja ranljivost Heartbleed, ki je močno odmevala tudi v medijih. Gre za napako v implementaciji kriptografske knjižnice OpenSSL, in sicer v implementaciji razširitve TLS/DTLS Heartbeat.
Ranljivost omogoča branje vsebine pomnilnika napadenega sistema komurkoli, in to prek interneta. Ob pomoči napada je mogoče rekonstruirati vsebino šifrirnih ključev HTTPS, posledično pa napadalec lahko dešifrira šifriran promet ali izvede krajo identitete strežnika ali odjemalca. Manj medijsko poudarjeno pa je bilo to, da ranljivost Heartbeat lahko vsebujejo tudi odjemalci – v tem primeru vsebino odjemalčevega pomnilnika bere zlonamerni strežnik. Ranljivost je bila sicer odpravljena v OpenSSL, različica 1.0.1g.
Kot končni uporabniki na napake v implementaciji resda nimamo neposrednega vpliva, lahko pa poskrbimo, da bo programska oprema na našem sistemu vedno posodobljena.
Napad s posrednikom
Pri napadu s posrednikom (tim. man-in-the-middle napad) se napadalec postavi med odjemalca in strežnik in prestreza komunikacijo med njima. Nato se začne obema lažno predstavljati – strežniku se predstavi kot odjemalec, odjemalcu pa kot strežnik. Tako odjemalec vzpostavi sicer šifrirano povezavo, a z napadalčevim lažnim strežnikom, strežnik pa prav tako vzpostavi drugo šifrirano povezavo, a ne s pravim odjemalcem, temveč z napadalčevim lažnim odjemalcem. Na tej vmesni točki se promet dešifrira in napadalec ga lahko prestreže v nešifrirani obliki.
Napadalec za lažno predstavljanje uporabi svoje digitalno potrdilo, zato je rešitev pred tem napadom načeloma zelo enostavna – uporabnik mora le preveriti, ali je digitalno potrdilo strežnika HTTPS, s katerim je vzpostavil povezavo, veljavno ali ne. Načeloma je takšno preverjanje razmeroma enostavno, če imamo opravka s t. i. 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. Zato je zelo priporočljivo, da na strežnikih HTTPS uporabljamo overjena digitalna potrdila. Postopek overjanja je enostaven in razmeroma poceni, pri nekaterih overiteljih celo brezplačen.
Vendar pa varnost overjenih digitalnih potrdil temelji na predpostavki zaupanja v t. i. 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 katero izmed tajnih služb. Če tak overitelj overi lažno potrdilo, uporabniki načeloma ne bodo posumili, da je potrdilo v resnici neveljavno.
Žal varnost t. i. 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 digitalno potrdilo HTTPS za poljubno domeno. Avtor tega prispevka si je takrat izdal lažna, a veljavna (torej overjena) digitalna potrdila kar za nekaj slovenskih spletnih bank … :-) (Seveda 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!)
V ne tako davni preteklosti je bilo mogoče podpise overiteljev na digitalnih potrdilih tudi ponarediti. Leta 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 konferenci CCC leta 2008 pokazala, kako je s kolizijami v algoritmu MD5 mogoče izdelati ponarejena, a veljavno digitalno podpisana potrdila za katerokoli spletno stran.
Naj na tem mestu omenimo, da je – na strani odjemalca – tudi obramba pred takimi napadi. Več o tem v nadaljevanju.
NSA se zaveda težav, ki jih za prestrezanje predstavlja komunikacija HTTPS.
Ukrepi za povečanje varnosti HTTPS v strežniku
Popolne varnosti sicer ni mogoče zagotoviti, lahko pa z nekaterimi premišljenimi ukrepi varnost precej izboljšamo. Prvi tak ukrep je uporaba ustrezno dolgih strežniških digitalnih potrdil. Dolga naj bodo vsaj 2048 bitov, še bolje 4096 bitov. Smiselno je, da ne uporabljamo samopodpisanih potrdil, temveč da naše strežniško potrdilo podpiše eden izmed t. i. zaupanja vrednih overiteljev, da se vzpostavi t. i. veriga zaupanja.
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. V nastavitvi spletnega strežnika pa omogočimo uporabo protokolov TLS, zlasti (trenutno) najnovejšega, TLS 1.2.
Za šifriranje v okviru povezave HTTPS 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 zelo pomembno, da na strežniku nastavimo preferenčni vrstni red algoritmov, ki se bodo uporabljali za šifriranje povezave.
Eden izmed boljših varnostnih mehanizmov za zaščito povezav HTTPS je uporaba t.i. poudarjene zaupnosti (angl. perfect forward security oz. perfect forward secrecy). Poudarjena zaupnost pomeni, da se šifrirni ključi samodejno spreminjajo vsako novo sejo oz. na določeno časovno obdobje. Če napadalcu 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 napadalcu kdaj kasneje uspe pridobiti strežniško digitalno potrdilo. Za uporabo tega vzamemo Diffie-Hellmanove parametre čim večje velikosti (npr. 4096 bitov), saj so ti parametri osnova za ključe EDH/DHE (Ephemeral Diffie-Hellman), ki omogočajo implementacijo poudarjene zaupnosti.
Poleg navedenih ukrepov lahko skrben sistemski upravitelj uvede še nekatere druge zaščitne mehanizme, npr. omogoči rabo vzglavij HTTP Strict-Transport-Security, vse spletne zahtevke brskalnikov samodejno preusmerja na protokol HTTPS, z ustreznimi parametri v konfiguraciji onemogoča t. i. vnovično pogajanje za vzpostavitev seje SSL s strani odjemalca itd. Kot rečeno, pa je zelo pomembno tudi to, da vestno skrbimo za nalaganje varnostnih posodobitev programske opreme.
Shematski prikaz napada s posrednikom
HTTPS in spletni brskalnik
Varnost povezave HTTPS je seveda odvisna tudi od odjemalcev. Zato je priporočljivo, da uporabniki naše spletne strani uporabljajo čim novejše različice spletnih brskalnikov. Žal se je treba zavedati, da nekatere varnostne izboljšave tudi v novejše spletne brskalnike včasih prihajajo z zamudo. Tak primer je npr. brskalnik Firefox, ki je privzeto podporo TLS 1.2 dobil šele pred kratkim, z različico 27.
So pa izdelovalci brskalnikov v zadnjem času vložili kar nekaj truda v preprečevanje ali vsaj oteževanje napadov s posrednikom. Eden izmed ključnih mehanizmov za preprečevanje napadov s posrednikom je preverjanje strežniških digitalnih potrdil.
Kot rečeno, je priporočljivo uporabljati overjena digitalna potrdila, a varnost teh potrdil temelji na predpostavki zaupanja v overitelja. Če je overitelj zlonameren ali prisiljen overiti lažno potrdilo, če mu nekdo ukrade digitalni ključ za podpisovanje ali pa uporablja slabo varnost, celoten opisani varnostni model pade.
Sodobni spletni brskalniki zato uporabljajo nekatera preverjanja digitalnih potrdil ob pomoči t. i. pripenjanja digitalnih potrdil (angl. certificate pinning). V osnovi gre pri pripenjanju digitalnih potrdil za to, da zaupanje ne temelji več na overjanju oziroma overoviteljski verigi zaupanja, temveč zaupamo samo točno določenim digitalnim potrdilom (takim 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 strežnik HTTPS prek posebnega vzglavja HTTP, 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.
Certificate Patrol je zaznal spremembo digitalnega potrdila.
Ena izmed možnosti preverjanja digitalnih potrdil je tudi pristop TOFU/POP. Pri TOFU (angl. Trust-On-First-Use) oz. POP (angl. Persistence Of Pseudonym) gre za to, da si odjemalec ob prvi povezavi do strežnika HTTPS zapomni digitalni prstni odtis njegovega digitalnega potrdila. Ob vnovičnem (kasnejšem) obisku nato odjemalec preveri, ali je digitalni podpis enak ali se je spremenil. V slednjem primeru uporabniku prikaže obvestilo oz. opozorilo.
Ta pristop uporablja Firefox dodatek Certificate Patrol. Dodatek si ob prvem obisku zapomni vsebino in digitalni prstni odtis HTTPS digitalnega potrdila, ko pa se 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.
Omeniti velja še dodatek HTTPS Everywhere. Na voljo je za brskalnike Firefox, Chrome in Opera, vsebuje pa seznam spletnih strani, ki podpirajo povezave HTTPS. Seznam je že izpolnjen, lahko pa dodajamo tudi svoje lastne strani. Ko skušamo obiskati eno izmed spletnih strani s seznama, nas brskalnik samodejno preusmeri na povezavo HTTPS.
Dodatek vsebuje tudi t. i. 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 spremljanje, v katerem omrežju smo skušali doseči šifrirano spletno stran HTTPS (če mu izrecno dovolimo, zazna številko ASN omrežja). Na podlagi tega skušajo avtorji dodatka (avtorji so člani organizacije Electronic Frontier Foundation) ugotoviti, katera omrežja oz. katere države izvajajo napade MITM.
HTTPS Everywhere in SSL Observatory
Kako varne so banke in država?
Za preizkus varnosti HTTPS je na voljo kar nekaj orodij. Kot osnovno orodje lahko uporabimo aplikacijo s_client, ki je del paketa OpenSSL, a ker gre za orodje, ki ga poganjamo iz ukazne vrstice, je bolje uporabiti kakšno spletno aplikacijo. Ena boljših in tudi uporabniško prijaznih je spletna aplikacija Qualys SSL Labs test, ki omogoča tako preverjanje strežnikov kot tudi odjemalcev. Aplikacija za preverjanje strežnikov je dostopna na naslovu https://www.ssllabs.com/ssltest/.
SKBjeva elektronska banka je zelo dobro zaščitena, državna banka SID pa veliko slabše.
Aplikacija preveri nastavitve HTTPS strežnika, izrecno tudi obstoj nekaterih glavnih ranljivosti, in na podlagi preizkusov poda številčno oceno od 0 do 100 za kakovost digitalnih potrdil, podporo kriptografskim protokolom, izmenjavo šifrirnih ključev ter kakovost šifrirnih algoritmov, ki jih podpira strežnik. Na koncu pripravi skupno oceno varnosti strežnika HTTPS od F (najslabše) do A (oziroma A- in A+). Naj omenimo, da se aplikacija za testiranje neprestano nadgrajuje, avtorji pa sledijo novostim na področju varnosti HTTPS, zato je priporočljivo, da sistemski upravitelji svoje strežnike redno preverjajo.
Elektronsko davčno poslovanje naše države (edavki.durs.si) se ponaša z oceno F.
Tudi E-sodišče - F!
V nadaljevanju podajamo slike rezultatov preizkusov nekaterih strežnikov slovenske države uprave in nekaterih slovenskih spletnih bank.