Nenavadno dogajanje v omrežju A1?

Na naše razkritje o domnevnem prestrezanju internetnega prometa mobilnih uporabnikov operaterja A1, so se odzvali tudi v A1. Na Twiterju so zapisali takole:

Delovanje storitve A1 Protekt je, tako kot delovanje vseh drugih storitev A1 Slovenija, povsem skladno z vso relevantno zakonodajo. Storitev A1 Protekt ne izvaja nikakršnega DPI-ja oz. nedovoljenega poseganja v uporabnikove podatke in njegovo zasebnost. Za zaščito uporabnikov pred zlonamernimi spletnimi stranmi in zlonamerno kodo uporablja t.i. preverjanje / filtiriranje DNS naslovov spletnih strani (DNS filtering) v bazah mednarodno priznanih varnostnih podjetij, kot je na primer Symantec, in uporabnike obvešča o dostopu do spletnih strani, ki so v bazah teh podjetij prepoznani kot tvegani. V praksi to pomeni, da ob zaznani grožnji začasno onemogoči dostop do spletne strani, ki je prepoznana kot tvegana, in uporabnika o tem obvesti s preusmeritvijo na ciljno stran. Na njej nato storitev uporabnika obvesti, da je spletna stran, ki jo želi obiskati, potencialno nevarna. Uporabnik pa se lahko odloči, ali bo vseeno obiskal spletno stran ali ne.

Žal odgovor najverjetneje kaže, da se pri A1 bržkone ne zavedajo, kaj točno počnejo v svojem omrežju. A za začetek skušajmo razložiti razliko med DPI in DNS filtriranjem.

DPI vs. DNS filtriranje

Kot rečeno, je DPI (angl. Deep Packet Inspection) tehnologija prestrezanja omrežnega prometa, ki omogoča vpogled v vsebino podatkovnih paketov oziroma elektronskih komunikacij.

IP podatkovni paketi na internetu so sestavljeni iz tako imenovanega vzglavja in podatkov. DPI pregled ovrednoti oziroma pregleda tako vzglavje, kot tudi podatkovni del posameznega paketa. Za razliko od navadnega filtriranja podatkovnih paketov, ki pregleduje zgolj vzglavja, torej DPI pregled omogoča tudi vpogled v podatkovni del. S pomočjo DPI je torej mogoč vpogled v vsebino komunikacije. To pa seveda pomeni poseg v komunikacijsko zasebnost.

Tehnika DNS filtriranja deluje nekoliko drugače. Najprej kratka razlaga, kaj je to sploh DNS. DNS sistem, poenostavljeno povedano, skrbi za pretvorbo domenskih imen v IP naslove. Kadar v spletni brskalnik vpišemo nek spletni naslov, na primer telefoncek.si, računalnik s pomočjo DNS sistema poišče IP naslov tega strežnika (v našem primeru 91.185.207.171) ter nato vzpostavi (spletno, ali kakšno drugo) komunikacijo s tem IP naslovom.

Ko torej uporabnik vpiše ime domene v svoj brskalnik, se zgodi naslednje:

• računalnik ustvari poizvedbo DNS in jo pošlje posebnemu strežniku, imenovanem DNS razreševalec (DNS resolver);
• DNS strežnik poišče ime domene ter njen IP naslov;
• DNS strežnik uporabnikovemu računalniku vrne IP naslov poizvedovane domene;
• spletni brskalnik se poveže s prejetim IP naslovom (ciljnim spletnim strežnikom) in vsebina spletne strani se prične nalagati.

Iz opisanega postopka vidimo, da je DNS sistem bistven za dostop do (spletne) vsebine. Če spletni brskalnik preko DNS sistema ne dobi IP naslova ciljnega strežnika, komunikacije z njim ne more vzpostaviti. Iz opisanega pa je tudi jasno, kako deluje DNS filtriranje in kako s pomočjo tega mehanizma lahko onemogočamo dostop do neželenih vsebin.

Pri DNS filtriranju namreč DNS strežnik za domene, ki se nahajajo na tako imenovanem črnem seznamu (angl. blacklist), IP naslova ne vrne, ali pa vrne “napačen” IP naslov. Če bi tako nekdo želel dostopati do domene z neprimerno ali zlonamerno vsebino, bi ga v primeru DNS filtriranja DNS strežnik preusmeril na neko drugo spletno stran, recimo spletno stran, ki bi uporabnika obveščala, da se na ciljni domeni nahaja nezaželena vsebina. Mimogrede, na tak način so v Sloveniji pred leti skušali blokirati spletne stavnice.

Iz navedenega vidimo, da je razlika med obema pristopoma precej velika. Če tehnologija DPI izvaja vpogled v vsebino komunikacije (in se filtriranje izvaja glede na vsebino), je DNS filtriranje “zgolj” omejevanje dostopa do neželene vsebine. Povedano drugače: DNS filtriranje lahko primerjamo s tem, da telefonski operater uporabnikom prepreči klicanje na znane “vroče linije”, DPI pa s tem, da zablokira vse klice, kjer se uporabniki pogovarjajo o seksu.

Kaj se dogaja v omrežju A1?

Kot smo že pojasnili v prvem članku o nenavadnem dogajanju v omrežju A1, smo pri poskusu dostopa do https://swop.nl ugotovili, da se dogajata dva scenarija.

Prvi scenarij. Ko smo z A1 Protekt skušali dostopati do swop.nl, smo bili preusmerjeni na https://moj.a1.si.

V tem primeru je mobilni operater dejansko izvedel DNS preusmeritev - namesto na swop.nl, smo bili preusmerjeni na moj.a1.si.

Vendar pa se je na omrežju A1 pojavljal tudi drugi scenarij.

Drugi scenarij. Ko smo z A1 Protekt skušali dostopati do https://swop.nl, nas je spletni brskalnik opozoril, da se nekdo poskuša lažno predstaviti za spletno stran swop.nl.

V nadaljevanju smo zato pregledali digitalno potrdilo, s katerim se je (lažna) spletna stran skušala predstaviti.

Iz lažnega digitalnega potrdila se jasno vidi da:

• je potrdilo samopodpisano,
• je digitalno potrdilo izdal SecuCloud.

Ko smo nato to digitalno potrdilo sprejeli, pa se je v brskalniku prikazala vsebina prave spletne strani swop.nl. Kar pomeni, da se na omrežju dogaja MITM napad na šifrirano HTTPS povezavo.

Povedano drugače: ko se je naš spletni brskalnik skušal povezati na spletno stran https://swop.nl, je nekdo komunikacijo prestregel in spremenil - v HTTPS komunikacijo je vrinil svoje digitalno potrdilo in izvedel MITM napad (napad s posrednikom). Ob tem se postavlja vprašanje ali je bila pri tem uporabljena tehnologija DPI oz. poseg/vpogled v podatkovni del omrežnih paketov?

Kaj se v resnici dogaja?

Za globje razumevanje dogajanja se vrnimo na v prvem prispevku omenjeno tehnično analizo, kjer smo skušali slediti prometu znotraj mobilnega omrežja A1 (z uporabo orodij traceroute in hping3) ter izsledili IP naslov 109.239.187.37, kamor je bil preusmerjen naš promet.

Kot rečeno, gre za IP naslov v omrežju A1, ki pa zunaj mobilnega omrežja ni dosegljiv. Ko smo z navedenim IP naslovom skušali vzpostaviti HTTPS povezavo, nam je strežnik ponudil SecuCloudovo samopodpisano digitalno potrdilo ter javil “System Error”.

A nadaljnje preverjanje je pokazalo, da strežnik v HTTP vzglavju odjemalcu pošlje besedilo “Wand”. Z malo raziskovanja smo našli raziskovalno skupino WAND, ki deluje v sklopu University of Waikato na Novi Zelandiji in se ukvarja pretežno z računalniškimi omrežji. Eden njihovih produktov je libtrace, programska oprema namenjena procesiranju omrežnih paketov oziroma omrežnega prometa. Ali je njihova rešitev del SecuCloudovega sistema ostaja odprto vprašanje.

Vendar pa smo z nekaj nadaljnega raziskovanja prišli do poročila European Advanced Networking Test Center z naslovom EANTC Test Report - Secucloud ECS² Advanced Suite Solution Performance Test. EANTC je v poročilu testiral SecuCloudov DNS Shield (DNS ščit) modul, ki je - kot navajajo - namenjen zaščiti mobilnih naročnikov pred dostopom do zlonamernih spletnih strani s pomočjo DNS filtriranja in filtriranja vsebine.

DNS Shield modul je sestavljen iz treh komponent. Ena izmed njih se imenuje SHIELD-Proxy (proxy je posredniški strežnik). Opisana je takole:

Komponenta Shield-proxy je komponenta varnostnega filtriranja, ki se uporablja kot HTTP/HTTPS cilj za prestrežene zahteve DNS. Odgovori bodisi s HTTP preusmeritvijo na ciljno informativno stran ali z neposredno dostavo vsebine. Glavne funkcije so: filtriranje URL naslovov, prestrezanje in dešifriranje tokov HTTPS in antivirusno skeniranje HTTP odgovorov.

Zgodba sedaj postane precej bolj jasna. Glede na navedeni opis, storitev A1 Protekt najverjetneje deluje na naslednji način:

• uporabnik v svoj spletni brskalnik vnese URL naslov;
• uporabnikov mobilni telefon opravi DNS poizvedbo;
• DNS strežnik omrežja A1 preveri ali se domena nahaja na tako imenovanem črnem seznamu;
• če se domena nahaja na tako imenovanem črnem seznamu, DNS uporabnikovi napravi ne vrne nazaj pravega IP naslova domene, pač pa IP posredniškega strežnika (Shield-proxy-a)
• uporabnikova naprava sedaj svoj spletni zahtevek usmeri na ta posredniški strežnik (in ne na pravi IP naslov domene);
• posredniški strežnik uporabnika preusmeri na informativno stran (moj.a1.si), kjer uporabnika opozori, da se na ciljni spletni strani nahaja nezaželena ali zlonamerna vsebina;
• uporabnik ima sedaj možnost, da se odloči, ali nadaljuje na ciljno spletno stran, ali pa da ciljne spletne strani ne obišče.

Stvar je sicer lepo zamišljena - če uporabnik zajadra na nevarno spletno stran, ga zaustavimo in o tem opozorimo, nato pa se uporabnik sam odloči ali bo obisk nevarne spletne strani nadaljeval ali ne.

Vendar pa živimo v letu 2020.

Večina spletnih strani danes privzeto uporablja HTTPS šifrirane povezave. In v primeru HTTPS šifriranih povezav, spletne preusmeritve delujejo nekoliko drugače kot v primeru nešifriranih povezav.

V primeru nešifrirane HTTP povezave je preusmeritev mogoča s pomočjo tako imenovane HTTP Response Status kode (tako imenovana koda HTTP odgovora). Gre za numerični odgovor spletnega strežnika na spletno zahtevo, ki sporoča status spletnega zahtevka. 3xx kode spletnemu brskalniku sporočajo, da se je spletna vsebina premaknila na drugo mesto (npr. 307 - Temporary Redirect ali 301 - Moved Permanently).

V primeru nešifrirane povezave preusmeritve ni problem narediti. Če je povezava nešifrirana, vmesni posredniški strežnik (Shield-proxy) tako imenovano kodo HTTP odgovora (v konkretnem primeru 307) preprosto vrine v spletno komunikacijo in spletni brskalnik bo sledil preusmeritvi.

V primeru HTTPS šifrirane povezave pa to ni tako preprosto. Ker je komunikacija šifrirana, jo je najprej potrebno “dešifrirati”. To pa ni mogoče drugače kot s pomočjo MITM napada oziroma z že opisanim vrivanjem lažnega digitalnega potrdila.

Zdi se, da na ta problem pri A1 niso pomislili. Kar morda kaže na to, da tehniki pri mobilnem operaterju A1 morda sploh ne vedo, kaj točno počnejo v lastnem omrežju.

Če bi namreč storitev A1 Protekt delovala tako, da bi DNS zahtevke do domen na tako imenovanem črnem seznamu zgolj blokirala, bi storitev delovala brez težav. Edina posledica bi bila, da domene iz črnega seznama ne bi bile dostopne.

Ker storitev A1 Protekt deluje tako, da problematične spletne zahtevke preusmeri čez posredniški strežnik (ki skuša uporabnika informirati o potencialni grožnji), pa se je pojavil problem z lažnimi digitalnimi potrdili in poseganjem spletni promet ter posledično poseganjem v komunikacijsko zasebnost posameznikov.

Težava je torej v tem, da A1 ne dela samo DNS filtriranja, temveč filtrirane spletne zahtevke preusmeri čez posredniški strežnik (Shield-proxy).

Vprašanje torej je, ali se pri A1 tega zavedajo ali ne? Kot kaže niti ne, saj so v svojem odgovoru na Twiterju zatrdili, da uporabljajo samo DNS filriranje.

Je pa tudi potrebno dodati, da pri A1 na spletni strani s pogostimi vprašanji o storitvi A1 Protekt sami navajajo takole: “Brez spleta težko delamo – uporabljamo ga z uporabo aplikacij (e-pošta, preverjanje prometa, igre ipd.). Storitev A1 Protekt preveri ves ta promet, ki ga ustvarjamo, in v ozadju preveri ali je vsebina škodljiva. … Če storitev zazna morebitno grožnjo, samodejno blokira stran oz. podatke in na tak način zaščiti vašo napravo.”

DPI pa izrecno omenja tudi PR sporočilo iz dne 4. oktobra 2018: “Da bi zagotovili poglobljeno zaščito, Secucloud združuje več močnih varnostnih tehnologij, vključno z več antivirusnimi pregledovalniki, požarnim zidom nove generacije, analizatorji omrežnih paketov (vključno z globinskim pregledovanjem paketov (DPI), pa tudi sistemom IDS in IPS), globalno oblačno inteligenco, analizatorje DNS zahtevkov, SSL skeniranje, analize zaupanja in ugleda, APT peskovnike in analizatorje vsebine.”

Dodatek iz dne 20. maja 2020: kot so nas opozorili preko socialnih omrežij, testna aplikacija organizacije Open Observatory of Network Interference (OONI) kaže, da se v omrežju A1 (z ASN številko AS21283) verjetno pojavljajo posegi v HTTP promet.

Orodje OONI je pokazalo, da so v omrežju A1 verjetno prisotne omrežne komponente, ki so odgovorne za cenzuro ali manipulacijo spletnega prometa (tim. “middle box”). Iz OONI baze, ki je javno dostopna je razvidno, da je test HTTP Invalid Request Line prisotnost takšnih naprav zaznal v 57 primerih (od februarja 2017), test HTTP Header FIeld Manipulation pa v 51 primerih (od novembra 2017). Vse navedeno kaže, da se v omrežju A1 dogaja nekaj nenavadnega.

Dodatne težave v omrežju?

Smo pa pri prvem scenariju - preusmeritev na spletno stran z obvestilom - opazili nekaj nadvse zanimivega. Na ciljno spletno stran (https://swop.nl) smo skušali dostopati s pomočjo orodja HTTP Requester, ki prikaže HTTP zahtevke pri povezovanju na spletne strežnike. Iz vrnjenih HTTP zahtevkov je razvidno, da je preusmeritvena spletna stran vrnila referenco na telefonsko številko, iz katere smo dostopali do mobilnega omrežja.

V nadaljevanju (čez nekaj dni) smo to obnašanje skušali podrobneje analizirati z orodjem Rest Api Client 1.3, ki prav tako prikazuje HTTP zahtevke in tudi tim. HTTP vzglavja. Skušali smo dostopati do spletne strani http://acpe.ac.in.

Tudi tokrat smo ugotovili, da preusmeritvena spletna stran vsebuje referenco na telefonsko številko, vendar ne našo. Še več, nadaljni pregled je pokazal, da preusmeritvena spletna stran vsakič, ko telefon ugasnemo in znova prižgemo, vrne referenco na drugo telefonsko številko (v glavnem s predpono, 040, zaznali pa smo tudi predpono 070).

Očitno torej Shield-proxy ob preusmeritvi na informativno stran v preusmeritveni URL vrine tudi telefonsko številko naročnika. A kot kaže se na tem delu omrežja pojavljajo napake, saj posredniški strežnik (Shield-proxy) vrača različne mobilne številke. Po kakšnem ključu se to dogaja, oziroma ali je to morda naključno, ostaja odprto vprašanje.

Zato se še enkrat pojavlja vprašanje - ali je zaposlenim pri A1 res jasno, kaj se dogaja v njihovem v lastnem omrežju in kako so nastavljene komponente rešitve A1 Protekt?

 

Glede na povedano, bi bilo vsekakor smiselno, da bi pri A1 storitev A1 Protekt pred uvedbo obsežneje pretestirali, predvsem pa bi bilo smiselno, da bi se potrudili razumeti kako storitev SecuClouda tehnično sploh deluje.

Prav tako bi morali uporabnike natančno obvestiti o tem, kaj se dogaja na omrežju in za to pridobiti tudi njihovo vnaprejšnje soglasje.

Kot smo zapisali že v prvem pripevku, se je treba zavedati, da tak model varnosti, kot ga ponuja rešitev podjetja Secucloud, temelji na zaupanju do izvajalca. To pa je posebna zgodba, ki si zasluži dodatno obravnavo.

 

Dodatek: Odgovor A1

Tik pred objavo tega besedila, smo prejeli odgovor A1. Objavljamo ga v celoti.

A1 v grobem potrjuje naše ugotovitve o implementaciji DNS filtriranja, žal pa je iz odgovora mogoče videti, da pri A1 ne razumejo kaj je MITM napad (vrivanje lažnega digitalnega potrdila to zagotovo je!), kaj je poseg v komunikacijsko zasebnost (vrivanje lažnega digitalnega potrdila to zagotovo je!), predvsem pa je videti, da ne razumejo, da je rešitev, ki končnemu uporabniku predstavi samopodpisano digitalno potrdilo slaba.

Kot rečeno, živimo v letu 2020, kjer spletni brskalniki ob samopodpisanih digitalnih potrdilih izpišejo jasno opozorilo. Da ne omenjamo dejstva, da je v primeru, da ciljna spletna stran uporablja tehnologijo HSTS (HTTP Strict Transport Security) ali celo HPKP (HTTP Public Key Pinning) takšno vrivanje lažnih digitalnih še bolj sumljivo oz. nemogoče.

Mimogrede, pozorni bralci bodo opazili, da v svojem odgovoru A1 enkrat zanika uporabo MITM (“Storitev A1 Protekt je namenjena zaščiti končnih strank A1 pred potencialno škodljivimi spletnimi stranmi in ne izvaja nikakršnega DPI-ja, uporablja tehnologije MITM, ali izvaja kakršnega koli drugega nedovoljenega poseganja v uporabnikove podatke in njegovo zasebnost.”), drugič pa jo priznava (“MITM tehnika se uporablja izključno v primeru, ko gre za HTTPS URL in je bila DNS zahteva klasificirana kot nezaželena / blokirana.”).

Prav tako smo še vedno mnenja, da bi moral A1 za vklop A1 Protekta (zlasti na način kako A1 Protekt deluje) pridobiti vnaprejšnje soglasje uporabnikov. Glede na to, da so pri A1 drugačnega mnenja, bo verjetneje najbolje, da o tem presoja Informacijski pooblaščenec.

Odgovor A1, posredovan 18. maja 2020:

Pozdravljeni,

Po dogovoru s sodelavcem Blažem Ferencem vam spodaj pošiljam podrobnejša pojasnila glede vašega članka z naslovom Prestrezanje v omrežju A1?, objavljenem na portalu Telefoncek.si v petek, 15. maja 2020.

Delovanje storitve A1 Protekt je, tako kot delovanje vse drugih storitev A1 Slovenija, povsem skladno z vso relevantno zakonodajo. Storitev tako ne krši GDPR zakonodaje in ne obdeluje osebnih podatkov uporabnika na nezakonit način. Skladno z določilom 6/1 člena GDPR se podatki obdelujejo za namen izvajanja pogodbe. Podrobnejša razlaga je opredeljena v Posebnih pogojih storitve A1 Protekt oziroma Politiki varstva osebnih podatkov A1, dostopni na A1.si. Storitev A1 Protekt je namenjena zaščiti končnih strank A1 pred potencialno škodljivimi spletnimi stranmi in ne izvaja nikakršnega DPI-ja, uporablja tehnologije MITM, ali izvaja kakršnega koli drugega nedovoljenega poseganja v uporabnikove podatke in njegovo zasebnost.

Za zaščito uporabnikov pred zlonamernimi spletnimi stranmi in zlonamerno kodo uporablja t.i. preverjanje / filtiriranje DNS naslovov spletnih strani (DNS filtering) v bazah mednarodno priznanih varnostnih podjetij, kot je na primer Symantec, in uporabnike obvešča o dostopu do spletnih strani, ki so v bazah teh podjetij prepoznani kot tvegani. V praksi to pomeni, da ob zaznani grožnji začasno onemogoči dostop do spletne strani, ki je prepoznana kot tvegana, in uporabnika o tem obvesti s preusmeritvijo na ciljno stran. Na njej nato storitev uporabnika obvesti, da je spletna stran, ki jo želi obiskati, potencialno nevarna. Uporabnik pa se lahko odloči, ali bo vseeno obiskal spletno stran ali ne. MITM tehnika se uporablja izključno v primeru, ko gre za HTTPS URL in je bila DNS zahteva klasificirana kot nezaželena / blokirana. V tem primeru ne izvajamo nikakršne analize vsebine zahtevkov, razen ocene domene / URL-ja.

Podrobno:

A1 Protekt je storitev, ki jo A1 Slovenija ponuja v sodelovanju s podjetjem Secucloud. Secucloud je ponudnik omrežnih varnostnih rešitev s sedežem v Nemčiji, ki ponuja širok nabor omrežnih varnostnih rešitev, namenjenih tako ponudnikom internetnih storitev, telekomunikacijskih operaterjev kot tudi podjetjem. Čeprav za podjetja ponujajo tako DPI kot tudi popolne proxy / MITM rešitve (v oblaku), se te rešitve ne uporabljajo na množičnih trgih ISP / telco za zaščito končnih strank. Namesto tega je na teh trgih, tudi v A1 Slovenija, rešitev zasnovana na osnovi DNS filtriranja. Rešitev je integrirana v podatkovnem centru operaterja, v tem primeru A1.

Delovanje rešitve:

1. Ko končni uporabnik A1 Slovenija brska po internetu, pošilja DNS zahtevke.

2. Za naročnike varnostne storitve ti DNS zahtevki prispejo na Secocloud DNS strežnik, ki je v celoti integriran znotraj A1 Slovenija omrežja.

3. Domena, za katero je vložena DNS zahteva, se ovrednoti z uporabo algoritmov. Evaluacija se nanaša samo na domeno in nima popolnoma nobene povezave z virom zahteve - to pomeni: pri evaluaciji se ne uporabljajo nobeni podatki o uporabniku. Obstajajo različne vrste algoritmov, pravil in metod, s katerimi se izvaja takšno vrednotenje DNS zahtevkov.

4. Če v skladu z rezultatom evaluacije domena NI razvrščena v eno od konfiguriranih kategorij, ki se blokirajo (npr.: zlonamerna programska oprema, neželena pošta, lažno predstavljanje itd.), platforma razreši DNS zahtevo in uporabniku vrne dejanski IP naslov zahtevane spletne strani. Od tega trenutka dalje na Secucloud platformo ne pridejo nobeni drugi paketi, povezani s to zahtevo.

5. Če je v skladu z rezultatom evaluacije domena razvrščena v eno od kategorij, ki se blokira, platforma v DNS odgovoru vrne enega svojih dediciranih IP naslovov (redirect na landing page). Izključno v teh primerih se zahteva preusmeri na Secucloud platformo znotraj slovenskega A1 omrežja.

6. Če gre za HTTP promet, se platforma odzove s preusmeritvijo na HTTP stran A1 Slovenija (ki se nahaja na strežniku A1 Slovenije)

7. Če je zahteva za HTTPS promet, mora platforma seveda uporabiti digitalno potrdilo za blokirano domeno. Bilo bi nemogoče, da bi bil tak certifikat legitimen, saj platforma sama NI predviden ciljni strežnik. Zato se ustvari samopodpisano digitalno potrdilo. To je izvedeno IZKLJUČNO z namenom, da ima končni uporabnik možnost odpreti landing stran, kjer vidi opozorilo in informacije o strani, ki je blokirana.

8. Če končni uporabnik sprejme opozorilo o digitalnem potrdilu, se ga preusmeri na landing stran, tako kot v primeru HTTP prometa.

9. Landing Stran ponuja možnost nadaljevanja za blokirano domeno. Če uporabnik izbere to možnost, bo domena dodana na seznam dovoljenih domen (whitelist) in ob naslednji DNS zahtevi bo prejel dejanski IP domene in nadaljnji promet ne bodo prispele na Secucloud platformo. Dovoljenje (Whitelistening) traja le določen čas (~ 15min).

V primeru, da želimo določeno stran, ki je pristala na črni listi, omogočiti za uporabo, je to možno nastaviti na željo stranke.

Secucloud se zelo hitro odzove na zahteve strank, kot je A1. V konkretnem primeru je A1 opozoril Secucloud na pritožbe stranke zaradi blokiranja spletne strani telefonacek.si. Po 60 minutah je podporna ekipa Secucloud to domeno dodala na seznam dovoljenih strani (whitelist) in ta ni več blokirana.

Prizadevamo si, da je evaluacija domen čim bolj natančna, vendar se včasih pojavijo tudi lažno blokirane strani. Na splošno menimo, da je bolje imeti lažno blokirano stran, ki je za končnega uporabnika lahko moteča, kot da ne blokiramo škodljive strani, kar lahko pomeni, da je uporabnik izpostavljen tveganjem.

Upoštevati je treba tudi, da v tem primeru tudi drugi ponudniki varnostnih rešitev menijo, da je https://telefoncek.si škodljiv (glejte https://sitereview.bluecoat.com/).

V želji, da imajo bralci vašega prispevka dostop tudi do pojasnil A1 Slovenija o navedbah v njem, vas vljudno prosimo, da zgornja pojasnila čim prej tudi objavite kot dopolnitev vašega prispevka.

Če boste imeli še kakšno vprašanje, sem vam na razpolago za pojasnila.

LP

Luka

Luka Štusej

Vodja skupine za paketno storitev in storitev z dodano vrednostjo

Packet Core and Services Team Leader