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

kolmapäev, 21. oktoober 2015

Kahefaktorilisest autentimisest

Iga vähegi küberhügieenist hooliv inimene kasutab võimaluse korral alati kahefaktorilist autentimist. Lühidalt tähendab see seda, et kuhugi sisse logiv kasutaja esitab lisaks oma tavalisele paroolile (ehk esimene faktor) ka mingi muu kinnituse (teise faktori), tavaliselt siis sellise, mis eeldab ligipääsu mingile kindlale füüsilisele esemele. Esimene laiem kokkupuude kahefaktorilise autentimisega toimus Eestis juba üle 15 aasta tagasi, mil ilmusid internetipangad koos paroolikaartidega, seega siinmaal on see juba tuttav nähtus. Paroolikaart (vahet polegi, et kas ühe- või korduvkasutavate paroolidega) oligi sellisel juhul kasutaja tavaparooli kõrval selleks teiseks faktoriks.

Siinkohal teeksingi väikese ülevaate võimalikest teise faktori lahendustest ning seda keskendudes mudelile kus tavatarbija soovib brauseri kaudu sisse logida mõnele veebilehele, näiteks internetipanka või sotsiaalvõrgustiku lehele vms.

Korduvakasutatav paroolikaart

Pangad on tänuväärselt olnud kohaliku küberhügieeni edendamise veduriks ja nii taibati juba kohe alguses, kui internetipank oli veel alles väheste tehnofriikide jaoks, võtta kasutusele paroolikaart. Korduvakasutatav paroolikaart on tänaseks ilmselgelt kõikidest võimalustest kõige ebaturvalisem, kuid omal ajal oli see muidugi suur samm edasi. Korduvkasutatavat kaarti on lihtne kopeerida ja vastavad rünnakud tekkisid ka üsna pea, kus inimestele hakkas laekuma "Гanzapangast" kalastuskirju teemal, et pank on kasutaja paroolid ära unustanud ja nüüd tuleks need saadetud vormil uuesti sisestada. Esimesed Гanzapankurid kukkusid kiirelt vahele, aga pretsedent oli sellega loodud.

Ühekordsete paroolidega kaart

Ühekordsete paroolidega kaart on juba kraad kangem, aga sellevõrra ebamugavam. Kuna neid kaarte tuli tihti uuendada (mis on juba iseenesest tüütu), siis oli pabermaterjal võrreldes korduvkasutavate kaartide plastikust kiirem ka kuluma. Kuigi endiselt kopeeritav, on ajaline faktor siinkohal oluline, sest koodikaart aegub üsna pea ja seega kaotavad kopeeritud paroolid millalgi kehtivuse. Lisaks, kui tegu on kasutaja vabal valikul kasutatavate koodidega ("vali kood ja kriipsuta läbi" lähenemine), siis ei tea ründaja, et millised koodid on juba kasutatud ja seega on kergem sisestada valesid paroole ning end automaatse lukustussüsteemi taha jätta.

PIN-kalkulaator

Sajandi alguse poole hakati välja andma ka PIN-kalkulaatoreid, mis on elektrooniline seadeldis ühekordsete koodide genereerimiseks. Tavaliselt töötab selline seade nii, et sisestad seadme korpusel oleva klahvistiku kaudu 5-kohalise numbrilise PIN koodi ja aparaat näitab selle peale oma ekraanil 8-kohalist ajutist PIN koodi, mida saabki pangale sisselogimiseks esitada. Mis alusel see ajutine kood genereeritakse, ma täpselt ei tea. Seade on praktikas turvaline, kuna seda ei saa kopeerida. Kuigi suhteliselt populaarne, siis laiadesse massidesse see siiski kunagi ei jõudnud, seadeldis ei ole tasuta ja see töötab ainult selle väljastanud pangaga. See on ka natuke kohmakas, nagu oleks vaja veel üht telefoni kaasas kanda.

ID-kaart

Järgmiseks tekkis kõigile tuttav ID-kaart. Selle puhul on autentimise aluseks kliendisertifikaat. Teadaolev, aga vähe kasutatud SSL/TLS võimalus on nõuda kehtivat x509 sertifikaati mõlemalt osapoolelt. Kõige tavalisem kasutusjuht ehk see, kui avad brauseris suvalise https:// algusega veebilehe aadressi, näeb ette, et kehtiva serdi esitab ainult server. Protokoll võimaldab küsida serti ka kasutajalt ja seda ID-kaardiga sisse logimine tähendabki. Server nõuab kliendi sertifikaati, brauser üritab seda laadida ID-kaardilt ja küsib ID-kaardi lahtilukustamiseks PIN koodi. Seejärel kontrollib server, et esitatud sert oleks allkirjastatud õige CA (ehk SK) poolt ja et seda poleks tühistusnimekirjades. Kui parool ka veel klapib (reeglina ID-kaardi ja Mobiil-ID puhul eraldi parooli siiski ei küsita), siis ongi kasutaja autenditud. Tänastel kaartidel on 2048 bitised RSA võtmed, mis on praktikas täiesti turvaline ja võltsimiskindel.

Mobiil-ID

Hilisem ID-kaardi lisa ehk Mobiil-ID töötab veidi teisiti, kuna seal otseühendust mobiilis asuva SIM-kaardi ja serveri vahel tekkida ei saa. Selle asemel genereerib server allkirjastamiseks mingi ühekordse väärtuse, saadab selle Mobiil-ID süsteemi ja saab sealt vastu autentimissessiooni 4-kohalise identifikaatori (ma ei tea kuidas see genereeritakse, tõenäoliselt tuletatakse allkirjastatavatest andmetest) ning kuvab selle kasutajale. Mobiil-ID süsteem saadab päringu koos sessiooni identifikaatorigaa SMS teel kasutaja telefoni, kasutaja allkirjastab päringu ja saadab samuti SMS teel allkirjaga vastuse tagasi. Kui vastus jõuab autentivasse serverisse, siis kontrollib see, et kas allkiri vastab kasutaja sertifikaadile ja sobivuse korral ongi kasutaja autenditud. SIM kaardil peaks samuti olema 2048 bitised RSA võtmed ja seega on Mobiil-ID sama turvaline kui ID-kaartki, kuigi turvalisust vähendab (vähemalt teoorias) musta kastina kasutaja ja autentiva serveri vahelisi päringuid vahendav Mobiil-ID süsteem.

TOTP/2FA (Google Authenticator)

Mujal maailmas nn. smartcard'e, mida nii ID-kaart kui ka Mobiil-ID oma olemuselt on, tavakasutajatele eriti pakutud pole. Kõige levinum teise faktori lahendus on TOTP põhine 2FA ühekordsete koodide generaator, mis reeglina väljendub kasutaja mobiilis oleva rakendusena. Rakendus kuvab hetkel kehtivaid koode ning arvutab need iga 30 sekundi järel uuesti ringi. TOTP koodid pole muud kui HMAC-SHA1 räsid, kus nn. seemneväärtus ehk seed on HMAC salajaseks komponendiks ning hetke aeg (teisendatuna 30 sekundi täpsuseks ehk siis floor(UNIX_TIMESTAMP/30)) on sisendiks, millest tehakse HMAC räsi. Saadud 20 baidine räsi teisendatakse kindla algoritmi alusel 6-kohaliseks numbriks.

Server teab samuti salajast seemneväärtust ning arvutab ka omalt poolt kontrolliks sama räsi. Kuna eri seadmete ajad võivad veidi erineda, siis arvutab server igaks juhuks mitu võimalikku väärtust, mõned minutid ajas ette ja taha. Kui üks leitud väärtustest klapib kasutaja pakutuga, siis ongi kasutaja autenditud.

Ajapõhised koodid ei ole siinkohal ainsad võimalikud, toetatud on ka muud OTP paroolid (näiteks HOTP, millel TOTP põhineb), kuid TOTP peaks olema enam levinud. Sellist autentimist toetavad muu hulgas Facebook, Google (s.h Gmail, Youtube jmt.), Dropbox, Outlook.com, tinglikult ka Skype ning paljud muud teenused.

Google Autheticator rakendus TOTP koodide genereerimiseks.
Tähelepanelik vaatleja saab kindlasti aru, et ekraanitõmmist on modifitseeritud ja koodid ei ole ehtsad.
FIDO/U2F

Uusimaks laiemale üldsusele mõeldud teiseks faktoriks on FIDO/U2F protokolli järgivad seadmed, mis peamiselt on USB porti ühenduvad võtmekujulised vidinad. Autentimisprotseduur näeb välja nii, et kui veebisait küsib võtit, siis sisestab kasutaja võtmeseadme arvuti USB porti (see võib seal juba eelnevalt olla, ei pea iga kord uuesti sisestama ja välja võtma) ning vajutab seadmel olevale nupule. Rohkem midagi teha pole vaja, veebileht tuvastab võtme ja suhtleb sellega taustal edasi ja õnnestumise korral logitakse kasutaja automaatselt sisse, mis teeb selle tõenäoliselt kõige mugavamaks lahenduseks üldse.

Yubikey poolt toodetud Githubi brändinguga U2F võtmed, mida müüdi kampaania korras hinnaga $5 tükk

Protokoll ise on veidi laiem, aga vaatlen siin vaid kõige odavamaid (ja eeldatavasti enam levikut saavat) lahendust. Hetkel toetab selliseid võtmeid vaid Chrome, kuid Firefox on protokolli toe samuti töösse võtnud ning on ka alust loota, et Microsoft lisab U2F toe oma Edge brauserisse. U2F võtmed teeb eriliseks see, et need on täiesti anonüümsed, sama võtit saab kasutada mitme eri teenusepakkuja juures ning teenusepakkuja ei saa omakorda jälgida, et kus seda võtit veel on kasutatud. Selline tulemus saavutatakse nii, et iga teenusepakkuja jaoks genereerib seade uue ja unikaalse avaliku ja salajase võtme paari (kasutades elliptilist kurvi secp256r1). Samas odavatel USB võtmetel endal sisemälu puudub ja seega seda genereeritud võtit nagu kuhugi salvestada pole. Protokoll lahendab probleemi nii, et seade krüpteerib salajase võtme ning edastab siis nii avaliku kui ka krüpteeritud salajase võtme seadme registreerimisel teenusepakkujale. Seade ise peab sellisel juhul teadma ainult krüpteerimiseks kasutatud salajast parooli.

Dropbox teenuses U2F võtme seadistamine
Pildil on Dropboxi vaade U2F võtme seadistamiseks. Kui nüüd sisestada arvutisse U2F toega USB võti ja vajutada võtmel olevale nupule, genereeriks seade võtmepaari ja saadaks need brauserile. See ongi lühidalt kogu registreerimisprotseduur.

Kui aga tahame registreeritud võtmega autentida, siis saadab server brauseri kaudu USB võtmesse registreerimisel saadud kasutaja salajase võtme ja allkirjastamiseks minevad andmed. Seade dekrüpteerib salajase võtme endale teada oleva parooliga, kasutab seejärel saadud salajast võtit andmete allkirjastamiseks ja saadab allkirjastatud andmed brauserile tagasi. Edasi kontrollib server USB seadmest saadud allkirjastatud andmeid registreerimisel saadud avaliku võtme vastu ja kui need klapivad, siis ongi kasutaja autenditud.

Google'sse sisselogimine U2F võtmega peale kasutajanime ja parooli edukat sisestamist

U2F võtmete suurim pluss on brauseritootjate tugi. Protokoll on välja töötatud koostöös Googlega, selle tugi on Chrome brauserisse sisse ehitatud (ei vaja eraldi pluginat nagu näiteks ID-kaart) ja teistesse saab tulevikus. Seega tegu on brauseritootjate jaoks "esimese kategooria kodanikuga" ja pole vaja karta, et brauseri või operatsioonisüsteemi uuendamise korral kõik jälle katki läheks. U2F põhist sisselogimist toetavad juba kõik Google teenused (Gmail, Youtube, Analytics, Adsense, Adwords jne.), Dropbox, Box, Github jpt. Mitmed teenused (näiteks LastPass) on äraootaval seisukohal, et kuni ka teised brauseri peale Chrome U2F toe endale lisavad, seega võib eeldada, et tulevikus vastavate teenuste arv kasvab jõudsalt. Eriti arvestades, et selle tuge on väga lihtne lisada, sest vajalik API on brauserisse sisse ehitatud ja selle kasutamiseks pole vaja midagi täiendavat installida.

U2F vs ID-kaart

Kui võrrelda U2F seadmeid ID-kaardiga, siis on U2F seadme eelis muu hulgas hinnas (teostatavad toimingud on palju lihtsamad ja RSA asemel kasutatakse vähem nõudlikku elliptiliste kurvide krüptot, siis selle võrra võib seade olla väiksema jõudlusega). U2F ei vaja ka keskset autentsuse tagajat, nagu ID-kaardi puhul on selleks Sertifiseerimiskeskus (see on samas nii pluss kui ka miinus, kuna keskse autoriteedi puudumisel ei saa neid võtmeid keegi kehtetuks tunnistada). Konkreetse U2F võtme autentsuse tagab kasutaja ise, kui võtme süsteemi lisab. Mõlemal juhul on põhisaladus (ID-kaardi puhul salajane võti ning U2F seadme puhul siis võtmete krüpteerimise parool) seadme kiibil ning ei välju sealt kunagi. U2F suurimaks plussiks on aga kindlasti suurte teenusepakkujate nagu Google poolne tugi, mida ID-kaart endale kunagi ei saa.

Ühesõnaga, keskse autoriteedi puudumise tõttu ei saa U2F võtit kasutada otseselt ID-kaardi kui elektroonilise dokumendi asemel, küll aga saab seda kasutada kindla konto autentimiseks, kus teenusepakkuja juba teab, et kes parasjagu sisse logib, kuid soovib täiendavat kinnitust. U2F võti pakub sama kategooria turvalisust, aga veidi väiksema hinna eest (ID-kaardi hind algab 25€, Yubikey U2F võtme "tavahind" on $18), suhteliselt anonüümselt (iga teenuse jaoks genereerib seade uue võtmepaari ning võtmeid ei taaskasutata eri teenuste vahel), ja garanteeritud töökindlusega (erinevalt siis ID-kaardi lahendustest, kus asjad "vahel töötavad, vahel mitte"). U2F seadme puhul pole vaja ka eraldi kaardilugejat, kuna seade ise käib USB pessa. U2F tuge on teenusepakkujatel kergem lisada, see ei vaja mingeid müstilisi spetsifikatsioone ja pluginaid. Gmaili kontole ei saa tõenäoliselt kunagi ID-kaardiga sisse logida, aga U2F võtmega saab seda juba täna.

---- järgneb täiendus algsele loole ----

SMS-2FA

Mul endal läks küll täiesti meelest ära, aga õnneks juhtis Facebookis Peeter Marvet tähelepanu veel ühele laialt levinud teisele faktorile ehk siis SMS põhisele koodide saatmisele. Sellisel juhul saadab teenus SMS teel kasutaja telefoni ühekordse koodi, mida saab hetkel pooleli oleva autentimise lõpetamiseks kasutada. Suureks boonuseks on see, et nii saab kohe teada, kui keegi on suutnud kasutaja parooli ära varastada ja proovib seda kuskil kasutada (SMS saadetakse reeglina pärast parooli edukat sisestamist, seega parool peab ründajal juba teada olema). Miinuseks aga kerge privaatsuse riive, kuna telefoninumbrit on võimalik kasutada profileerimiseks ning erinevate teenuste kontode kokkuühendamiseks ja tegevuse jälgimiseks (kasutajanimi võib ju teenusest teenusesse muutuda, aga mobiilinumber jääb samaks). Samas kui teenus juba niikuinii mingil muul põhjusel kasutaja telefonimbrit vajab ja täiendavat privaatsuse riivet ei teki, siis muidugi on tegu üsna hea lahendusega kuna SIM on praktiliselt kopeerimiskindel ning samuti ei pea telefon olema "nutikas," kõlbab iga vana Nokia või Ericsson. SMS-põhine autentimine on "tavainimesele" reeglina kõige arusaadavam, kuna see ei nõua lisatarkvara ega seadmeid.

Miinuspoolelt veel probleemid mobiili leviga (näiteks lõpetab piirkonna ainus mast töö või siis on hoopis ülekoormus) ja roaming võimaluse olemasoluga välismaal (mõlemad kehtivad ka Mobiil-ID kohta). Samuti võivad SMS transpordi torud olla "umbes" kuna tavaliselt on saatjaks mõni USA teenus ja sõnum peab läbima pika maa, enne kui mõnda Eesti telefoni potsatab.

Näiteks hiljuti külastasin üht rahvusvaheliste majandussanktsioonidega piiratud territooriumi ning seal rahvusvaheline roaming ei töötanud, telefoni tuli hoopis panna kohalik SIM kaart, mis muutis ühe hetkega kasutuks nii Mobiil-ID kui ka SMS-2FA.



Kasutatud lühendid
  • SSL/TLS – SSL (Secure Sockets Layer) on vanem ja TLS (Transport Layer Security) uuem krüptograafiline protokoll võrgusuhtluse turvamiseks. Wikipedia
  • x509 – Rahvusvahelise Telekommunikatsiooni Liidu (ITU) standard avaliku võtme infrastruktuurile digisertifikaatide jaoks. Wikipedia
  • CA – (Certification authority) on organisatsioon, mis annab välja ja kinnitab digisertifikaate. Wikipedia
  • SK – AS Sertifitseerimiskeskus, meie enda kohalik CA
  • RSA – (Rivest-Shamir-Adleman) on avaliku võtmesüsteemiga krüpteerimise algoritm andmeedastuses. Wikipedia
  • 2FA – on kahefaktoriline autentimine. Wikipedia
  • OTP – (One-time password) ühekordseks kasutamiseks mõeldud parool, mis sõltuvalt implementatsioonist kaotab kehtivuse parooli kasutamisel või kindla aja möödudes või järgmise ühekordse parooli genereerimisel. Wikipedia
  • TOTP – (Time-based One-time Password Algorithm) on algoritm ajapõhise parooli leidmiseks, mille komponentideks on salajane seemnevõti ning hetke aeg. Wikipedia
  • HMAC – (Hash-based message authentication code) on konstruktsioon krüptograafilise räsi leidmiseks, mille komponendiks peale räsitavate andmete on salajane parool.  Wikipedia
  • SHA-1 – (Secure Hash Algorithm 1) on krüptograafiline räsifunktsioon, mis genereerib räsitavatest andmetest 20 baidise räsi. Wikipedia
  • HMAC-SHA1 – on HMAC konstruktsioon, mis kasutab räsifunktsioonina SHA-1 funktsiooni.
  • FIDO Alliance – (Fast IDentity Online) on konsortsium turvaliste online autentimismeetodite väljatöötamiseks. Koduleht
  • U2F – (Universal 2nd Factor) on avatud standard 2FA täiustamiseks, kasutades USB ja NFC põhiseid seadmeid. Wikipedia

teisipäev, 13. oktoober 2015

Bugi OSX Mail App rakenduses

Tundub, et OSX Mail App lendab õhku kui IMAP server saadab EXPUNGE teate juhul kui postkastis pole mailirakenduse arvates ühtegi kirja. Ilmselgelt on tegu sünkroniseerimisveaga, aga kas see just tähendab, et peaks exceptionit visates õhku lendama, pole päris selge. Pigem peaks käituma nagu alati juhul kui tekib sünkroniseerimisprobleem, nimelt avatud mailbox sulgeda, see seejärel uuesti avada ja vaadata, et mis seal siis nüüd on.

teisipäev, 6. oktoober 2015

Probleemid QQ webmailiga

QQMail on üks suurimaid Hiina e-maili pakkujaid. Ei julge täpset kasutajanumbrit pakkuda, aga mõnisada miljonit kasutajat võiks sellel ikka olla (kokku on QQ kasutajaid miljardi ringis, aga kõik ei ole neist e-maili kasutajad, QQ toodete portfell on päris suur). Igatahes on see üks maailma suurtest Gmaili, Hotmaili ja Yahoo kõrval ja seega tuleb e-maili tarkvara luues ka QQ'ga arvestada.

Huvitaval kombel ongi QQ webmailil üks spetsiifiline probleem ja seda nimelt manuste unikood failinimedega. Aarvestades et Hiinas on unikood au sees ja ASCII mitte, siis on see tõesti imelik.

Kui standardi järgi asub failinimi Content-Disposition päisekirje filename argumendina, siis paljud e-posti rakendused (etteruttavalt, ka QQ webmail) kasutavad mittestandardset name argumenti Content-Type päises. Mitte-ASCII sümbolite kasutamiseks failinimes tuleb see kodeerida ja korrektseks kodeeringuks on RFC2231 Parameter Value Continuation, mis võimaldab jaotada pikemaid failinimesid väiksemateks osadeks (et mitte rikkuda rea pikkuse piirangut) ning nendes olevad mitte-ASCII sümbolid kodeerida urlencoding-laadses kodeeringus.

Failinime "😁😂.jpg" kodeerimine käiks sellisel juhul nii:
Content-Disposition: attachment;
    filename*0*=utf-8''%F0%9F%98%81%F0%9F%98%82.jpg

RFC2047 kirjeldab veidi vanema kodeeringu mehhanismi, encoded-word kodeeringu mis võimaldab koderida päiseridade väärtusi.

Kirja pealkiri "Spämm 😁😂" võiks välja näha nii:
Subject: =?UTF-8?Q?Sp=C3=A4mm_=F0=9F=98=80?=

Encoded-word nagu ka continuation on atom tüüpi väärtused, mis tähendab, et neid ei saa, vähemalt standardi järgi, kasutada päisekirjete argumentide puhul jutumärkide vahel. Mittestandardselt saab muidugi küll ja seda QQ teebki.

Ühesõnaga, selle asemel et kasutada korrektset continuation kodeeringut, kasutab QQ failinimede puhul encoded-word väärtusi jutumärkide vahel. Veel huvitavam, lisaks sellele, et QQ ei genereeri väljuvaid kirju standardi järgi, ei oska QQ ka sissetulevaid kirju õigesi käsitleda.

Näiteks kui manuse päises on failinimi defineeritud vastavalt standardile:
Content-Disposition: attachment;
    filename*0*=utf-8''%F0%9F%98%81%F0%9F%98%82.jpg

Siis QQ webmailis seda kirja vaadates, kuvatakse manuse linki nii:


Seega tuleb kirjadele lisada failinimi kaks korda. Ühe korra standardi järgi filename argumendina ja ühe korra mittestandardse name argumendina:
Content-Disposition: attachment;
    filename*0*=utf-8''%F0%9F%98%81%F0%9F%98%82.jpg
Content-Type: image/jpeg;
    name="=?UTF-8?Q?=F0=9F=98=81=F0=9F=98=82=2Ejpg?="

Ja nüüd saab ka QQ kõigest aru:

reede, 2. oktoober 2015

Mis on see salapärane moodulus?

Septembris kerkis üles viga ID kaardi sertifikaade genereerimisel, kus väidetavalt olevat mingisugune moodulus negatiivne, aga teadjamad räägivad, et see ei saa seda kuidagi olla ja seega on viga kõigest formaalne. Hea ülevaate probleemist leiab näiteks RIA blogist. Ei hakkakski siin probleemi olemust üle kirjeldama, keskenduks pigem tollele müstilisele moodulusele, et mis asi see üldse on ja miks see negatiivne olla ei saa. Järgnev jutt ei ole krütpograafiline ega matemaatiline teadustekst, vaid for dummies from a dummie, nii et kannatage ära ja jätke parandused kommentaaridesse.

Kõige lihtsamalt võttes on moodulus, nagu nimigi viitab, jäägiga jagamistehte jagaja. Modernse krüptograafia aluseks on hiigelpikad algaarvud, näiteks 2048 bitiga esitatud täisarvul on veidi üle 600 nulli ning selline moodulus ehk jagaja määrab sisuliselt ära numbriskaala, millel toimetame. Võrdluseks autode puhul võiks mooduluseks olla see number, mis on spidomeetril kõige suurem, näiteks 160 km/h. Auto mootor saab tekitada liikumiskiirust vahemikus 0 kuni 160, aga mitte vähem ega rohkem. Jah, osad detailid protsessi käigus võivad liikuda küll kiiremini – näiteks punkt auto ratta välisküljel võib vastavalt asukohale liikuda autost kiiremini, aeglasemalt või olla üldse paigal, aga auto liikumiskiirus jääb siiski sinna määratud vahemikku. Sama on ka krüptoarvutustega.

Et juttu veidi ilmestada, siis koostame siinkohal lihtsa jagatud võtmega ROT põhise krüptolahenduse, kuid fikseeritud saladuse (tavaliselt 13) asemel arvutame jagatud saladuse osapoolte salajasest ja avalikust võtmest Diffie-Hellman võtmevahetuse abil. Sellisel juhul saavad kasutatud võtit teada ainult mõlemad osapooled, aga mitte seda sõnumit pealt kuulavad kolmandad isikud.

Meil on kaks osapoolt, vanad tuttavad Alice ja Bob, kes lepivad kokku, et nende kasutatud võtmevahetuse avalikeks konstantideks on eelpool mainitud moodulus, milleks valitakse 23 (seega prime p=23) ja generaatoriks valitakse 5 (ehk g=5), mis määravadki kasutatava numbriskaala. Järgmiseks valib Alice endale meelepärase salajase võtme, milleks saab algarv 7 (ehk a=7, pange tähele, et see jääb g ja p vahele) ning Bob valib endale salajaseks võtmeks algarvu 11 (ehk b=11).

Salajast võtit loomulikult kellelegi edastada ei tohi ja seetõttu peavad Alice ja Bob tuletama oma salajasest võtmest ka avaliku võtme. Selle leiame tehtega

A←ga mod p

Kus A on Alice avalik võti, g on generaator 5, a on salajane võti 7 ning p on 23.

Alice avalik võti = 57 % 23 = 78125 % 23 = 17

Sama teeme ka Bobi võtmega:

Bobi avalik võti = 511 % 23 =  48828125 % 23 = 22

Seega on Alice salajaseks võtmeks 7 ning avalikuks võtmeks 17, viimase väärtuse edastab ta ka Bobile. Bobi salajaseks võtmeks on omakorda 11 ning avalikuks 22, mille ta edastab Alicele.

Järgmiseks tuleks tuletada nendest väärtusest ühisosa ehk jagatud võti. Selle leiame oma salajasest võtmest ja vastaspoole avalikust võtmest tehtega

S←Ba mod p

Kus B on Bobi avalik võti 22, a on Alice salajane võti 7 ning p on 23.

Jagatud võti Alice jaoks = 227 % 23 = 2494357888 % 23 = 22

Ning sama tehe Bobi jaoks

Jagatud võti Bobi jaoks = 1711 % 23 = 34271896307633 % 23 = 22

Nüüd teavad nii Bob kui Alice, et salajase info omavahel vahetamiseks tuleb kasutada ROT22 algoritmi. Kuna me ei ela enam Rooma impeeriumis, vaid vahepeal on paar tuhat aastat edasi läinud, siis kasutame 26 kohalise tähetabeli asemel tervelt 256 kohalist (ehk siis toimetame 1 baidi raames).

Alice tahab saata Bobile sõnumit "saladus" (baitidena 73:61:6c:61:64:75:73). Sõnumi krüpteerimiseks kodeerib ta selle jagatud saladusega, liigutades kõiki baite 22 võrra suuremaks ja saab väärtuse 89:77:82:77:7a:8b:89. Bob omakorda saanud sellise sõnumi, kerib jagatud võtme võrra baidid madalamaks ja saabki sõnumi sisu lugeda. Profit!

Kokkuvõtteks

Kui vastata esialgsele küsimusele, siis moodulus ei saa tõesti olla negatiivne ja seda seetõttu, et skaala millel toimetame (ning moodulus määrabki skaala ülemise otsa) on alati positiivne. Täiendavalt võis tähele panna, et juba niivõrd lihtsa lahenduskäigu korral läksid tehetes kasutatud väärtused juba päris suureks (näiteks jagatud saladuse leidmisel korraks läbi käinud väärtus 34 271 896 307 633), mis siis veel "päris" krüptost rääkida.



Täiendus

Kuna Facebookis küsiti, et mis bitt see ikkagi täpselt siis mooduluse negatiivseks muudab, siis kopipeistin siia arhiveerimise mõttes ka oma vastuse:
Küsimus on ASN.1 INTEGER väärtuse korrektses koostamises, see on siis see numbritüüp mida kasutatakse avaliku võtme mooduluse salvestamiseks sertifikaadis. Konkreetselt on sellel numbrivormingul selline tingimus, et esimene bitt näitab märki: kui see on 0, siis on tegu positiivse arvuga, kui aga 1, siis negatiivne. Kui number on piisavalt väike, siis jääb selle biti jaoks kenasti ruumi, aga suurte numbrite korral lähevad kõik bitid kasutusse ja seega tuleks tekitada juurde veel üks täidisbait, mis koosneb ainult nullidest (ei muuda numbri väärtust, küll aga tekitab vajaliku esimese nullbiti). Mis on nende sertifikaatide juures valesti, ongi see, et too täidisena mõeldud nullbait on numbriväärtuse eest puudu, aga numbriväärtus ise on niivõrd suur, et kasutab esimese biti ise ära. OpenSSL aga seda märki üldse ei vaata, sest kuna see ei saa olla muud kui positiivne, siis nullbaiti (kui see on olemas) lihtsalt ignoreeritakse.

Näide minu enda sertidega. Vana serdi puhul on mooduluse esimene väärtusbait 0xB9, mis bittidena väljendub 10111001. Nagu näha, on vasakpoolne bitt täidetud ja selleks, et seda numbrit mitte negatiivseks pöörata, on moodulus esitatud mitte B9:…, vaid 00:B9:… seega kõik klapib. Uue serdi puhul on esimene numbribait 0x97 ehk 10010111 (samuti on esimene bitt täidetud), kuid moodulus ei ole mitte 00:97:…, vaid 97:…. OpenSSL teisendab selle oma kõhuks ikkagi õigeks numbriks, õigemini ta lihtsalt ei arvesta esimese biti kui eriterminiga, aga vähem andestavad implementatsioonid, mis käsitlevad numbri kodeeringut korrektselt, loevad selle asemel välja ühe vigase negatiivse numbri (kuna esimene bitt läheb märgina kasutusse, siis muutub lisaks märgile ka terve number valeks)

Ja jätkuvalt – minu arvamus ei ole mitte kuidagi teaduslik ning selles võib esineda vigu kuna kõik vastavad teadmised olen saanud guugeldades ja oma loogikaga tuletades. Võrdluseks, täpselt samade uurimismeetoditega on teised inimesed jõudnud torusiili lastele sisse jootmiseni, nii et beware. Kui tead paremini või leiad jutus vea, siis anna sellest teada.

neljapäev, 1. oktoober 2015

Koodi deployment veebiserverisse

Vanadel headel aegadel oli koodi saatmine serverisse väga lihtne ning selleks võlusõnaks oli FTP. Näiteks töötasin umbes 10 aastat tagasi ühes veebiagentuuris, kus tegime PHP põhiseid veebilehti. Deployment nägi seal välja ülilihtne, nimelt kasutasime koodi kirjutamiseks Zend Editori, millel oli sisse ehitatud FTP tugi. Kui tahtsime midagi (live's) muuta, siis avasimegi editori, klikkisime ikoonil Open ja valisime FTP serveris asuva faili. Peale muudatuse tegemist klikkisime ikoonil Save, editor salvestas faili otse üle FTP serverisse ja oligi muudatus deploy'tud. Seejärel tuli brauseriaknas vajutada klahvile F5 ning muudatus saigi nähtavaks, mis saaks olla veel mugavam?

Paraku olid sellisel lähenemisel omad probleemid. Esiteks muidugi ei olnud ju selline uuendus kuidagi versioonitud. Kuna tegu oli lihtsalt faili üle kirjutamisega, siis muudatus kuskile kirja ei läinud ja seega ei olnud võimalik ka kergelt muudatust tagasi keerata. Kodukootud varunduslahenduseks oli lihtsalt aegajalt kõik serveris olevad failid FTP kaudu korraga alla laadida ja zip faili salvestada. Kui nüüd oli vaja mingeid muudatusi tagasi võtta, siis tuli vastav zip fail üles leida (eeldusel, et olid viitsinud/taibanud selle varukoopia üldse teha), lahti pakkida ja õige fail üles leida. Halval juhul tuli pöörduda hostingupakkuja poole ja neilt viimast backup'i lunida.

Aegajalt tuli ette ka race condition'it, juhul kui mitu arendajat sama faili kallal toimetasid ja siis üksteise muudatusi oma muudatustega üle salvestasid. Seda juhtus samas väga harva, kuna reeglina oli üks arendaja projekti kohta.

Minu totaalne lemmik oli salvestamine võrguprobleemide korral. Mida see üldse tähendab, et editor salvestab mingi faili FTP'sse? See tähendab, et kõigepealt avatakse FTP kaudu serveris fail kirjutamiseks ja seda nii, et faili pikkus lühendatakse 0 baidini ja seejärel siis kirjutatakse sellesse avatud faili selle faili uuenenud sisu. Mingist transaktsioonilisest faili kirjutamisest võis sellisel puhul vaid unistada. Praktikas juhtus tihti nii, et editor avas faili (ehk lühendas selle 0 baidini) kuid siis tekkis võrguprobleem ja Zend Editor viskas selle peale pikema jututa pildi taskusse. Tulemus? Serveris oli nüüd vana faili asemel 0 baidine fail ning lokaalses masinas polnud ka enam faili sisu saadaval, kuna editor oli kokku jooksnud.

Sarnane probleem tekkis tihti ka mahu ületamise tõttu. Veebihostingu paketid olid suhteliselt väikesed ja ikka juhtus, et klient oli laadinud sinna mingeid hiigelsuuri pilte ja pdf faile jne. nii et kettamaht oli täis saanud ja isegi üle läinud, sest FTP lubab viimase faili kettale kirjutada, isegi kui sellega läheb quota lõhki. Kui nüüd üritada nüüd sellises keskkonnas mingit faili muuta, siis faili avamine õnnestub (ehk siis lühendamine 0 baidiseks), aga sinna faili midagi kirjutada enam ei õnnestu, kuna quota on juba varasemalt lõhki. Kui selleks muudetavaks failiks juhtus olema index.php või siis rakenduse konfiguratsioonifail, siis oli tulemus teada – veebileht oli jälle "maas".

Tänapäeval on asjad tunduvalt muutunud, ainult poolearuline kasutab rakenduse üleslaadimiseks serverisse FTP'd ja seda kasvõi juba turvalisuse tõttu (ka FTPS ei pruugi olla turvaline, kuna vaikimisi on krüpteeeritud ainult command channel ehk see, kustkaudu liiguvad paroolid, aga mitte data channel, kustkaudu liiguvad failid). Võimalusi on nüüd igasuguseid, tutvustaksin lähemalt poor-man herokut ehk git'i kaudu deploy'mist.

Eeldused:
  • Meie rakendus (selles näites tavaline PHP baasil toimiv veebileht) kasutab versioonihalduseks git'i
  • Olemas on ssh ligipääs serverisse (sama kasutajana, kelle õigustes peavad olema rakenduse failid)

Samm 1. Seadista remote repository

Loo serveris repo kaust (sõltuvalt asukohast võib olla vajalik teha seda root kasutaja õigustes), suvaline asukoht kõlbab, aga näites teeme selle asukohta /var/opt

cd /var/opt
mkdir webapp.git
cd webapp.git
git init --bare

Selle tagajärjena on meil olemas täiesti tühi git repo asukohas /var/opt/webapp.git.

Samm 2. Update hook

Selle jaoks, et taolisesse tühja reposse millegi saatmine ka midagi reaalselt muudaks, seadistame update sündmuse tegevuse, milleks on bash skript asukohas hooks/update.

cd /var/opt/webapp.git/hooks
nano update

Avanenud tekstitoimetisse võib kopeerida järgmise failisisu (eeldusel, et /var/www/webapp/htdocs on kaust, kus hakkavad asuma rakenduse failid)

#!/bin/bash
GIT_WORK_TREE=/var/www/webapp/htdocs git checkout "$3" -f

Järgmiseks tuleks anda sellele failile käivitusõigused

chmod +x update

Nüüd tuleks jälgida, et rakenduse failide kaust eksisteerib ja et kõik failiõigused on paigas

mkdir -p /var/www/webapp/htdocs
chown www-data:www-data /var/www/webapp
chown -R www-data:www-data /var/www/webapp/
chown www-data:www-data /var/opt/webapp.git
chown -R www-data:www-data /var/opt/webapp.git/

Ja sellega ongi server seadistatud.

Samm 3. Lokaalne seadistus

Kohalikus git koodirepos, kus asuvad siis rakenduse failid, tuleks lisada uus git remote asukoht, tavaliselt on selle nimeks origin, kuid deploy jaoks kasutame hoopis nimetust production.

git remote add production www-data@example.com:/var/opt/webapp.git

www-data on siis see kasutaja kelle õiguses serveris toimetame ning example.com on ssh serveri hostname.

NB! Tavaline "origin" remote asukoht jääb endiselt alles kuna git hajuslahendus, nii jääb origin suunama koodihoidlasse ja production veebiserverisse. Lisaks võib teha veel staging vmt.

Samm 4. Deploy!

Nüüd ongi kõik seadistused tehtud ja edasi ei ole muud, kui muudatusi deploy'ma hakata. Iga kord kui oled uuendanud koodi ja selle ära commit'inud, võid jooksutada käsu

git push production master

kus master on siis aktiivne branch. Git laeb muudatused remote reposse, seal käivitub update hook, mis omakorda (eeldusel et commit õnnestub), kopeerib kõik vajalikud failid veebifailide kausta.

Profit!