neljapäev, 10. detsember 2015

Let's Encrypt tasuta SSL serdid

Kes on viimase aasta ainult kuskil kivi all elanud, pole arvatavasti veel kuulnud sellisest initsiatiivist nagu Let's Encrypt. Tegu pole millegi vähemaga kui revolutsiooniga SSL sertifikaatide väljastamises. Täpsemalt küll nn. DV ehk domain validatud sertifikaatide haldamises, sest OV ja EV serte väljastatakse ka edaspidi täpselt nii nagu täna (vähemalt esialgu). Domeenikinnitusega domeenide väljastamine on sertide müüjatele muutunud nii odavaks, et nende eest nagu polekski enam põhjust üldse raha küsida ja seda Let's Encrypt teebki – annab DV domeene kõikidele soovijatele tasuta. Samas ei ole tasuta sertifikaadid mingi uudis, näiteks StartSSL pakub neid juba aastaid. Revolutsioonilisus seisneb hoopis milleski muus kui hinnas, nimelt viisis kuidas neid serte üldse soetatakse.

Kui meenutada, kuidas näeb välja üks tavaline DV serdi hankimise protseduur, siis võiks see olla järgmine:

  1. Kõigepealt muidugi teeme läbi serdi ostmise protseduuri
  2. Siis genereerime uue salajase RSA võtme (või kasutame olemasolevat). Tavaliselt kasutatakse selleks openssl käsurida
  3. Järgmiseks koostame (suure tõenäosusega jälle openssl käsurealt) sertifikaadipäringu, kuhu läheb kirja meie füüsiline asukoht, administraatori e-posti aadress ja soovitud domeeninimi
  4. Nüüd kopeerime ja pasteerime sertifikaadipäringu sisu (see on base64 kodeeringus) sertifikaadimüüja kodulehele vastavasse tekstikasti ja kinnitame tellimuse
  5. Edasi tuleb oodata, kuni domeeni administraatori e-postkasti laekub kiri kinnituslingiga
  6. Avame kinnituslingi ja klikime nupul, et oleme serdi väljastamisega nõus
  7. Serdi müüja saadab nüüd samale aadressile sertifikaadi koos serdiahela teiste sertidega (tõenäoliselt zipiga pakitult)
  8. Pakime zip faili lahti ja laeme võtme ning uue serdi, vajadusel koos serdiahelaga serverisse

Nagu näha, siis serdi müüja poolelt käib kõik üsna automaatselt (sellest ka odav omahind sertide väljastamises), aga ostja poolel tuleb teha üsna palju käsitööd alates tellimisvormi täitmisest kuni e-posti kaudu saadud zip failiga žongleerimiseni.

Let's Encrypt muudab kõike seda. Edaspidi saab serte tellida ja uuendada puhtalt tarkvara abil ilma igasuguse inimesepoolse sekkumiseta, mis ongi tegelikuks revolutsiooniks. Let's Encrypt on nimelt esimeseks ACME ehk Automatic Certificate Management Environment protokolli implementeerijaks, mis kirjeldab ära sertifikaadi tellimise automatiseeritud protsessi. Tulevikus võtavad sama protokolli tõenäoliselt üle ka teised sertide müüjad, see ei ole sugugi mõeldud olema ainult Let's Encrypt keskne. Kusjuures protokoll näeb ette võimalust, et serdi eest saab ikkagi ka maksta.

ACME protokoll töötab lihtsustatult nii:

  1. Tarkvara genereerib ise PKI võtme ja CSR sertifikaadipäringu
  2. Sertifikaadipäring saadetakse allkirjastatult ACME API aadressile
  3. ACME server teeb päringu soovitud domeeni urlile domeen/.well-known/acme-challenge/{token}
  4. Klient vastab sellele päringule allkirjastatud {token} väärtusega
  5. Klient laeb ACME serverist genereeritud serdi

Kuigi protsess on taustal mõnevõrra keerulisem, siis tarkvara jaoks on see protseduur nagu iga teine ning seetõttu on see muu hulgas ka kergelt automatiseeritav. Kui kasutada ametlikku letsencrypt klienti, siis taustal toimuvat üldse ei näegi, kõik tundub üsna maagiline – sisestad käsureal soovi, et tahad endale uusi serte ja järgmisel hetkel on kehtivad serdid juba ettemäärtud kaustas olemas.

Tõenäoliselt ei jää letsencrypt klient siiski ainsaks võimaluseks serte tellida, kuna esiteks ei ole referentsklient päris automaatne (seda annab shelli võimaluste ja yes käsu abil muidugi parandada), see nõuab miskipärast ka üsna palju ressursse (eelkõige operatiivmälu) ja lisaks on see veel veidi piiratud võimalustega. Protokoll on avalik ja seega ei ole kellelgi takistuseks töötamaks välja just omale sobivat tarkvara.

Küsimused ja vastused

1. Kas sertide genereerimiseks peab kasutama letsencrypt utikat?
Ei pea. Protokoll on avalik, letsencrypt utikas on lihtsalt selle protokolli üks implementatsioon

2. Kas Let's Encrypt lubab tellida suvalisel kasutajal suvelisele domeenile serte?
Ei luba. Serdi genereerimiseks peab tellija tõestama valdust valitud domeeninime üle. Kui tellija ei suuda tõestada, et ta kontrollib valitud domeeni, siis sertifikaati ei genereerita. See on tavaline DV sertide genereerimise praktika.

3. Kas serte peab tellima samast masinast, mille domeenile tahad serti tellida?
Ei pea. Domeeni omandust saab tõestada kas HTTP või DNS abil. DNS kaudu ei puutu konkreetne masin üldse asjasse. HTTP abil valideerides peab Let's Encrypt server saama ligipääsu domeen/.well-known/acme-challenge/* URL'ile, kuid selle saab näiteks proxy reeglite kaudu suunata veebiserverist välja, ühtsesse sertide genereerimise masinasse.

4. Kas Let's Encrypt saadab teised serdimüüjad ajaloo prügikasti?
Kindlasti mitte. Kuigi pakutav tasuta sert võib sundida ka teisi kas hinda veelgi langetama või siis täiesti tasuta muutma, on Let's Encrypt siiski omade piirangutega ja rohkem mõeldud olema teed rajavaks referentsiks, mitte turu domineerijaks. Näiteks kehtivad Let's Encrypt sertide genereerimisel rate limit pirangud, samuti genereeritakse ainult DV serte. Kommertspakkujad saaksid sama protkolli kaudu pakkuda tunduvalt paindlikumat teenust, näiteks kõigepealt tuvastada tellija organisatsioon ja edaspidi lubada tuvastatud kasutajal tellida ka OV/EV serte. Kusjuures hind ei pruugi olla üldse seotud sertide arvuga, kommertspakkuja saaks serte müüa näiteks ka subscriptioniga kus serte võib genereerida X hulgal niikaua kui tellijal on müüja juures kehtiv kuutasuline subscription. Siiani ei ole midagi väga innovatiivset saanud selles vallas teha, kuna niiöelda API põhine kiire ja suures koguses sertide genereerimine oli ühtse standardi puudumise tõttu võimalik siiski ainult väga suurtele klientidele.

5. Kas nüüd loobuvad odavate sertide tellijad oma vanadest sertidest Let's Encrypt sertide kasuks
Ei usu. Let's Encrypt idee ei seisne mitte niiväga tasuta serdides (kuigi muidugi ka selles), vaid nende sertide tarkvaralises genereerimises. Lihtsalt eelmise pakkuja asendamiseks see ei sobi, kuna sellisel viisil genereeritud serdid on palju lühema kehtivusajaga (3 kuud vs. standardne 1 aasta) ja seega tuleks serdi uuendamise toimingut läbi viia tunduvalt tihemini. Eelkõige võiks "klientideks" olla ikka need, kes suudavad selle voo automatiseerida. Näiteks veebihostingu pakkujad jmt. Tavatarbijale võib olla isegi lihtsam käia kord aastas kommertspakkuja juures ja maksta oma $8, kui käia iga paari kuu tagant serveris letsencrypt utikat käivitamas.

neljapäev, 26. november 2015

Jagatud saladused

Kui üldiselt räägitakse krüptograafia puhul kas sümmeetrilisest (andmed krüpteeritakse ja avatakse sama võtmega) või asümmeetrilisest (andmed krüpteeritakse avaliku võtmega, avatakse salajase võtmega) krüptograafiast, siis eksisteerib veel üks põnev andmete krüpteerimise meetod, nimelt jagatud saladuste kasutamine.

Ma ei ole teoreetik, vaid praktik, seega ei oska öelda, et kas see on päris eraldiseisev või hoopis sümmeetrilise krüptograafia erivorm, kuid erinevus tavalisest sümmeetrilisest krüpteerimisest seisneb selles, et andmete avamiseks on vaja mitut võtit. Kusjuures ükski võti omaette ei ütle meile andmete sisust mitte midagi, kuid koos suudavad selle avada. Vaatamegi siin lähemalt üht tuntuimat jagatud saladuste algoritmi Shamir's Secret Sharing (originaalne artikkel, PDF) ja eelkõige siis selleks, et kuidas seda praktikas kasutada.

Shamiri jagatud saladuste algoritmi puhul võime genereerida suvalise n arvu võtmeid, kusjuures saladuse taastamiseks on vaja teada ainult k võtit, kus k võib olla võrdne või väiksem kui n. Seega kui n on näiteks 4 (võtmeteks on S1, S2, S3 ja S4) ja k on 2, siis saladuse avamiseks sobib ükskõik milline järgmistest kombinatsioonidest S1+S2S1+S3S1+S4S2+S3S2+Svõi S3+S4, kus kombinatsioonide arvu leiame valemiga n!/((n-k)!(k!)).

Kus sellist jagatud saladust üldse kasutada? Üheks praktiliseks näiteks võiks olla kahefaktoriline autentimine sellises teenuses, kus kasutaja andmeid krüpteeritakse ja avatakse brauseris mingi sümmeetrilise võtmega. Sümmeetriline võti oleks peidetud Shamiri algoritmiga ning selle avamiseks peaksime teadma vajalikku hulka jagatud võtmeid (meie näiteks 2). Sellisel juhul teaks kasutaja üht jagatud saladuse kahest vajalikust võtmest ja server teaks teist. Kui kasutaja nüüd suudab tõendada serverile teise faktori olemasolu, saadab server kasutajale enda teada oleva saladuse, kasutaja paneb kaks saladust kokku ja saabki võtme oma andmete avamiseks. Me ei saa kasutada Shamiri jagatud saladust otse andmete peitmiseks, kuna see sobib vaid väikese suuruse andmete jaoks, nimelt on jagatud saladuse üksikud osad sama suured kui peidetavad andmed.

Järgmises näites kasutame Shamiri jagatud saladuste JavaScripti implementatsiooni (täpsemalt Node.JS versiooni), mille leiab siit.

Alustuseks on on meil andmed, mida tahame peita ning sümmeetriline parool nende andmete krüpteerimiseks.

var vault = "suur saladus";
var secret = "salakala";

var crypto = require("crypto");
var cipher = crypto.createCipher("aes256", secret);
cipher.update(vault);
var encrypted = cipher.final("hex");

// "2230f86334604f915cca82247378f7c4" -> saadame serverisse

Järgmiseks jagame krüpteerimiseks kasutatud saladuse mitmeks osaks Shamiri jagatud saladuste algoritmiga ja salvestame kuidagi koha peal ja teise poole saadame serverisse.

var secret = "salakala";

var secrets = require("secrets.js");
var shares = secrets.share(new Buffer(secret).toString('hex'), 2, 2);

// "80181920359aa3b26722b" -> salvestame
// "8021caca506eacbef50f5" -> saadame serverisse

Seega server teab nüüd esiteks krüpteeritud andmeid "2230f86334604f915cca82247378f7c4" ning üht osa jagatud saladusest "8021caca506eacbef50f5". Meie aga omakorda teame teist osa jagatud saladusest "80181920359aa3b26722b". Kumbki pool ei saa hetkel nende andmetega suurt midagi peale hakata.

Ütleme, et tahame nüüd uuesti vaadata, et mis need salajased andmed olid. Sellepärast küsime serverist kõigepealt peidetud andmed ja seejärel teeme läbi kahefaktorilise autentimise. Ütleme, et server saadab selle jaoks meile mingi koodiga SMS sõnumi, sisestame sõnumis olnud koodi ja nüüd saadab server meile ka teise osa jagatud saladusest. Seega on meil olemas kõik vajalik, et andmed taastada.

Selleks taastame kõigepealt jagatud saladustest salajase parooli.

var shares = ["80181920359aa3b26722b","8021caca506eacbef50f5"];

var hex = secrets.combine(shares);
var secret = new Buffer(hex, 'hex').toString();

// "salakala

Ja seejärel dekrüpteerime saadud saladusega krüpteeritud andmed.

var encrypted = "2230f86334604f915cca82247378f7c4";
var secret = "salakala";

var decipher = crypto.createDecipher('aes256', secret);
decipher.update(new Buffer(encrypted, 'hex'));
console.log(decipher.final('utf-8'));

// "suur saladus"

Kasutatud näide on muidugi väga lihtsustatud, seega reaalsed lahendused oleks tunduvalt keerukamad. Näiteks võiks jagatud saladused krüpteerida kasutaja parooliga ning mõlemad serverisse saata. Samuti tuleks andmete krüpteerimisel kasutada paremat meetodit, kui vaikimisi seadistuses crypto.createCipher seda on (valida tuleks turvaline initsialiseerimisvektor jne.). Samuti on vaja lahendada mõistlik autoriseerimisprotsess, kus krüpteeritud andmeid saaks laadida ja salvestada ainult õige isik. Need küsimused ei ole samas käesoleva näite puhul väga olulised, kuna eesmärk oli lihtsalt tutvustada jagatud saladuste kontseptsiooni. Mida nende jagatud saladustega peale hakata, on juba igaühe enda välja mõelda.

teisipäev, 24. november 2015

hashcash elektroonilised postmargid

Üks võibolla veidi varju jäänud, kuid tegelikult laialt kasutatav kontseptsioon on töötamise kinnituse (proof of work) algoritm hashcash. Minu huvi selle algoritmi vastu on eelkõige seotud e-postiga, kuid algoritmi tuntuim kasutus on hoopis seotud krüptoraha Bitcoin protokolliga, sest justnimelt hashcash on see "ülesanne," mida kõik Bitcoini kaevurid jooksvalt lahendama peavad. Hashcashi räside omaduseks on see, et neid on raske genereerida (nõuab palju CPU jõudu), aga kerge kontrollida (CPU kulu on olematu).

Asja tuum on iseenesest lihtne: üks osapool saab hashcashi abil teisele tõestada, et on teinud mingi küsimuse lahendamise nimel märkimisväärse hulga tööd. E-posti puhul oleks pidanud see töö kujunema elektroonilise postmargi hinnaks. Saatja peab kirja saatmiseks investeerima mõnevõrra CPU tsükleid ehk siis maksma "margi" eest, kus "margiks" on töö tulemus ning margi olemasolu kirja päises tõestaks saatja panust. Lihtne ülesanne legitiimsele saatjale ("margi" genereerimine võtab võibolla vaid sekundi), aga raske spämmerile, kes peaks selliseid marke genereerima suures koguses.

Paraku ei saanud hashcash postmarkidest kunagi eriti asja. SpamAssassin suhtub margipäise (X-Hashcash) olemasollu positiivselt, aga sellega enamvähem selle levik ka piirdub. Spämmi küsimuses on see ka täiesti mõistetav – protokolli loojad ei saanud omal ajal kuidagi ette näha, et tänaseks on spämmerite käsutuses suure arvutusvõimsusega botnet'id, mis suudaks vajaminevaid marke arvutada tõenäoliselt kiireminigi (tegu on siiski väga kergesti paralleliseeritava ülesandega), kui legitiimsed saatjad seda teha saaks.

Nüüd aga siis algoritmi enda juurde. Tegu on suuresti tavalise räsi genereerimisega (hashcash puhul sha1, bitcoini puhul sha256), kuid mitte ainult. Töö tegemine garanteeritakse räsile tingimuste seadmisega, näiteks elektrooniliste markide puhul peavad räsi esimesed 20 bitti olema väärtusega 0. Mõnevõrra on see sarnane eelmises postituses kirjeldatud meetodile onion domeeninimede genereerimisele, ainult et kui seal tahtsime saada räsi (domeeninime) algusesse mingeid oma valitud sümboleid, siis hashcash puhul loetakse räsi algusest 0 bitte. Kusjuures margiks ei ole mitte räsi ise, vaid väärtus, millest sellise räsi saime.

Näide

Ütleme, et tahame saata kirja aadressile andris.reinman@gmail.com ning nüüd on meil vaja genereerida selle aadressi jaoks üks mark. Mark sisaldab andmeid algoritmi kohta (milline hashcash versioon, mitu nullbitti peab olema), saaja kohta (ehk siis saaja e-posti aadress) ning juhuslikku väärtust (nonce). Kuna nonce genereerimine võib olla liiga kulukas, siis saame väärtusele lisada ka kaunteri – iga kord kui teeme väärtusest räsi ja selle tulemus ei vasta tingimustele, suurendame kaunterit ühe võrra ja proovime uuesti.

Näitna kasutame järgmist marki (protokoll näeb ette väljade eraldajana koolonit):

1:20:151124104010:andris.reinman@gmail.com::riNR+WfrgW1XSEOr:1

Esimene väli on hashcash versioon (1), teine määrab vajaliku arvu nullbitte (20 bitti), kolmas on ajatempel kujul YYMMDD[HHMMSS], neljas on saaja aadress, viies väli on jäetud tuleviku jaoks tühjaks, kuues on nonce ja seitsmes on kaunter (ruumi säästmiseks kasutan kaunteris hex vormingus numbreid).

Igatahes kui me teeme sellest väärtusest sha1 räsi, saame tulemuseks sellise:

2871ead94a099c4b612db8751652f9e8ecf7af01

Nagu näha, ei vasta see kuidagi seatud tingimustele. 20 nullbiti jaoks peaks räsi hex vorming algama 5 nulliga. Aga proovime edasi, suurendame kaunterit nii kaua, kuni leiame soovitud väärtuse.

1946814 räsi hiljem on meil juba selline mark:

1:20:151124104010:andris.reinman@gmail.com::riNR+WfrgW1XSEOr:1db4be

Millest saamegi soovitud tulemuse, kus väärtuse esimesed 20 bitti on 0 bitid:

00000052aa08f0edf3b5d51cb2a1b1efe015af01

Edasi saame kleepida saadud margi juba e-kirja päisesse

X-Hashcash: 1:20:151124104010:andris.reinman@gmail.com::riNR+WfrgW1XSEOr:1db4be

Kui saaja taolise margiga kirja kätte saab, võib ta võtta margist sha1 räsi ja saada samuti sobiva tulemuse. Lisaks peaks saaja kirja panema ka nonce, sest ükski teine mark sama nonce väärtust enam kasutada ei saa. Kolmanda kaitsemeetmena peab saaja jälgima ka kuupäeva, et see ei oleks liiga kaugel minevikus ega ka tulevikus. Kui kõik klapib, võib saaja kirja ehtsaks pidada.

teisipäev, 17. november 2015

Tor peidetud teenus

Tor tarkvara saab kasutada kolmel eesmärgil. Esiteks muidugi anonüümselt veebis surfamiseks (see ei ole küll 100% riskivaba, kergelt puudutasin seda probleemi oma eelmises postituses), teiseks Tor peidetud teenustele ligipääsuks ning kolmandaks nendesamade peidetud teenuste loomiseks. Kui esimesega on selge – Tor võrgu kaudu saab avada suvalise veebilehe nii, et veebiserver näeb ühenduse algatajana mõnd muud IP aadressi, kui see, mida tegelikult kasutad, siis teise kahega mitte niiväga.

Mis on üldse peidetud teenus?

Peidetud teenus on selline veebiserver, millele pääseb ligi ainult Tor võrgust. See tähendab, et veebilehele jõudmiseks ei ole vaja läbida nn. exit node'i ehk seda masinat, mille kaudu suunatakse liiklus ümber Tor võrgust vabasse võrku, sest veebiserver ise ongi sellisel juhul exit node'iks. Peidetud teenuse tunnuseks on *.onion domeeninimi. Selline domeeninimi ei lahendu tava-DNS abil, küll aga suudab sellise veebiserverini päringuid juhatada Tor paketis olev Onion ruuter.

Peidetud teenus on oluline kahel põhjusel – kõigepealt on exit node läbimine alati turvarisk, kuna seda võib pidada mõni pahatahtlik osapool (HTTP protokolli kasutamine võib seega olla läbi Tor'i isegi ohtlikum kui ilma Tor'ita, sest Tor võrgus on suurem tõenäosus kui tavavõrgus, et keegi vahepeal võrguliiklust pealt kuulab), tegu on siiski avatud proksiga. Teiseks põhjuseks on see, et peidetud teenus on, nagu nimigi ütleb, peidetud. Veebiserveri kasutaja ei saa kuidagi järgi vaadata, et mis IP aadressi taga veebiserver asub ja et kellele see aadress kuulub.

Viimast väidet tasub muidugi võtta terakese soolaga, sest mõningases ulatuses on siiski võimalik selliseid teenuseid deanonümiseerida, lisaks annab tihti serveri aadressi ära kehvasti seadistatud või turvaaukudega veebiserveri tarkvara, robustsemaiks näiteks oleks see kui Apache 404 leht on konfitud kuvama veateate jaluses veebilehe tegelikku hostname'i või IP aadressi.

Kuidas peidetud teenust teha?

Peidetud teenus ei ole tegelikult muu, kui Onion ruuteri seadistamine valitud domeeninime ruutimiseks täiesti tavalise veebiserveri pihta. Veebiserver ise ei pea seega Tor võrgust mitte midagi teadma, veebiserver kuulab nagu ikka mingil kindlal TCP pordil sisenevaid päringuid, et neid teenindada ja Tor ei puutu kuidagi asjasse. Trikk on selles, et veebiserveri võib seadistada võtma vastu päringuid ainult Onion ruuteri aadressilt (ehk kui Onion ruuter ja veebiserver asuvad samas masinas, siis tohiks veebiserver teenindada ainult päringuid mis algatatakse localhost aadressilt), sellisel juhul ei ole võimalik veebiserverile ligi pääseda tavavõrgu kaudu, küll aga Onion ruuteri kaudu.

Aitab lobisemisest, teeme ühe uue peidetud teenuse

Järgnev juhend kasutab Ubuntu 14.04 LTS operatsioonisüsteemi, kõik käsud käivitatakse root kasutaja õigustes ning eeldame, et meil on juba olemas mingi veebiserver (näites aadressil 127.0.0.1:80 ehk tava HTTP port localhostis), mida soovime serveerida peidetud teenusena.

Samm 1. Installime Onion ruuteri

Tor tarkvara saamiseks on meil vaja lisada Tor repositooriumi andmed. Näites kasutame Ubuntu versiooni 14.04, teiste operatsioonisüsteemide jaoks vajaliku info leiab Tor projekti kodulehelt.

Niisiis, lisame süsteemi Tor repositiooriumi ning sellega seotud GPG võtme info:
$ echo "deb http://deb.torproject.org/torproject.org trusty main
deb-src http://deb.torproject.org/torproject.org trusty main" >> /etc/apt/sources.list
$ gpg --keyserver keys.gnupg.net --recv 886DDD89
$ gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | apt-key add -
Järgmisena saame installida vajaliku tarkvara
$ apt-get update
$ apt-get install git build-essential libssl-dev tor deb.torproject.org-keyring
Kus

  • git on vajalik hiljem Shallot nimelise tarkvara laadimiseks (vaata allpool)
  • build-essential on vajalik Shallot'i kompileerimiseks
  • libssl-dev on samuti vajalik Shallot'i kompileerimisel
  • tor on Tor tarkvara, sh. Onion ruuter
  • deb.torproject.org-keyring on Tor'i võtmerõngas

Kui kõik õnnestub, on meil serveris töökorras Onion ruuter. Kuna kolmandatele rakendustele paistab see tavalise SOCKS5 proksina, võime selle katsetamiseks teha mõne päringu rakendusega curl
$ curl --socks5-hostname 127.0.0.1:9050 duskgytldkxiuqc6.onion
Mille tulemus võiks olla umbes selline:
<html>
<head><title>Example rendezvous points page</title></head>
...

Kui kõik õnnestus, siis järelikult saame teha Tor võrku väljuvaid päringuid, kuid meid huvitavad hetkel rohkem sisenevad päringud, seega peame edasi tegutsema.

Samm 2. Genereerime unikaalse .onion domeeni

Selle sammu võib ka vahele jätta, kuna vaikimisi genereerib Tor tarkvara ise vajaliku *.onion domeeninime, kuid automaatselt genereeritud nimed on kergelt öeldes mittemidagiütlevad nagu eelmises olnud duskgytldkxiuqc6.onion. Palju parem oleks ju kui saaksime selle nime ise valida.

Halb uudis on, et domeeninimi tuletatakse räsina salajasest võtmest, seega peabki see näima juhuslik. Hea uudis on, et veidi saame selle nime kuju siiski kontrollida – seda juhul kui genereerime nii palju erinevaid võtmeid, et lõpuks leiame sellise, kus räsi ongi soovitud kujul. Heaks näiteks oleks Facebooki onion domeen facebookcorewwwi.onion, kuid siin tuleb jälle üks halb uudis – iga täiendav sümbol kasvatab domeeni arvutamisele kuluvat aega eksponentsiaalselt. Seega kui sooviks on arvutada Facebooki laadse 15 sümboliga räsi (eeldame, et viimane, 16. sümbol "i" on juhuslik), kuluks selleks miljoneid CPU-aastaid, mis ei ole tavainimesele kättesaadavad, seega peame leppima vähemate sümbolitega, näiteks kuus kohta valitud teksti ja 10 suvalist sümbolit. Kuuekohalise stringi leidmine võtab kuni 30 minutit, 7-kohalise leidmine võtab terve päeva, 8-kohalise leidmiseks kulub terve kuu jne.

Tor peidetud teenuse domeeninime leidmisega tegeleb näiteks Shallot. Järgmisena hangimegi Shalloti ja proovime leida domeeninime, mis algaks 6-kohalise stringiga "andris".
$ git clone git://github.com/katmagic/Shallot.git
$ cd Shallot/
$ ./configure && make
Kui rakendus on kompileeritud, saame sobiva domeeninime leida järgmise käsuga (argumendiks on regulaaravaldis, seega ^andris tähendab, et sellised sümbolid peavad asuma domeeninime alguses):
$ ./shallot ^andris
Kui kõik õnnestub, peaks umbes poole tunni jooksul laekuma ka esimene vastus
-------------------------------------------------------------------
Found matching domain after 549741619 tries: andris23zrbn2da5.onion
-------------------------------------------------------------------
-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQC7PBSSwX8IoWAHevf25yry/IQYHWbEa05nBtSty9jAlxmNfZmy
jUcwJKZRZtzghyUgH04n7VwaQWOe8R0Vt6zIUOE+D8jGVhHj9Y/Sgy09e1AgiS2A
...eemaldatud read...
ISB3KXkCpvbdWThFACkCQQC2zfj+XlbFptT2FGou4jSAuKVukvnL/W0ZBDN7D1HT
nBMvIfOd4qt1sqGdXqocbI/DmCdsTWntHIUroj3bNwMX
-----END RSA PRIVATE KEY-----
Siit näeme, et Shallot on leidnud meile domeeninime kujul andris23zrbn2da5.onion ning sellele vastava salajase võtme.

Järgmiseks tuleks leitud domeeninimi lisada Tor konfiguratsiooni. Selle jaoks loome kataloogi, kus hakkavad asuma domeenime andmed
$ mkdir -p /var/lib/tor/hidden_service
$ echo "andris23zrbn2da5.onion" > /var/lib/tor/hidden_service/hostname
$ nano /var/lib/tor/hidden_service/private_key
Viimase käsu peale avaneb tekstiredaktor, sinna pasteerime siis salajase võtme ning salvestame faili.

Tor nõuab kindlaid piiratud failiõigusi, seega muudame failide omanikku ja õigusi
$ chmod -R 0700 /var/lib/tor/hidden_service
$ chown -R debian-tor:debian-tor /var/lib/tor/hidden_service
Nonii, nüüd ongi domeeninimi seadistatud ja saab minna järgmise sammu juurde.

Samm 3. Konfigureerime Tor HiddenService andmed

Praeguseks on kõik eeldused täidetud ja üle jääb vaid peidetud teenus aktiveerida. Selle jaoks modifitseerime torrc konfiguratsioonifaili.
nano /etc/tor/torrc
Otsime üles HiddenServiceDir ja HiddenServicePort väärtused ning eemaldame nende ridade eest kommentaarisümbolid #, nii et need read peaks failis olema järgmisel kujul
HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:80
Esimene väärtus näitab ära kausta, kus asuvad domeeninimega seotud failid (kui seda kausta ei eksisteeri, genereeritakse see koos suvalise domeeninimega automaatselt). Teine näitab ära, et millisel siseneval pordil (näites port 80) võtab Onion ruuter päringuid Tor võrgust vastu ning millisele veebiserverile (näites localhost ehk 127.0.0.1:80) need päringud edastab.

Peale konfigureerimist jääb teha viimane liigutus, milleks on Tor teenuse taaskäivitus
$ service tor restart
Nüüdsest peakski olema valitud aadress Tor võrgu kaudu ligipääsetav.

Kui teenus on püsti, saame seda kontrollida ka ilma Tor brauserita. Sellisel juhul võime tavabrauseris avada veebilehe läbi onion.to veebiproksi. Näites kasutatud domeeni saab seega lahti aadressilt https://andris23zrbn2da5.onion.to/

Lõpetuseks

Nagu näha, ei ole peidetud teenuse seadistamises midagi ilmvõimatut. Kõige olulisem oleks, et meil on üldse mingi veebiserver, mida Tor võrku välja näidata. Samuti tuleks kindlasti väga hoolega jälgida serveri seadistust, et see ei annaks välja mingit infot serveri tarkvara ega ka server enda kohta, seega ei mingeid phpinfo() faile. Maha tuleks keerata X-Powered-By, Server ja muud seonduvad vastusepäised. Apache veebiserveri puhul tasuks üle vaadata ServerTokens ja ServerSignature seadistused, samuti ka Indexes valik, kuid kõige parem oleks üldse mitte Apachet kasutada. Nginx on tunduvalt parem, aga kõige mõistlikum oleks võibolla ehitada minimaalne staatilist sisu serveeriv Node.js põhine server, siis võib kindel olla, et kuskil ei ole kogemata jäänud mõni konfiguratsiooniparameeter korrektselt seadmata. Vastasel korral pole nagu erilist mõtet üldse peidetud teenust püsti panna, see ei oleks ju enam peidetud.

esmaspäev, 9. november 2015

Kuidas kübermaailmas turvaliselt toimetada

Järgnev postitus pole mitte absoluutne tõde, vaid minu nägemus ja isiklikud soovitused kübermaailmas ringi toimetamiseks. Peamiselt kirjutan sellest, et mis tarkvara ja vahendeid pean turvaliseks ja ise ka kasutan. Lisaks triviaalsele ehk suvaliste mailimanuste mitte-avamise ning võõraste mälupulkade mitte-kasutamise kõrval eelistan selliseid vahendeid, mis sobiks lõppkasutajale ja mis ei nõuaks liiga detailseid teadmisi või keerulist konfigureerimist. Kuna mul ei ole mingeid erilisi saladusi mida kaitsta, siis on full-paranoid mode minu jaoks küll veidi võõras, kuid see ei tähenda, et ei peaks ettevaatlik olema – ka näiteks perefotosid tuleb turvata, sest nende pealt on hea planeerida parimat aega vargile tulekuks.

Apple seadmed

Olen töötanud Eesti, Saksa ja Ameerika startuppide heaks ja kõikjal on kasutatud just Apple arvuteid. Esiteks on tegu väga hea hinna ja kvaliteedi suhtega, arvutid on vastupidavad, alumiiniumkorpus ei kulu, klahvid käivad sujuvalt ka peale aastaid kasutamist. Teiseks muidugi see, et OSX pole muud kui Unixi skinn, mis tähendab, et OSX shell on enamvähem sama funktsionaalsusega kui Linuxi shell. Seega ideaalne arendaja-arvuti. Unix teatavasti on suhteliselt turvaline operatsioonisüsteem, ka OSX on aastaid uhkustanud viiruste puudumise üle ja suures osas on see olnud õigustatud. Täna muidugi ei saa milleski liiga kindel olla, kuid OSX "viirused" on reeglina siiski kasutaja poolt ise lolli peaga masinasse lubatud troojalased, mitte iseseisvalt sinna roninud. Piraattarkvara ma põhimõtteliselt ei kasuta ja just seetõttu, et ma ei saa kindel olla, et mida see tegelikult sisaldab.

Mobiiliseadmetest on iPhone hinna poolest küll kallim kui suurem osa Androidi analooge, kuid pikas plaanis ei pruugi hinnavahet üldse olla. Kõigepealt jälle kvaliteet, aastane iPhone on normaalse kasutuse juures peaaegu nagu uus, samas kui kõik Androidi mudelid, vähemalt need mis mul on olnud, näitavad juba väsimuse märke. Teiseks saavad ka 4 aasta vanused iOS seadmed loetud päevade jooksul viimased tarkvarauuendused (4S jooksutab uusimat iOS versiooni, kuigi anti välja juba 2011), samas kui Androidi maailmas pole haruldane, et eelmise hooaja seadmele peab tarkvarauuendust ootama pool aastat ja üleeelmise hooaja telefonile ei tulegi enam kunagi ühtegi uuendust. Kui telefoni tarkvaras on aga teada olevad turvaaugud ning parandust neile kuskilt ei paista, ei ole väga mõtet sellist telefoni pikalt pidada. Varem viitsisin tegeleda igasugu ruutimiste ja CyanogenMod tarkvaraga, aga enam mitte, mulle piisab kui need paar äppi mida reaalselt vajan, töötaks turvaliselt ja sellega saab iPhone suurepärast hakkama.

Ketaste krüpteerimine

FileVault (System Preferences → Security & Privacy → FileVault) võimaldab krüpteerida terve ketta. Täpsemalt jagab FileVault ketta kaheks partitsiooniks – väikeseks boot partitsiooniks, kus asuvad parooliga lukustatult võtmed ning siis nende võtmetega krüpteeritud partitsiooniks, kus asuvad kõik failid. Kui arvuti käima panna, laetakse boot partitsioonilt OSX kasutajaliidest meenutav sisselogimisvaade, peale kasutaja valimist ja parooli sisestamist lukustatakse krüpteeritud partitsioon lahti ning algab tegelik süsteemi käivitus.
FileVault on selles arvutis sisse lülitatud

TimeMachine võimaldab varukoopiad samuti krüpteerida. Selle jaoks tuleb TimeMachine ketta valikul teha linnuke kasti "Encrypt backups".

TimeMachine puhul tuleks jälgida, et linnuke oleks kastis "Encrypt backups"
TrueCrypt krüpteeritud ketaste loomiseks on endisel kasutuskõlbulik, kuigi selle autorid on kutsunud üles TrueCrypti enam mitte kasutama. Alternatiivina on võimalik kasutada ka TrueCrypt kloone, näiteks VeraCrypt, mille arendus käib erinevalt TrueCrytptist edasi. Kloonide probleemiks on peamiselt litsentsiküsimused, sest TrueCrypt oli küll tasuta tarkvara, aga mitte open source selles mõttes et igaüks tohiks koodi kopeerida. Rakenduse kood oli nähtav ainult sõltumatute auditite tegemiseks, mitte enda tarkvaras kasutamiseks.

Paroolide majandamine

Paroolidega majandamiseks kasutan paroolihaldurit. Varasemalt olen paroolihalduritest juba juttu teinud, ise kasutan kõikide paroolide jaoks (va. ID kaardi PIN koodid, mis on peas) just LastPass haldurit ning täpsemalt selle tasulist versiooni hinnaga $12 aastas. LastPass sisselogimise teiseks faktoriks kasutan Yubikey OTP võtit ning iPhones on LastPass avamiseks Touch ID ehk sõrmejälg. Loomulikult on mul igal pool kus võimalik, sisse lülitatud kahefaktoriline autentimine.

sudo parooli saab visudo kaudu maha võtta, kuid see ei ole soovitav ja mina pole nii ka teinud. Kui on teada, et tuleb teha rohkem tegevusi root kasutajana, on mõistlik minna root kasutaja režiimi käsuga sudo su ning sisestada see parool ühekordselt, mitte iga natukese aja tagant uuesti. Kui enam root õigusi pole vaja, siis panna terminali aken kinni või minna tavakasutaja režiimi tagasi käsuga exit. Kui installida homebrew pakihaldus, siis tuleks samuti jälgida, et see saaks tehtud tavakasutaja õigustes, mitte sudo abil

ssh võtmed peaksid olema kindlasti parooliga kaitstud. OSX võimaldab võtme parooli Keychaini salvestada (kuna ma ei ole paranoid modes, siis kasutan Keycahini palju, kuid kui on põhjust paranoiline olla, siis tasuks seda muidugi vältida või vähemalt panna Keychainile eraldi parool ja iCloudi seda mitte sünkida), sellisel juhul pole vaja parooli edaspidi üldse käsitsi sisestada, aga kui keegi peaks id_rsa failist kuidagi koopia tegema, ei saa ta seda ilma paroolita kasutada.

OSX jooksutab rss-agent tarkvara automaatselt, seega tuleb ssh võtme parool sisestada vaid korra. Kahjuks on keegi hull arendaja otsustanud, et sellele parooliväljale ei saa teksti pasteerida, seega on pika parooli sissetoksimine üsna tüütu

Tor võrgu kasutamine

Tor brauser ei ole imevahend, tegu on tavalise Firefox klooniga, mis jätab süsteemi sarnaselt Firefoxiga erinevaid jälgi. Lisaks on ka Eestis olemas kohtulahend, kus inimene jäi süüdi küberründes, kuna kasutas Tor võrku samal ajal, kui toimus rünnak Tor võrgust. Tor võrgust kirjutan võibolla mõni teine kord pikemalt, eelkõige siis hidden service'ite tegemisest, aga praegu mainin vaid ära, et Tor brauser on lihtsalt teise nimega Firefox, millel on maha keeratud mitmeid featuure, mis võiks potentsiaalselt anda välja kasutaja identiteedi ning mis on seadistatud ühenduma internetti läbi SOCKS5 proksi pordil 9150. Kõige olulisem tarkvara Tor süsteemis on ikkagi Onion ruuter, mis ühelt poolt ühendub Tor võrku ja teiselt poolt tekitab teistele rakendustele kasutamiseks sellesama SOCKS5 proksi.

Turvaline e-post

PGP e-posti krüpteerimiseks on kõige parem tarkvara GPGTools, mis on OSX Mail rakenduse plugin. S/MIME toetus on mailirakendustes reeglina parem, kuid see on rohkem enterprise kasutajatele. Tavakasutajate jaoks on de facto mailikrüpto lahendus ikkagi PGP ning praeguseks on selle taga ka näiteks Saksa riik. GPGTools on tunduvalt stabiilsem kui näiteks Enigmail ning selle ainsaks miinuseks on mõningane viide uute OSX versioonide toetamisel.

Sõnumineerimine

Sõnumiäppide puhul on privaatsustasemeid mitu ning valida tuleks endale sobivaim, sest kõige turvalisem ei tähenda kõige mugavamat ja vastupidi. Täiesti out on vanad lahendused nagu MSN Messenger (see vist enam ei töötagi?), ICQ jne. Facebook Messenger on turvaline selles mõttes, et seda ei saa jälgida samas võrgus olevad pahalased, sest käib üle HTTPS protokolli. WhatsApp, iMessage, Facetime on turvalised selles mõttes, et kasutavad end-to-end krüptot, nii et seda ei saa pealt kuulata ka teenusepakkuja, kuid samal ajal ei saa kindel olla, et kas end-to-end on teenusepakkuja poolt ikka sisse lülitatud. Telegram on turvaline samuti end-to-end krüpto tõttu, kuid selle lahendus ei ole just kuulikindel. CryptoCat on teoorias turvaline kuid praktikas leitakse sellest tihti olulisi turvalisust vähendavaid vigu. Signal on turvaline end-to-end tõttu (erinevalt Telegramist kasutab ka turvalist protokolli) ning see on samal ajal kontrollitav, kuid selle kasutajaid on vähem kui muudel teenustel. Ühesõnaga, kui kardate nuuskivaid kolleege, siis on juba Facebook Messenger piisavalt turvaline (eeldusel, et arvutis ei ole registreeritud ettevõtte CA serti ja liiklus ei käi läbi ettevõtte proksi, mis HTTPS liklust murraks), kui aga muretsete välisriikide luureteenistuste pärast, siis oleks Signal õige valik.

Võrdluseks, terroristid kasutavad Amn Al-Mujahid krüpteerimistarkvara, mida annab välja Al Fajr Media Center Technical Committee, kuid see tarkvara laetakse miskipärast HTTP protokolli kaudu ning seetõttu ainult jumal teab, mis sealt tegelikult alla tuleb, tõenäoliselt hoopis mingi NSA spyware.

VPN ja turvalised ühendused

Ma ei kasuta VPN'i, aga kui see on võimalik, siis teistel kindlasti soovitan. Ma ei kasuta eelkõige seetõttu, et mul on kodus küll VPN võimeline võrguketas, kuid ma ei taha väljastpoolt mitte mingeid ühendusi koduvõrku lubada. Eraldi VPS'i seadistada pole viitsinud ning teenust osta pole raatsinud. Seega kasutan võõras võrgus HTTP saitidega ühendumiseks tavaliselt ssh tunneli põhist proksit. Juhul kui on ligipääs mõnda VPS serverisse, on tunneli ülesseadmine imelihtne ja see ei vaja mingit lisatarkvara, piisab vaid järgmisest käsust:

ssh -f -N -D 1080 vpshost

kus 1080 on port, millel hakkab toimetama SOCKS5 proksi ja vpshost on mõne VPS serveri hostname või IP aadress. Brauser tuleb seadistada kasutama netti ühendumiseks sedasama localhost:1080 proksit ja edasi käibki ühendus krüpteeritud kujul ja võõras võrgus nuuskijate pärast pole vaja enam muretseda.

Virtuaalmasinate kasutamine

Juhul kui on tarvis siiski külastada kahtlasi veebisaite või käivitada kahtlasevõitu rakendusi, siis ei tasu seda kindlasti teha omaenda arvutis. Õnneks on mõeldud välja mugav lahendus virtuaalmasinate näol, mina kasutan selleks tasuta VirtualBox tarkvara. Selle jaoks tuleks siis tekitada mingi virtuaalmasin, installida kõik uuendused ja teha sellest snapshot. Kui nüüd on vaja toimetada kahtlastes nurgatagustes, siis võibki seda teha selles virtuaalmasinas. Kui vajalikud toimingud on tehtud, tuleks taastada virtuaalmasina esialgne snapshot ning kui midagi märkamatut sattuski virtuaalmasinasse, siis kõik vahepeal toimunud muudatused kaovad snapshoti taastamisel ning tulemuseks on täpselt samasugune masin nagu see enne kasutamist oli.

Kokkuvõtteks

Üritan elada turvalist elu, samas end mitte lolliks mõeldes. Eelkõige tuleks hinnata võimalikke riske ning kui riske pole, siis pole mõtet ka liiga palju turvata. Facebook Messenger on siin heaks näiteks, ilmselt ei kaitse see mind NSA eest, küll aga saan selle kaudu kontakti pea igaühega ning samas on selle turvalisuse tase piisavalt kõrge, et päris igaüks neid vestlusi lugeda ei saa. Üle mõeldes tekib oht vindi pealekeeramiseks ning tulemuseks võib olla hoopis ebaturvaline lahendus, näiteks hiljuti tähelepanu leidnud PHP CodeIgniter klass RSA krüptograafiaks.

Jah, just nii tuleb valida RSA algarve, see viib turvalisuse uutesse kõrgustesse

Ühesõnaga, kainet mõistust! Ei tasu õnnega mängida, aga ei tasu ka üle mõelda.

esmaspäev, 2. november 2015

Turvalistest paroolidest

Jätkaks küberhügieeni teemadel. Kui varasemalt oli juttu kahefaktorilisest autentimisest, siis seekord vaatleks autentimise esimest faktorit ehk paroole.

Kui kiirelt meelde tuletada, siis on tavalised nõuanded paroolide valimisel järgmised:
  • Paroolid peavad olema võimalikult pikad
  • Paroolid peaksid sisaldama võimalikult erinevat tüüpi sümboleid
  • Paroolid ei tohiks olla arvatavad (n. koera nimi, sünnipäev vms.) ja need ei tohiks olla üldkasutatavate paroolide nimekirjas (passw0rd, 123456 jne.)
  • Paroole peaks vahetama, mitte hoidma kasutuses igavesti
  • Paroole ei tohiks taaskasutada (st. et erinevate veebilehtede jaoks ei tohi kasutada sama parooli)
  • jne.

Keerukate reeglite eesmärk on takistada nn. brute force meetodil paroolide murdmist, kus proovitakse läbi kõik võimalikud paroolid. Analoogiks oleks 4 kohalise numbrikoodiga kohvriluku avamine – näiteks kui sellise kohvriluku avamise kood on 0345 ning proovime seda avada brute force meetodil, siis peaksime käima läbi küll 345 erinevat koodi (0000, 0001, 0002, …, 0345), kuid lõpuks saaksime selle luku ikka lahti. Nelja numbri puhul on võimalikke proovimisvariante 104 ehk 10 000, nii et kuigi kõikide variantide läbiproovimine võtab veidi aega, on see siiski igaühe poolt murtav, seega tuleks tagada, et võimalikke variante poleks mitte 10 000, vaid tunduvalt rohkem ja seda need reeglid teevadki.

Väikese entroopiaga paroolid, näiteks samuti neljakohaline SIM kaardi PIN1, on tavaliselt kaitstud katsete arvu piiranguga. Kui sisestad kolm valet PIN'i, siis pead hakkama sisestama pikemat PUK'i, ning kui ka seda on sisestatud 10 korda valesti, võib kaardi ära visata. Paroolide brute force'imise all peame seega rohkem silmas neid lahendusi, kus korduste arv pole piiratud, näiteks parooliräside varguse järel nende räside lahendamist kõikide võimaluste läbi proovimise läbi (eeldusel, et räsid pole koostatud lohakalt ning ei ole koheselt murtavad juba eksisteerivate rainbow tabelite abil).

Kui kasutame ainult väikeseid ladina tähti, on kuukohalise parooli võimalike variantide arv 266 ehk 308 915 776. Kuigi inimese jaoks on see hulk juba liiga suur, siis arvutile on veel jõukohane. Kui lisame ka numbrid, siis saame ühe suurusjärgu võrra variante juurde (366 ehk 2 176 782 336). Kui teeme vahet suur- ja väiketähtedel, saame veel ühe suurusjärgu (626 ehk 56 800 235 584, teisiti väljendudes oleks see log262*6 ≈ 36 bitti entroopiat, kus iga täiendav sümbol, eeldusel et see sümbol valitakse juhuslikult, annaks 6 bitti entroopiat juurde). Ühesõnaga, iga kord kui teeme reegleid keerulisemaks, suurendab see tublisti võimalike variantide arvu, mida brute force ründaja peaks kasutaja parooli murdmiseks läbi proovima.

Lühidalt ütleks, et kõigi nende reeglite täpne täitmine on siiski mission impossible. Kuigi idee poolest tore, ei ole inimese aju mõeldud suures koguses suvaliste sümbolijadade meelde jätmiseks ja selline lähenemine lõpeb varem või hiljem paroolidega kollasel märkmepaberil kuvari küljes. Olukorra lihtsustamiseks on välja pakutud mitmeid mnemoonilisi võtteid. Populaarne koomiks XKCD soovitab kasutada paroolina lauseidDiceware soovitab valida parooliks samuti sõnu, kuid valida need täringuheitega. Esineb ka soovitusi moodustada lauseid, aga kasutada vaid sõnade esitähti jne.

Selliste soovituste probleemiks on tihti võlts-turvalisustunne.  Kui parooli moodustamise meetodist teavad "tavainimesed," siis päris kindlasti on sellega juba kursis ka kõik paroolikräkkerid. Paroolikräkkerid reeglina ei proovi läbi kõiki paroole vahemikus "aaa…" kuni "zzz…", kuna see võtaks liiga kaua aega, selle asemel alustavad nad ikka enim tõenäolistest variantidest. Tuntud turvauurija Bruce Schneier väidabki, et XKCD pakutud lahendus ei ole selle tõttu täna enam turvaline. Kui võtta puhtalt kasutatud sümbolite arvu järgi, siis oleks "correct horse battery stable" tõesti eeskujulik parool, probleemiks on, et tegu on nn. tavaliste sõnadega, mille arv on üsna piiratud. Muidugi saab nii luua tõeliselt turvalisi paroole, kuid ise "juhuslikult" sõnu valides võib tegelik saada olevate sõnade ring olla ikka üsna väike. Punast haamrit mäletab veel keegi? Veidi aitab eestikeelsete sõnade, eriti täpitähtedega sõnade vähene tuntus, neid tõenäoliselt esimeses järjekorras siiski ei proovita.

Lavale astub paroolihaldur

Paroolidega seotud riskide maandamiseks kasutabki iga turvalisuse pärast muretsev inimene paroolihaldamise tarkvara, selmet tegeleda triviaalsustega nagu uute keeruliste paroolide välja mõtlemine ja nende pähe tuupimine.

Paroolihalduri korral tuleb meeles pidada vaid üht parooli ehk paroolihalduri ülemparooli paroolifailile ligipääsuks. See võiks tõesti vastata kõikidele nendele eelpool kirjeldatud reeglitele, sest kõigest ühe keerulise parooli meeles pidamine ei tohiks siiski olla üle võimete. Kui paroolihaldur seda võimaldab, tuleks autentimiseks kindlasti kasutada ka teist faktorit.

Paroolihaldurite tarkvara võib laias laastus jagada kolme kategooriasse:

  1. Tarkvara, mis töötab ainult kasutaja arvutis ning sellest paroolide kätte saamiseks tuleb kasutada Copy-Paste meetodit. Sellised on näiteks PasswordSafe ja KeePass. Kuigi tegu on kõige turvalisema variandiga, võib selline pidev käsitsi paroolide ringi tõstmine olla üsna ebamugav.
  2. Tarkvara, mis salvestab paroolid kasutaja arvutis, kuid on integreeritud muu tarkvaraga (brauseri pluginad võimaldavad veebilehtede paroolivälju automaatselt täita, DropBoxi integratsioon võimaldab paroolifaili sünkroniseerida eri seadmete vahel jmt.). Selline on näiteks 1Password. See on samuti üsna turvaline kuna paroolifail on kasutaja kontrolli all, kuid liidestus brauseriga tekitab omad riskid.
  3. Tarkvara, mis salvestab paroolifaili "pilves" (tavaliselt küll krüpteeritud kujul, nii et paroolifaili avamine toimub alati kasutaja arvutis ning teenusepakkuja väidetavalt nendele andmetele ligi ei pääse) ja on samuti integreeritud muu tarkvaraga brauseri pluginate jms. abil. Selline on näiteks LastPass. Teoorias turvaline (de/krüpteerimine toimub kasutaja arvutis), praktikas jääb igaühe oma hinnata, kas usaldab oma teenusepakkujat või mitte.

LastPass abil Zone.ee lehele sisselogimine. Kasutajanime lahtrisse tekib lisanupp, millele vajutades avaneb selle saidi jaoks salvestatud kasutajate nimekiri. Nimel klikkides täidetaksegi autentimisväljad valitud kasutaja andmetega.
Paremate võimalustega paroolihaldur võib maksta küll veidi raha, kuid kui üldse oma raha mingi tarkvara alla panna, siis võiks see just olla paroolihalduri tarkvara. See muidugi ei tähenda, et tasuta poleks võimalik – suur osa paroolihalduritest ongi täiesti tasuta või siis osaliselt tasuta. Tasulised versioonid pakuvad lihtsalt mugavamaid või paremaid võimalusi. Näiteks LastPass lubab tasulisel kontol kasutada autentimise teiseks faktoriks Yubikey võtmeid, 1Password pro-mobiiliäpp võimaldab hallata ka TOTP koode jne. Enne ostu tasuks muidugi võrrelda tasuta ja tasulise pakkumise erinevust, võibolla tasuline variant ei annagi midagi vajalikku juurde, kõik sõltub konkreetsest kasutajast.

Korralik paroolihaldur töötab ka mobiilis. Siin on näha kuidas Zone.ee lehel iOS brauseri lisamenüüs on ka LastPass valik. Sellel vajutades avaneb salvestatud kasutajate nimekiri ning seejärel sobivale nimele vajutades täidetaksegi autentimisväljad salvestatud kasutaja andmetega.
Paroolihaldur on selles suhtes üsna anomaalne lahendus – ühest küljest teeb see kasutaja paroolid turvalisemaks ja raskemini murtavaks, mis võiks nagu tähendada ka lisandunud keerukust, teisest küljest aga muudab elu hoopis mugavamaks, kuna pole vaja enam paroole ise trükkida, selle töö teeb edaspidi ära seesama paroolihaldur. Moodsates brauserites on paroolide salvestamine ja täitmine samuti sisse ehitatud, kuid paroolihaldur töötab brauserite ja platvormiüleselt. Sama lahendus töötab nii töölaual brauseris X, kui ka mobiilis brauseris Y.

Kas on ka miinuseid?

Jah, on üks suur miinus, nimelt konsolideeritud paroolifail. Kui ründaja saab kätte paroolifaili ja mõistatab/varastab ülemparooli paroolifaili avamiseks, siis on kõik ligipääsud ründajal käes. Isegi kui ülemparool ei ole teada, võib paroolifaili sisu saada kätte kasutaja arvuti mälust. Absoluutselt kõike ei tasu seega sinna jätta, näiteks ID-kaardi PIN koodid võiksid olla siiski peas, mitte paroolihalduris. Samas, täielik ligipääs kasutaja arvutile paroolifaili kättesaamiseks on siiski tunduvalt vähem tõenäolisem, kui see et rogue veebileht salvestab kasutaja parooli ja proovib sama kasutajanime ja parooli kombinatsiooni hiljem ka kõikidel muudel võimalikel veebisaitidel, kus kasutajal võiks konto olla. Seetõttu kuulemegi üsna tihti inimestest, kes Gmaili kaudu "kojusõiduks rahapalveid" laiali saadavad, aga ei kuule nendest, kelle paroolihaldur oleks ära häkitud ja sellest paroolid kätte saadud. Pealegi, paroolihalduriga seotud riske saab maandada ka teise faktori kasutuselevõtuga.

Lõppude lõpuks on turvalisus alati kompromiss. Suure tahtmise korral oleks siiski võimalik paroolid pähe õppida või vähemalt kirjutada kuskile märkmikku, mis asub salajases kohas saja luku taga, kuid tavakäitumises on mugavus siiski väga oluline. Kui me peaksime iga parooli sisestamiseks minema salajasest šeifist salajast märkmikku tooma, et sealt trükkida käsitsi ümber 50 kohaline sümbolite rägastik, siis lõppeks see üsna kiirelt mõne kavala, kuid turvalisuse nulli viiva "parandusega," näiteks sellega, et autentimine lülitatakse hoopis välja.



Lugemist


kolmapäev, 28. oktoober 2015

Miks STARTTLS on paha?

STARTTLS on meetod kliendi ja serveri vahelise turvamata ehk vabatekstilise ühenduse üleviimiseks krüpteeritud ühendusele. Klientrakendus saadab sellisel juhul serverile käsu STARTTLS (või STLS või kuidas iganes käsu nimetus juhtub olema), server aktsepteerib seda, seejärel toimub tavapärane võtmevahetus ning edasi liiguvad kõik andmed juba krüpteeritud kujul. Kõige rohkem kasutatakse seda e-posti protokollides (SMTP, IMAP, POP3), kuid ka mujal (XMPP, LDAP jne.). Tundub nagu päris hea idee või mis? Kõik me ju armastame krüptot?

Noh, ei ole hea idee. Tegu on järjekordse sea-selga-sadul lahendusega. Kõigepealt oli meil siga ehk mingi hästi toimiv vabateksti protokoll, seejärel avastasime, et oleks vaja kuidagi kasutada ka krüpteeringut ehk sadulat, paneme nüüd kaks asja kokku ja ongi hobune. Oleks nagu seesama vana vabateksti protokoll, kõigest pisikese laienduse lisamise abil saame edaspidi andmeid edastada krüpteeritult, segamata seejuures vanade rakenduste tööd, mis krüpteeringut kasutada ei mõista.

Mida siis STARTTLS võrreldes täielikult krüpteeritud ühendusega meile praktikas annab? Ükski normaalne ("normaalne" ei ole kahjuks sama, mis "kõik") server ei luba tänapäeval kasutajal edastada paroole üle turvamata ühenduse. Selline autentimiskatse blokeeritakse mõistlikult seadistatud serveri poolt üsna kiirelt. Mida aga saab teha autentimata serveris? Tuleb välja, et ei saagi suurt midagi (välja arvatud muidugi MTA serverid, millest tuleb juttu allpool). Näiteks nii SMTP kui ka IMAP puhul on autentimata olekus lubatud vaadata vaid serveri poolt toetatud laiendusi (SMTP puhul näitab neid EHLO käsk, IMAP puhul CAPABILITY), samas IMAP serverid näitavad autentimata olekus tihti vaid neid laiendusi, mida on vaja otseselt autentimiseks, seega ei ole sellest infost suurt kasu.

Võrdleme näiteks Apple iCloud IMAP serveri CAPABILITY väljundit:

Autentimata olekus:
* NK11P00MM-ISCREAM001 14F39 XAPPLEPUSHSERVICE IMAP4 IMAP4REV1 SASL-IR AUTH=ATOKEN AUTH=PLAIN
Autenditud olekus:
* XAPPLEPUSHSERVICE IMAP4 IMAP4REV1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS CHILDREN BINARY UNSELECT SORT CATENATE URLAUTH LANGUAGE ESEARCH ESORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES CONDSTORE ENABLE CONTEXT=SEARCH CONTEXT=SORT WITHIN SASL-IR SEARCHRES XSENDER X-NETSCAPE XSERVERINFO X-SUN-SORT ANNOTATE-EXPERIMENT-1 X-UNAUTHENTICATE X-SUN-IMAP X-ANNOTATEMORE XUM1 ID IDLE
Ühesõnaga, juhul kui meil on võimalik valida algusest peale krüpteeritud ühenduse (IMAP puhul siis IMAPS pordil 993) ja algselt vabatekstilise, kuid STARTTLS abil krüpteeritud olekusse üleminekuga ühenduse vahel (IMAP puhul siis pordil 143), siis STARTTLS ei anna meile praktikas mitte mingisugust eelist, küll aga teeb lahenduse keerulisemaks. Mis viibki meid järgmise punkti juurde.

STARTTLS implementeerimine tarkvaras

Ilmneb, et vabatekstiliselt ühenduselt krüpteeritud ühendusele üleminek ei olegi nii hästi programmeerimiskeelte ja teekide poolt toetatud kui võiks arvata. Halval juhul pole seda võimalust üldse (valida on kas vabateksti või krüpteeritud ühenduse vahel, kuid mitte hilisema muutmise vahel), veidi paremal juhul on see küll võimalik, aga implementatsioon võib olla bugine (sest see on keeruline ning harva vaja minev featuur). Eriti halval võimalusel, nagu veel suhteliselt hiljuti oli Chrome brauseri laienduste jaoks mõeldud chrome.socket API puhul, on ainult vabateksti võimalus ning krüpteeritud ühenduste loomise võimalus puudub sootuks. Kui programmeerimiskeele teegid üleminekut ei võimalda, on alternatiivselt võimalik SSL/TLS kiht ise implementeerida (lõppude lõpuks käib kõik ju üle sellesama tcp ühenduse, ainult vorm muutub), aga selle tulemuseks on algselt ühe probleemi morfeerumine umbes kuueks tuhandeks veel suuremaks probleemiks ja seega on see kõige viimane tee üldse, mida mööda minna.

Turvaprobleemid

Kui algusest peale krüpteeritud ühenduse puhul on kõik selge, me kas kasutame krüpteeringut või me lõpetame töö, siis üleminekuga ühenduse korral pole kõik sugugi nii ühene. Vaatame näiteks niiöelda tavalist STARTTLS kasutusjuhtu:

Joonis 1. Klient läheb serveriga suheldes üle krüpteeritud ühendusele


Kõik on lihtne ja selge. Klient näeb võimalust STARTTLS kasutamiseks ning läheb üle krüpteeritud ühendusele. Vaatame nüüd veidi keerulisemat juhtu:

Joonis 2. Kliendi ja serveri vahel olev MITM peidab STARTTLS võimaluse ning klient jääb kasutama vabatekstiliselt ühendust

Siin on asjad juba vähem selged. Seekord ei ühendu klient mitte autentse serveriga, vaid MITM ründaja serveriga (selline olukord võib igapäevaelus tekkida näiteks siis, kui ollakse parasjagu ühendunud mõnda "tasuta" wifi võrku, mille ruuteris olev DNS server saadab kõik ühendused ründaja serverisse). MITM server muutub siinkohal passiivseks proksiks, kuid kõigepealt avab ta tegelikku serverisse turvatud ühenduse, kliendile esitab aga andmed nagu server ei toetakski üldse krüpteeringut. Klient läheb seepeale turvamata ühendusega edasi (ühtegi reeglit pole ju rikutud), server aga omakorda arvab, et ühendus on krüpteeritud ja kõik korras.

Protokollilised probleemid

Ütleme, et meil on MTA server, mis soovib edastada kirju meie jaoks tundmatusse MX serverisse A. Avame vabatekstilise ühenduse serverisse A pordil 25, saadame oma EHLO ja vastu saame info, et server toetab STARTTLS laiendust. Väga tore, algatame ülemineku. Nüüd aga tekib tõrge, serveri nimi on A, kuid sertifikaat on nimele B või on see aegunud või on see ise-allkirjastatud, ühesõnaga – sert on vigane. Mis teha?

Juhul kui me eeldaksime, et ühendus peab olema kindlasti krüpteeritud, siis tekiks siinkohal veaolukord ja kiri jääks edastamata. Kuid STARTTLS puhul ei ole asjad nii lihtsad. Liiklus pordil 25 ei ole mõeldud olema krüpteeritud, seega vabatekstiliste andmete edastamine oleks nagu OK. Vigane sert võib tähendada MITM'i ja sellise ühenduse kaudu andmete edastamine nagu ei oleks OK, vastasel korral ei oleks ju krüptost mitte mingit kasu.

RFC2595, mis käsitleb STARTTLS implementeerimist, on lahendanud asja muidugi geniaalselt:
The decision about whether acceptable authentication or privacy was achieved is made locally, is implementation-dependent, and is beyond the scope of this document.
Praktika

Teoorias tundub asi päris kole, aga kuidas on praktikas? Praktikas on veel koledam. Lisaks võimalikele küberkollidele kasutavad sarnaseid krüpto mahajooksmise võimalusi ka täiesti legaalsed ettevõtmised, näiteks suured mobiilifirmad. Tavaliselt tehakse seda nii, et filtreeritakse ridu kujul "250-STARTTLS". Selline rida jäetakse üldse välja või asendatakse see näiteks reaga "250-XXXXXXXA". Tulemuseks on see, et klient ei näe serveri pakutud võimalust krüptole üleminekuks ja jääb vabatekstilisele ühendusele. Eelkõige on see probleem pordil 25 olevate MTA serveritega, mitte niivõrd 587 MSA serveritega. Seega ei oota server ka autentimist ning muudatus ei tule kunagi välja. Võrguoperaator aga saab nii vabalt jälgida oma võrgus toimuvat meililiiklust.

Lisaks ISPidele tegelevad sama asjaga kohati ka terved riigid. Näiteks hiljutise Google'i e-posti turvalisuse teemalise uuringu järgi blokeeritakse Tuneesiast Gmaili serveritesse tehtavatel ühendustel tervelt 94% juhtudest STARTTLS kasutamine.

Mis on kogu jutu mõte?

Kõik algas sellest, et aastal 1997 registreeriti IANA port 465 protokollile SMTPS ehk krüpteeritud SMTP. Juba aasta pärast võeti see aga tagasi, sest vahepeal oli välja mõeldud STARTTLS, mis tollal tundus kõikide murede lahendaja – selmet registreerida kaks porti, üks vabateksti ja üks krüpteeritud ühenduse jaoks, võis registreerida vaid ühe ja teha mõlemat. Seega aastast 1998 ei ole enam sellist asja nagu SMTPS pordil 465. Sellel pordil asub täna hoopis protokoll nimega URL Rendesvous Directory for SSM. Elu teeb siiski omad korrektiivid ja suur osa SMTP serveritest, sh. ka oluliseimad nagu Gmail, toetavad endiselt (ehk siis juba 17 aastat peale ametliku toe lõppemist) krüpteeritud ühendust pordil 465. See on üks suuri vastuolusid reaalsuse ja paberil kirjas oleva vahel ja ilmselgelt on seal ka põhjus – nimelt STARTTLS on halb, kasutada tuleks krüpteerimist juba baidist nr 1. ning mitte oodata kuni mõni MITM meie ühenduse ära rikub.



Lisalugemist