Kirjutisi seinal

Eilsest on saadaval Covid19 immuniseerimistõendid. Logisin patsiendiportaali ja salvestasin enda oma ja vaatasin sisse.

Loodud on ta ilmselgelt riigipiiride ületamiseks ja seal tõendis leiduvad isikuandmed on piiride ületamisel niikuinii vajalikud ja peavad niikuinii olema muudes dokumentides kirjas.

Siseriiklik kasutamine on teine asi. Tegelikult ei ole restorani või kontserdile minnes sinu nimi ja sünniaeg üldjuhul oluline (siis muidugi tekib küsimus kuidas tuvastada et QR-koodi näitaja on sama isik, aga olemuselt tekib see ka kogu paberi näitamisel). Kui see peaks nõutavaks kujunema, siis eralda pdf failist qr-kood kas mõne sellekohase tarvikuga (näiteks: pdfimages covid-certificate.pdf covid-cert-qr-kood) või ekraanitõmmise meetodil ja salvesta vaid QR-koodi fail telefoni.

QR-koodis on selline url (YKSUUID, TEINETUNNUS, SINUISIKUKOOD asemel on tegelikud andmed):
https://vg.digilugu.ee/?url=https%3A%2F%2Fvg.digilugu.ee%2Fapi%2Fcertificates%3Fuuid%3DYKSUUID&s=TEINETUNNUS&i=person+identifier_SINUISIKUKOOD

Kui selle avad, siis näed niisugust pilti (konkreetsed väärtused on kustutatud).


Piiride ületamisel on selline detailsus võib-olla vajalik, aga siseriiklikult tegelikult mitte. Piisaks Jah/Ei tüüpi vastusest.

Tegelikult eriti ei oska immuniseerimistõendi sisu ja teostust väga kommenteerida. Hoopis jäid silma veebiserveri vg.digilugu.ee seadistused. Ja seda kahe nurga alt:

(1) SSL'i seadistused (neid saad mõõta testssl skripti või SSLLabs'i veebirakendusega), millest jäävad silma sellised vead:
- TLS 1.3 on puudu (sellise tasemega rakendusel seda eeldaks)
- TLS 1.2 pakub välja 21 šifrikomplekti, millest 17 on CBC-põhised ja neid pigem ei loeta mõistlikuks (eriti sellist tüüpi rakendusel)
- DNS CAA on puudu (sellise tasemega rakendusel seda eeldaks)
- sertifikaadiahela teostus pole ka kõige parem

(2) Serveri turvaseadistused (hinnatuna Securityheaders veebirakendusega)



Kui eelmises näites on asjaolud, mille üle saaks ehk natuke vaieldagi, siis siin on puhas plats:
- olemas on vaid HSTS
- puudu on CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy ja neid kõiki eeldaks sellise taseme rakendustest

Aga tegemist pole ükskikjuhtumiga, vaid laiema süsteemitusega. Kui vaatame samade töövahenditega (SSLTest/Securityheaders tänase päeva seisuga) president.ee (A+/C), valitsus.ee (A+/A), vm.ee (A/D), ria.ee (A+/A), kapo.ee (A+/C), eesti.ee (A+/C) ja teisi Eesti riigi saite, siis tulemused on väga ebaühtlased ning sarnaseid vigu leidub neist nii mõnelgi. Ja need SSLTesti A+ ja A-tulemused sisaldavad samamoodi nõrku šifrikomplekte, TLS 1.3 mittekasutamist ja puuduvat DNS CAA'd.

Läbipaistvuse osas mainin ka, et olen osalenud nii mõnelgi riigihankel, kus tingimuste osaks on olnud siinräägitud teemadest nö "maksimumnõuded". Oleks ju tore, kui riigi omad veebirakendused siis ka vastaks samadele tingimustele. Ja need tingimused oleks täidetud ühtlaselt.

vg.digilugu.ee saidi puhul tasub aga lisaks mainida kolme olulist asjaolu:
(1) Minu brauser annab märku katsest kanva andmete alusel arvutit profileerida - miks peaks selline tegevus vajalik olema ning missugustes kasutustingimustes see kirjas on?
(2) Kus on saidi privaatsustingimused? Kontrollvaates on kirjas valmistaja kaubamärk, aga eeldaks ka viidet selle saidi privaatsustingimustele. Mis andmeid vg.digilugu.ee saidi puhul logitakse, kaua logisid hoitakse ja kes ning kuidas neid töötleb? Kuna päringutes on isikukood olemas ja päringuid tegevaid kliente profileeritakse ning saab vähemalt ip-aadressi täpsusega tuvastada, siis annab mõlema poole andmeid huvitaval viisil kokku panna. Näiteks väliskasutuse kontekstis saaks sellisest andmekogust teada, mis riikides konkreetse isikukoodi kasutaja reisib ja kes kipuvad koos reisima, sisekasutuses aga joonistuks välja profiil sellest mis asutusi keegi külastab.
(3) Samast tehakse lisaks alampäring Guardtime saiti vaccine.gtuslabs.com. Kus on kirjas see teave mida sinna edastatakse? Ja siis tulevad selle otsa kõik eelmise punkti küsimused.

Tänase päeva pommuudis on küberturvalisuse valdkonnast. Key Reinstallation Attack ehk KRACK võimaldab WPA2'd kasutavaid WiFi ühendusi pealt kuulata ning andmed muuta ja seeläbi väga palju kurja korda saata.

See on üks hullemaid andmeturva probleeme (võib olla ka kõige suurem), mis läbi aegade on leitud.

Viga on WPA2 protokollis endas ning kõik tugijaamad ja kliendid, kes selle vähegi korralikult on implementeerinud, on ka haavatavad. Ja see puudutab arvuteid, tahvelarveuteid, mobiiltelefone, külmkappe ja mida iganes, mis WPA2'ga WiFi't kasutavad. Lihtsamalt öeldes puudutab see kõiki WiFi'ga vidinaid siin maailmas.

Seni kuni tugijaamade tootjad ja kliendi-tarkvara valmistajad veaparandused valmis saavad, on 2 valikut:

• ära kasuta WiFi't (kasuta arvutite puhul traadiga ühendust ja mobiilsete puhul 3G/4G tüüpi ühendusi)
  
• ja kui kasutad WiFi't, siis jälgi, et kõik liiklus oleks VPN'iga kaetud ja/või kõik rakenduste poolt tehtavad ühendused krüpteeritud - kui sa ise ei tea kuidas seda kontrollida ja seadistada, siis küsi neilt kes teavad
  

Mida tähendab "kõik rakenduste poolt tehtavad ühendused krüpteeritud"? Näiteks seda, kus iganes liigutad privaatset teavet või ei taha et kolmas osapool saaks seda lugeda, siis:

• vaata et sinu veebibrauseris url algaks https-iga ja et sa pole brauseris ssl'i teemalisi vigu maha keeranud
  
• vaata et sinu e-posti kliendis kirjade lugemine IMAP või POP3'ga oleks krüpteeritud
  
• vaata et sinu e-posti kliendis kirjade saatmine SMTP'ga oleks krüpteeritud
  
• vaata, et sinu lemmik-sõnumiklient kasutaks krüptograafiat
  

Õnneks on tarkvara paikamine juba alanud. Näiteks wpa_supplicant (alusteek Androidis ja Linuxis) on paigad juba avaldanud, kuid alati on õhus küsimus, et millal need sinu vastavate WiFi-suutlike seadmeteni jõuavad.

Täiendatud 21:50

Läbi aegade suurimale arvutiturvaprobleemile on saanud osaks ka pretsedenditu ja koordineeritud lahenduse otsimine. Viimase paari kuu jooksul on teavitatud kõiki olulisimaid operatsioonisüsteemiarendajaid ning tänasel pärastlõunal (i.e. peale turvavea avalikustamist) on ükshaaval hakanud ka turvaparandusi ilmuma (sh Windowsile ja mitmele Linuxile). Oluline oleks et ka tugijaamade tootjad järgi tuleksid ning kasutajad oleksid suutelised ka neid uuendusi tegema.

Seega uuendage niipea, kui see teil võimalik on.

Praktikas on tihti vaja mõne mälupulga kogu sisu mõistlikult turvalisel viisil tühjendada. Linuxis käiks see kõige lihtsamal viisil käsurealt nii (olles administraatori õigustes):

shred /dev/sdx -n 5 -v

Vajalik /dev/sdx vaata järgi näiteks df käsuga, kuid tavalise ühe kõvakettaga arvuti puhul oleks üldjuhul /dev/sdb (praktikas on mälupulgal tihti vaid üks partitsioon ja /dev/sdb1 toimib ka). Võti -n kirjutab kõik üle 5 korda ja -v näitab mida ta parasjagu teeb.

Programm shred loomulikult kolmetäheliste organisatsioonide huvi vastu ei aita, kuid harju keskmise huvilise vastu küll ning teeb seda viisil, mis arvestab välkmälude tavapärase hajutatud kirjutamise (wear leveling) loogikaga ehk teisisõnu kirjutab äärest ääreni.

Selle artikli järgi on pupulaarsemad telefonide PIN-koodid 1234, 0000, 2580, 1111 ja 5555.

Sa oled esimest korda ssh serverisse logides kindlasti märganud sellist teadet:

The authenticity of host 'aaa.bbb.ccc.ddd' can't be established.
RSA key fingerprint is 00:11:22:33:44:55:66:77:aa:bb:cc:dd:ee:ff:gg:hh.
Are you sure you want to continue connecting (yes/no)?

Kuidas saad kontrollida, et see sõrmejälg õige on?

Sa kas oled eelnevalt saanud administraatorilt õige sõrmejälje või kui serverile on füüsiline ligipääs olemas, siis vaatad ise järgi. Ssh serveris hoitakse võtmeid /etc/ssh kaustas ja avalikud võtmed (.pub laiendiga failid) on kõigile ka loetavad. Käsuga ssh-keygen saad neid ka uurida ja muu hulgas leida ka vajaliku sõrmejälje (väikeseks muigeks võid lisada vahele ka -v võtme):

ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key.pub