Category Archives: Uncategorized

pgconf.eu 2016

pgconf  2016.11.04 16:15:14

Since this year’s European PostgreSQL conference pgconf.eu happened to take place in my home country I just couldn’t pass the opportunity to go.
I’m not really a huge PostgreSQL user though — I mostly use it for personal projects, but have also done at least one rather unconventional proof-of-concept project on it at work (a largeish graph DB).

At work the main production databases that I’m currently responsible for (or have been in the past) are all based on MySQL/MariaDB, but this is mainly because these decisions were made 10+ years ago when the pros and cons of each choices were quite different than they are today. It’s rather likely that for all the new projects I would rather use PostgreSQL.

I won’t go over the talks one by one but rather share some general themes that I noticed.

Zeitgeist

There’s a German word Zeitgeist which loosely means the spirit of the time. I have begun to notice that at conferences there’s often some unifying subtopic of the project that is somewhat unproportionally important to the particular community at that time for some reason. For example at Europython 2010 the zeitgeist was all about concurrency and ways to get around the GIL. At Europython 2015 I barely heard anything about concurrency anymore, even though things at that front haven’t changed much in between — instead everyone was focused on data mining and scientific computing. So anyway I feel that at pgconf 2016 the central topic was replication. There were many talks exploring different approaches to replication and various master-slave switchover orchestration tools. It will be interesting to see what solution the community will settle on in the next couple of years.

Popularity

PostgreSQL has been gaining a lot of popularity over the recent years, probably mainly because of the uncertainty related to MySQL after Oracle bought it. This also means that many commercial companies see opportunities in selling support/consultancy around postgres related things. In general for-profit companies tend to be interested in having something to differentiate themselves from the competition so they are somewhat inherently motivated to create custom extensions and solutions instead of working together. It certainly felt at the times that each company at the conference had a different solution for handling replication and cluster orchestration each with its own up- and downsides. Let’s just hope it doesn’t end with a full scale Unix wars scenario. PostgreSQL has always had a rather rich landscape of forks so maybe they have already learned to handle this somehow.

Where to do the complex stuff?

There were several talks about some of the more powerful constructs and capabilities of PostgreSQL from window functions, recursive CTEs, lateral joins, upserts, aggregate filters to various nosql capabilities, custom datatypes, foreign tables, operator overloading and support for countless programming languages.

Which brings us to a rather classical dilemma: should we use various powerful tools that the DB provides and be tied down to it as a result, or use the DB as a simple datastore and do the complex stuff in the app? I see it as a continuum where on one end you only use simple queries (probably through ORM) and on the other end you have monstrosities like Oracle APEX where even the application itself is in the DB.

The keynote speaker from Adyen said that he believes that the decision to avoid procedures, triggers etc. was the best tech decision they did even though it was for completely different reasons. My experience is more or less the same – I think a good rule of thumb is to avoid non-declarative features but be rather liberal with everything else.

Case studies

For me the most interesting talks at the conference were various talks about real system setups and problems encountered along the way. There were several of these types of talks, starting with the keynote delivered by Michiel Toneman from Adyen which is a quickly growing payment processing company currently serving ~60 billion payments per year. They have been undergoing exponential growth for years which has led to some rather interesting scaling problems. Their master database is currently over 40TB and has 11 tables with a size over 1TB. Their largest table is currently around 11TB. Michiel talked about the reasoning and complexities around choosing PostgreSQL for a payment processing company, which is in a field usually dominated by high cost proprietary databases like Oracle and Sybase. It was interesting that postgres usage at Skype had been kind of a validation that probably made it a acceptable choice elsewhere.

Another interesting talk was about problems that Skype has encountered with PostgreSQL. The interesting part for me was that even though we use MySQL we still have encountered most of the same problems. That’s because many of these problems were just something that you encounter when running DB under serious load (lock queues, small degradations in IO performance having snowball effects, lagging read replicas, cleaning up bloat etc.)

if it hurts, do it more often

For the last month or so me and my partner have taken cold showers in the morning. There are seemingly endless lists of benefits of this available on the Internet so I won’t bore you with another one. For me the main goals were to boost the immune system and to really wake up, both of which it really seems to provide.

It’s also a good exercise of willpower.

We have also extended our open water swimming period. Here’s a nice picture from today of the local bog lake (Kõnnu järv).
k8nnu_j2rves_ujumas
The air was at 15 degrees C and the water probably somewhere around 7 degrees C. After going in, there was this burning cold feeling but it’s kind of enjoyable in its own strange way. After coming out the air actually feels rather warm and there’s this strange heating feeling under the skin all over the body long afterwards.

good news everyone!

The Tom of Finland exhibition in Helsinki has been extended until 13.09.2016.

In addition to many Tom’s works there’s also this Tom-inspired 3D printed drinking fountain in the lobby:
Tom of Finland inspired drinking fountain

It wasn’t usable for its intended purpose for some reason but is still one of the best real uses of 3D printing I have seen so far.

There was also this drawing of a duck by Tom from his youth. As a duck keeper I have to say Tom’s tendency to exaggerate the sizes of certain body parts is indeed clearly visible.
Tom's duck

31c3

Käisin läinud aasta lõpus 31C3’l, millest allpool toodud mõned mälestused ja mõtted.

Chaos Communication Congress (CCC) on igaastane, 4 (öö)päevane Saksamaal toimuv rahvusvaheline häkkerite kokkusaamine. Seekord toimus konverents 31 aastat ja on kasvanud väga suureks (~13k osalejat). Toimumiskohaks on Hamburgi konverentsikeskus, mis on oma olemuselt selline hiiglaslik labürint hoone. Ka kolmandal päeval avastasime veel mingi korruse, kus polnud varem käinud.
hamburg conference center 31c3

Üldiselt on konverents jagatud loogiliselt erinevateks teemadeks (Isetegemine, Tehnoloogia, Häkkimine, Teadus, Kunst, Poliitika ja ühiskond jne.)
Põhikava toimus paralleelselt neljas suuremas saalis, lisaks oli ka mitusada väiksema töötuba jms. üritust.

tetris_door_1024

Kogu ürtuse aja kestsid ka mitusada rahvakogu, mis on põhimõtteliselt sellised projekti/organisatsiooni spetsiifilised lauad, kus saab vastava teemaga tegeleda.
Näiteks sai seal tutvuda 3d printimisega, sõrmuste valmistamise, droonida, robootika, kudumismasinate, lukkude muukimise ja kõikvõimalike muude asjadega. Muuhulgas oli võimalik ka näiteks ööpäevaringselt jootmist õppida 😛

Lisaks tegutses veel ka ööpäevaringne peoala DJdega (kuhu me küll väga ei läinud sest suitsuhais mattis hinge).

31c3 sitting shadow

Konverentsi korraldavad vabatahtlikud ja kuskil 10% külastajatest aitavad ühel või teisel viisil kaasa. Ilmselt on aastatega korraldust viimse detailini lihvitud ja üldjoontes oli kõik perfektne ja saksa täpsusega tehtud. Näiteks kuni viimase hetkeni püsis kõik graafikus, wifi toimis laitmatult (tipus korraga 7800 kasutajat), kõik ettekanded olid üle maailma live streamidena kättesaadavad jne. Paar väiksemat probleemi oli — näiteks suudeti ürituse wiki teise päeva õhtuks maha tõmmata (nagu kuuldavasti ka eelnevatel aastatel) ja lõppsõna oli vastupidiselt päevakavas lubatule inglise asemel saksa keeles.

Puht tehniliselt on ka tegu üsna mastaapse ettevõtmisega, näiteks on ürituse välislink suurem kui mõnel riigil, toimisid lokaalsed DECT ja GSM võrgud, videot kanti lokaalselt üle ka DVB-Tga, oli oma kiirabi laadne värk koos laatsaretiga, mingi lastehoiu laadne värk jne. Üles oli muuhulgas pandud ka pneumaatiliste torude süsteem asjade saatmiseks mööda maja (rohkem ilmselt küll huumori huvides) ja IRC kaudu sai tellida pizzat (ilmselt seda võimalust elus rohkem ei avane ;-)).

pneumatic intercept

Konverentsil on keelatud teha pilte ilma kõigilt pildil olevatelt inimestelt nõusolekut küsimata. Kuna see on 13k inimese seas pehmeltöeldes raske siis konverentsist väga palju pildimatejali pole. Kuid midagi leiab näiteks Flickr’ist.

Kuna tegu on eeskätt häkkeritele suunatud konverentsiga, siis algasid loengud iga päev mitte varem kui 11:30 kuid
kestsid vähemalt südaööni välja. Kella 1 ajal öösel oli üldiselt maja peal palju rohkem elu ja liikumist kui 11 ajal hommikul 🙂

31c3 star trek corridor

Ürituse spetsiifikat arvestades algas õpetlik moment tegelikult juba enne konverentsile jõudmist.
Kodus sai üle pika aja tehtud korralikud varukoopiad läpparist ja telefonist.
Enne esimesel päeval hotellist lahkumist veetsin tunnikese läpparis ebaolulisi teenuseid sulgedes ja tulemüüri confides.
Telefoni hoidsin enamiku ajast lennureshiimis jne.
Üritusel läpakalt või telefonilt ekraanilukku maha võttes oli üsna kõhe tunne, kuna pidevalt oli kahtlus, et keegi raudselt seljatagant jälgib või filmib.
Tundub, et läks üldiselt õnneks ja seekord keegi minu seadmetesse sisse ei häkkinud aga oli kuulda, et kõigil nii hästi ei läinud.
Lisaks oli kuskil wikis näha ka tabelit väliste saitidega, mis on konverentsil osalejate poolt maha häkitud.

Sisust

Alljärgnev on kokkuvõte minu jaoks huvitavamatest teemadest. Nagu mainitud toimus pidevalt paralleelselt 4 ettekannet, seega ma viibisin neist maksimaalselt veerandil. Neist omakorda on allpool kirjeldatud mingi mulle olulisemana tundunud alamhulk.

Mobiilindus

Selle aasta fookuseks oli SS7 võrk, mida kasutavad mobiiloperaatorid omavaheliseks suhtluseks (roamingu teemad, SMS jms.). Antud võrgu ligipääsu omades on teades ainult telefoni numbrit võimalik muuhulgas jälitadata suvaliste telefonide asukohta üle maailma, võtta vahelt nende kõnesid jms.

Selgub, et sellist ülemaailmset jälitusteenust müüakse suisa kommerts tootena. Omal ajal (80ndad) kui see protokoll disainiti oli vähe osapooli ja suhtlus käis üle spetsiaalsete füüsiliste kanalite, seega mingit autentimist sisse ehitatud pole ja osapooled usaldavad teisi pimesi. Tänapäeval on SS7 võrgule ligipääsu saamine aina lihtsam. Esinejatel oli see igatahes kuskiltkaudu olemas ja liveis demonstreeriti näiteks kõne vaheltvõtmist.

  • SS7: Locate. Track. Manipulate See ettekanne keskendus SS7 rünnakutele
  • Mobile self-defense Siin räägiti alustuseks osaliselt sarnast SS7 teemat, mida eelmiseski ettekandes. Lõpupoole avalalikustati nende ja ka muude rünnakute (võlts tugijaam, nõrk võrgu krüpto) avastamiseks loodud Androidi rakendus SnoopSnitch. Soovitan kõigil kellel sobiva kiibistikuga root‘itud Androidi telefon seda proovida. Selle rakenduse põhjal saab paremat infot ka GSMMap, mis on selline crowd-sourced ülevaade selle kohta, kui turvalised on eri riikides mobiilvõrgud. Selle ettekande põhisõnum oligi, et operaatorid üldiselt pigem ei tee turvalisust omal algatusel paremaks ja neid peab selleks avaliku häbistamise hirmuga sundima. Et seda oleks võimalik teha ongi vaja andmeid koguda.

TR-069

Too Many Cooks – Exploiting the Internet-of-TR-069-Things TR-069 on kliendiseadmete (CPE) haldamise protokoll, läbi mille näiteks ISPid oma klientide ruutereid haldavad. Protokoll nõuab, et seade kuulaks HTTPd TCP pordil 7547 ja seal vastab sellistel väheste resurssidega seadmetel tihtipeale RomPager nimeline veebiserver. Üldjuhul on ka uusimatel hetkel müüdavatel seadmetel sellest ürgne versioon (versioon aastast 2002). Käidi välja mitmesugust päris huvitavat statistikat:

  • ~45m avalikust võrgust ligipääsetavat TR-069 klientseadet üle maailma
  • avatud portide arvult on TR-069 HTTP järel internetis teisel kohal
  • ka HTTP serveritest on kuskil 50% igasugu sardsüsteemid/IoT asjad (~35m seadet)
  • TR-069 avalikest klientidest on kuskil 50% RomPager veebisereveriga ja neist omakorda 98.04% kasutab versiooni 4.07 aastast 2002
  • osades riikides ~50% IPdest haavatavad

Demoti mitmeid lihtsaid rünnakuid selle softi versiooni vastu ja näitavad, kuidas nende Chrome pluginiga saab admin õigustes vabalt CPEsse sisse. Õpetlik on selle loo juures mitte niiväga konkreetne exploit vaid see, et sellistel embedded seadmetel üldiselt puudub igasugune variant nii firmwarei up-to-date hoidmiseks, kui tegelikult isegi HTTP serveri tarkvara tootjalt paranduste jõudmiseks kasvõi seadme tootjani (kes ei ole ahelas veel viimane lüli). Ühesõnaga on nii CPEde puhul konkreetselt, kui ka embedded/IoT teema puhul laiemalt tegu väga viljaka pinnasega ründamiseks, millest hakkame ilmselt aina enam kuulma seoses sedasorti seadmete massilise lisandumisega.

SCADA

SCADA on protsessijuhtimise süsteem, mis praktikas tähendab igasuguste tehaste ja suuremate seadmete (majade ventilatsioon, tammid jms.) juhtimist. Viimastel aastatel on toimunud mitmeid tõsiste füüsiliste ja rahaliste järelmitega küberrünnakuid selliste süsteemide vastu, näiteks Iraani uraani rikastamise tehases seadmeid rikkunud Stuxnet või Türgis gaasitoru õhkimine. Turva uurijad on hakanud antud valdkonda aina enam uurima ja kajastama ja tulemused on üsna masendavad, kuna tundub et SCADA maailmas pole küberrünnakuid kuigi tõsiselt võetud ja usutakse security by obscurity printsiipi.

  • SCADA StrangeLove: Too Smart Grid in da Cloud Ülevaatlik ettekanne erinevatest viimase aasta uutest rünnakutest uurijate grupilt, kes on SCADA ründamisele keskendunud. Näitasid muuhulgas rünnakuid erinevate päikese-, hydro-, tuuleelektrijaamade vastu, ühel või teisel viisil avaliku interneti kaudu rünnatav vähemalt 8GW võimsust. Muuhulgas näidati rünnakut ka kontrolleri softi vastu, mida kasutatakse LHCs ja gaasitorude juhtimises. Üldisest turvatasemest antud valdkonnas annab aimu, et kui nad kuulutasid välja avaliku 2 päevase ligipääsu oma laboris olevatele seadmete ründamiseks siis leiti üle 10 uue turvaaugu. Lisaks on tarkvara uuendamisega lugu sarnane nagu eelpool TR-069 puhul – jooksutatakse 10+ aastat vana teada aukudega tarkvara ja mingit selget uuendamise kanalit tegelikult polegi. Tegeletakse siis kui põleb, ilmselt sõna otseses mõttes 😛
  • Damn Vulnerable Chemical Process Rääkis virtuaalse õppekeskkonna loomisest protsesside/tehaste ründamise harjutamiseks (analoogne siis veebirakenduste maailmast Damn Vulnerable Web App‘ile). Päris huvitav tähelepanek oli, et süsteemi sisse saamise järel tegelik töö alles algab ja tuleb aru saada kuidas konkreetses tehases protsess töötab (igaüks unikaalne) ja kuidas seda kõige mõistlikum enda kontrolli all olevate kraanide ja sensoritega teha annaks. Eeldab põhjalikke valdkonna teadmisi (vähemalt kui eesmärk on mingi peenem rünnak, kui lihtsalt kõige vastu taevast laskmine).
  • Switches Get Stiches Seda ma ise vaatama ei jõudnud aga kuna kirjeldab tööstuslikke etherneti switchide vastaseid rünnakuid, mida Damn Vulnerable.. jutust viidati siis täielikuse huvides mainin ära.

Tor

  • State of the Onion Igaastane ülevaade Tor võrgu arengust. Kirjeldati viimase aasta jooksul toimunud Tori vastaste rünnakute olemust. Tundus, et parim hetkel teadaolev rünnak on liikluse korreleerimise rünnak, mis on üsna efektiivne, kuid eeldab NSA sugust ründajat kes suudab üle maailma liiklust paljudest punktidest salvestada ja suhteliselt pikaajaliselt talletada. Nenditi, et hetkel head rohtu sellise ründaja vastu pole. Paraku ei paista olevat hetkel ka paremat alternatiivi seega, kui tahad privaatsust siis palju variante rohkem polegi. Meeldejäävaim mõte oli, et kõik peaksime kõigile oma lähedastele rääkima, mis on Tor ja miks me seda kasutame ja vajame. Seda selleks, et ei saaks tekitada ülduses muljet, et see Tor on ilmselt mingite abstraktsete kurjamite tööriist vaid, et see ongi asi mida kasutab su enda poeg, vend, sõber, kolleeg jne. oma igapäevaelus.
    Lisaks räägiti Open Observatory on Network Interference projektist, mis pakub avatud lähtekoodiga tarkvara, mille abil analüüsitakse kas ja kuipalju eri riikides internetti tsenseeritakse.
  • Tor: Hidden Services and Deanonymisation Esitleti uuringut, mis üritas leida vastust küsimusele, mida sisaldavad Tori peidetud teenused. Paistis, et peamiselt lastepornot. Tekkis arutelu ühest küljest mõõtmis metoodika üle. Väidetavalt on tor võrgus tavaline et paljud lastekaitseorganisatsioonide spiderid tsüklis kammivad selliseid lehti, mis annab kallutatud pildi. Teisest küljest arutleti küsimuse üle kas annaks midagi selle vastu ette võtta või mitte (suvalise asja blokeerimise võimekuse olemasolu süsteemis võimaldab blokeerida ka misiganes muu asja mis poliitiliselt vms. põhjusel kellegile ei meeldi). Siin ka Tori poolne kommentaar sellele ettekandele.

Turvaline progemine

  • Why are computers so @#!*, and what can we do about it? Üks humoorikaimaid ja nauditaivamaid ettekandeid üritusel. Rääkis, nagu pealkirigi ütleb sellest, miks meil tarkvaraga pidevalt igasugu jamad on ja kuidas saaks teha töökindlamat tarkvara. Esineja uurimisala oli tegelikult formaalse ja testitava prose spetsifikatsiooni loomine. Väitis, et tegelikult tänaste protsessori dokude pealt polegi võimalik üheselt öelda kuidas mingi asi käituma peaks (sest kirjutatud inimkeeles, mis lihtsalt ei ole piisavalt ühetähenduslik).
  • Trustworthy secure modular operating system engineering Räägiti Mirage OSist, mis on teadusprojekt kirjutada nullist turvalisem “OS” täielikult OCamlis. OS sellepärast jutumärkides, et pigem on see teekide hulk, mida iga rakendus vastavalt vajadusele endasse impordib. Jutu üldmõte oli, et viskame kõik aastakümnetega kogunenud abstraktsioonikihid (nagu näiteks failisüsteem) minema ja alustame nullist. See jutt kõlab üldiselt sellise klassikalise uue õhukese frameworki alustamise jutuna, mis lõpetab peale kogu vajaliku funktsionaalsuse lisamist samasugusena nagu ta eelkäia. Ühtlasi peaksid kõik selle fantaasia teostumise puhul kõike OCamlis kirjutama. Mitte, et mul otseselt midagi OCamli vastu oleks, aga igasugune monokultuur ajab mind kergelt leili. Pikemalt räägiti SSL teegist mille nad selle süsteemi jaoks kirjutasid ja proof-of-concept käsurea Jabberi chati kliendist. Kui nüüd tahta sellest chati kliendist sulle saadetud faile salvestada või sellele mingit graafilist UId lisada oledki tagasi vajaduse juures terve suur ebavajalik abstraktsioonide hunnik siiski taasluua. Mingiteks väga spetsiifilisteks asjadeks võib selline lahendus samas isegi sobida.
  • Code Pointer Integrity Ettekanne rääkis kuidas C (ja põhimõtteliselt ka C++) koodi teha automaatselt ründevektoriks olevate mälukasutuse vigade kindlaks (buffer overflowd jms. klassika). Põhimõtteliselt on tehtud LLVM peale vahend, mis analüüsib koodi ja igasugu ohtlikule pointeri aritmeerikale (sellisele mis võib viia control-flow muutmiseni) lisatakse runtime kontrollid. Innovatsioon oligi siin just selles, et ainult tõesti ohtlikele kohtadele lisatakse ainult sellised kontrollid, mille tulemusena on jõudluse kahanemine üldjuhul piisavalt väike (paar protsenti), et seda võiks reaalse süsteemi peal ka tootmises kasutada. Kogu värk on avatud lähtekoodiga saadaval ja pikem jutt toimemehhanismist siin. Nad on kokku lasknud enda vahendiga turvatud FreeBSD kasutajaruumi koos 100 portsuga nii, et peaks olema täiesti reaalselt kasutatav asi, mitte selline akadeemiline veidrus. Üldiselt tundus selline C koodi automaatne töökindlamaks muutmine palju praktilisemat maailma üldist turvataset tõstev asi, kui eelpoolmainitud kõige nullist uuesti kirjutamine.

Valimised

  • Security Analysis of Estonia’s Internet Voting System Vaadeldi igasuguseid elektroonilise hääletuse süsteeme läbi aegade ja nende auke. Alles kuskil keset ettekannet jõuti tegelikult Eesti i-hääletuse süsteemi kirjeldamiseni. Põhikriitika Eesti i-hääletusele oli, et sellise süsteemi ohumudel peaks tänapäeval arvestama riikliku klassi ründajaga, kes on võimeline konstrueerima väga keerukaid ja kalleid rünnakuid. Väide oli, et Eesti ohumudel pigem ei arvesta sellist klassi ründajaga ja et käitusturvalisuses (operational security) oli mitmeid olulisi puudusi.

    Täpsemalt räägiti rünnakust kliendi rakenduse ja serverite vastu. Kirjeldatud rünnakutes ei olnud otseselt midagi uut ja oluline on aru saada, et täielikult turvaline süsteem ei ole võimalik. Seega alati kui arutletakse küsimuse üle, kas i-hääletus on turvaline, on küsimus tegelikult selles, kas nad on piisavalt turvalised. Küsimus taandub sellele, kas ründajale on kasu edukast rünnakust piisavalt suur, et katta kulud (ja ka riskid vahelejäämisel). Haldermanni väide oli, et ühe EU ja NATO liikmeks oleva riigi kontrolli alla saamine võib olla riikliku klassi ründajale piisavalt suur motivaator, et finantseerida väga kalleid ja keerukaid rünnakuid.

    Esimesena kirjeldati valimisrakenduse pahavaraga ründamise võimalust, mis on algusest peale olnud teada ja süsteemi nõrgim koht. Küsimus on pigem, kas seda annab realistlikult teha mastaabis, mis tulemust oluliselt mõjutaks ilma, et pettus seejuures ilmsiks tuleks. Riskianalüüsid paistavad järeldavat, et pigem mitte (kuid jällegi analüüs eeldab põhimõtteliselt siseriikliku rünnet).

    Rünnak serveripoole vastu tundub oluliselt huvitavam, sest kuigi vajalik rünnak on siin palju kordi keerukam ja kallim, on ka potentsiaalne kasu vastavalt suurem – eduka rünnaku puhul valimisserveri vastu võib väljundiks anda ükskõik millise tulemuse. Ühtlasi tundub ühe viimistletud konkreetse serveri vastase rünnaku avastamine ka palju vähem tõenäoline, kui mitmekümne või mitmesajatuhande kliendi arvuti puhul.

    Potentsiaalsete rünnakute kirjeldusele järgnes käitusturvalisuse probleemide loetlemine. Kõige masendavamad tundusid mulle neist:

    • mingi isikliku suvalist tarkvara täis läpaka kasutamine valimisrakenduse allkirjastamiseks
    • tulemuste liigutamine häältelugemisserverist välja isiklikul (igasugu juhuslikku kola täis) mälupulgal (peale seda kui DVD kirjutamine mingil põhjusel ebaõnnestus)

    Järgnevalt kirjeldati eesti poliitikute, ajakirjanduse ja asjaga seotud tehnoloogia ekspertide reageeringut, mis oli üsna masendavalt mustvalge. Tunda on, et osale seltskonnale mõjub igasugune i-hääletuse kriitika nagu isiklik solvang. Teine pool jällegi teeb vastavalt kõik endast oleneva veenmaks rahvast, et e-hääletus on absoluutselt ebaturvaline ja tuleks kogu täiega kaotada.

    Näiteks toodi Rõivase kommentaar, et keegi Haldermani tiimi liige on facebookis mingi linnavalitsuse töötaja sõber ja seega töötab vastasele (klassikaline ad hominem rünnak). Või siis valimiskomisjoni kommentaar, et kui oleks sellise võimekusega ründaja, siis ta ju varastaks pigem raha kui hääli (väga veider eeldus riikliku ründaja puhul). Lõpetuseks näidati veel ka Veldre vastust CERTi nimel pealkirjaga E-valimised on (liiga) turvalised, mis lisaks provotseerivale pealkirjale sisaldab ka samavõrd üle võlli sisu (sarkastilises toonis ja ad hominem rünnakutega).

    Sellised ärapaneva tooniga arrogantsena mõjuvad avaldused tekitavad kõike muud, kui usaldust süsteemi vastu.
    Tehniline vastulause peaks olema võimakult emotsioonitu ja faktiliselt täpne. Ei ole vähimatki mõtet laskuda vaidlustesse kelle mälupulka täpselt kasutati või selle üle kas Halderman ikka suudab 100% kindlalt tõestada, et pokkeri- või torrenti rakenduse ikooni taga tegelikult ka just see rakendus oli.

    Sellise ettevõtmise käitusturvalisus peab olema laitmatu. Igasse kõvalekaldesse peaks suhtuma tõsiselt ja neile järgnema avalik arutelu ja selgelt kommunikeeritud parandus järgnevaks korraks.
    Näiteks mingite isiklike läpakate kasutamise asemel eeldaks ma vähemalt Bruce Schneieri kirjeldatud skeemi, et ostetakse mitu erinevat läptopi erinevatest füüsilistest poodidest ja paigaldatakse neile puhas tarkvara ja rohkem need masinad võrku ei satu.

    Hea algus reaalse usalduse tekitamiseks oleks võtta ette Haldermani artikkel, punkthaaval läbi töötada 3.2 ja 3.3 all toodud märkused, teha vajalikud parandused ja kus vaja endale ka avalikult tuhka pähe raputada.

    Kokkuvõttes tundub kogu vastasseisu põhjus olevat küsimuses, kuhu täpselt tõmmata piisava turvalisuse joon. Halderman ütleb, et realistlik on riiklikul tasemel ründaja, meie enda riskianalüüsid paistavad piirduvat siseriikliku ründaja eeldusega. Rünnakud, mis mõnda aega tagasi tundusid kuuluvat ulmevaldkonda, on tänaseks Stuxneti ja Snowdeni paljastustega saanud reaalsuseks. Seega tundub üsna arusaamatu, miks näiteks Veldre vastulauses selliste rünnakute võimaluse üle ironiseerib (peab sama tõenäoliseks, kui päikese ootamatut kustumist või neutronpommi balti jaamas).

    Mida meie i-hääletuse riskianalüüsid siis täpsemalt ikkagi ütlevad? Ametlik valimiskomisjoni tellitud analüüs aastast 2011 loetleb päris pika rivi mitmesuguseid võimalikke rünnakuid, omistab neile hinnangulised tõenäosused (3 palli süsteemis hinnang) ja pakub mõningaid variante asjade paremaks lahendamiseks. Siit me otseselt teada ei saa, millise ründajaga arvestatakse ja tõenäosused paistavad olevat saadud lihtsalt intuitsiooni pealt.

    Viimastel aastatel on kirjutatud mitu magistritööd, mis üritavad formaalsematel alustel (ründepuudega) i-hääletuse vastastele rünnakutele tõenäosuseid leida. Üks ilus lühike ülevaade kahest sellisest magistritööst Eesti i-valimiste riskianalüüsi teemadel on siin. Seal leitakse muide, et i-hääletuse tühistusrünnak võiks täitsa tasuv ja suhteliselt odav olla ka siseründajale (aga sellistest rünnakutest Halderman ei rääkinud, seega las ta hetkel jääb).
    Ma tahaks tähelepanu pigem juhtida sellele, et selline tasuvusanalüüs ei ütle meile tegelikult midagi riikliku ründaja rünnakute tõenäosuste kohta. Seda kahel põhjusel. Esiteks eeldab mudel, et ründaja on ratsionaalselt ja majanduslikult mõtlev (poliitiliste kaalutlustega ei arvestata ja olekski üsna võimatu arvestada). Teiseks tuleb mudeli kasutamiseks sinna panna mitmesuguseid numbreid, mille määramine riikliku ründaja puhul on pea võimatu. Näiteks, kui palju oleks Venemaa valmis ohverdama, et ühte NATO ja EU liikmesriiki endale sobivat valitsust saada?
    On see miljon, 100 miljonit, miljard või 10 miljardit eurot? Ma ei ütleks, et ükski neist numbritest lähiajalugu vaadates täiesti võimatu oleks.

  • The rise and fall of Internet voting in Norway Norra krüptograaf andis ülevaate Norra i-hääletuse piloodist, mis tänaseks on maha kantud (i-hääletuse pooldajad kaotasid võimu). Norras puudub meie ID kaardiga analoogne süsteem, seega saadeti postiga mingeid paroolikaarte, mis ei kõla just väga turvalise ega elegantse lahendusena. Kogu süsteem olla liiga keerukalt tehtud (mingi 200k+ rida enterprise stiilis koodi) mille turvalisuses on end üsna raske veenda.
    Sellegipoolest oleks ka meil siit üht teist õppida. Esiteks lasid nad häältelugemise rakenduse kirjutada kahel erineval arendajal ja ka kasutasid mõlemat – vaadati, väljund oleks identne. Võimaldab püüda nii vigu kui ka lihtsalt ründaja elu oluliselt raskemaks teha. Teatud kriitilistes rakendustes on selline liiaste süsteemide kasutamine täitsa tavapärane, täitsa nõustun norrakatega, et ka riigi tuleviku otsustamine võiks sama oluline olla.

    Teine teema oli protsessi läbipaistvus, väidetavalt oli kood githubis kõigile nähtav ja auditeeritav. Eestis näiteks on kliendirakenduse kood kinnine (nagu ka mingid jupid serveripoolsest otsast).
    Ka kole avalik kood võimaldab mingi seisukoha kujundada, kinnise koodi usaldamine on paraku puhas usuküsimus. Mina isiklikult security by obscurity usku ei ole.

Krüpto / privaatsus

  • ECCHacks – A gentle introduction to elliptic-curve cryptography Lihtsate ja arusaadavate näidetega sissejuhatus elliptilistesse turvakõveratesse koos Pythoni koodinäidetega. Ilmselt kui veel mingi 3-4 korda vaatan saan päriselt ka aru 😛 Seletatakse muuhulgas, miks konkreetsete sobivate kõverate valik on nüansrikas ja miks NSA või kellegi teise poolt arusaamatutel alustel valitu võib olla väga hea ründevektor.
  • Finding the Weak Crypto Needle in a Byte Haystack Räägiti kuidas võtme taaskasutust automaatselt tuvastada. Minu jaoks põhiväärtus tegelikult esimeses pooles, mis räägib mis on võtme taaskasutus ja miks see halb on koos praktiliste näidetega.
  • Forging the USB armory Räägib USB pulka mahutatud pisikesest personaalse turva otstarbelisest arvutist. Saab kasutada asjadeks nagu bitcoini rahakott, krüpteeritud andmesalvestus, paroolihaldus, VPN, ssh gw. jne.
  • Now I sprinkle thee with crypto dust Väga intensiivne ülevaate ettekanne, kus tunni aja jooksul mitmed projektid räägivad 10-15 minutit oma projektist. Ühendavaks jooneks nende projektide vahel on soov teha internet turvalisemaks, raskemini tsensuuri poolt kontrollitavaks ja pealtkuulamiskindlamaks. Minu jaoks neist kõige meeldejäävam oli viimasena kirjeldatud Darkmail projekt, mis on katse teha otspunktkrüpteerimisega (end-to-end encryption) e-maili lahendus. Erinevalt varasematest sama eesmärgiga lahendustest (GPG) on seekord plaan teha asi, mida oleks lihtne kasutada ja oleks lõppkasutaja jaoks üsna nähtamatu.
  • UNHash – Methods for better password cracking Kirjeldas avatud lähtekoodiga rakendust inteligentseks paroolide äraarvamiseks (vastandina tavapärasele jõumeetodile). Põhimõtteliselt on erinevate lekkinud suurt paroolibaaside pealt kirjeldatud mustrite klassid, mille alusel inimesed tihtipeale paroole koostavad (stiilis <number><sõna><number>). Paljud näiliselt keerukad ja pikad konstruktsioonid (näiteks paroolifraasid) on sellise meetodiga väidetavalt palju lihtsamini murtavad, kui klassikaliste vahenditega.
  • DP5: PIR for Privacy-preserving Presence Räägiti, kuidas teha homomorfse krüpteerimisega privaatsust säilitavaid andmebaase olemasolu (presence) teenuse näitel. Selline lahendus võimaldaks luua põhimõtteliselt igasugu suhtlusvõrgustikke ja sotsiaalseid võrkke, kus teenusepakkuja ei oma mingit ülevaadet kes on kelle sõber ja kellega suhtleb. Seletatakse üsna hästi ära, kuidas homomofrne krüpto töötab ja tavainimesele kordaminevat rakendust selle peal. Fundamentaalseks probleemiks tundub olevat süsteemi skaleeruvus kasutajate arvu lisandudes süsteemi (tegelikult baasi suuruses lihtsalt küsimus). Toodi näide, et miljoni kasutajaga privaatse võrgu puhul on käigushoidmise kulu kuskil 1$ kasutaja kohta kuus.

huumor

  • Internet of Toilets Andis ülevaate erinevatest WC automatiseerimise projektidest (peamiselt DIY) asjad. Huvitav oli üsna lõpus mainitud tõsiasi, et on olemas esimesed exploidid tarkadele WC pottidele, mis võimaldavad ründajal prill lauda tõsta-langetada, veejuga lasta jne.
  • Funky File Formats Väga humoorikas ja samas tehniliselt hariv ettekanne, mis rääkis milliseid trikke on võimalik failiformaatide veidraid võimalusi kasutades teha. Näiteks alustati jpg failiga, mis ühtlasi on täiesti legaalne ja toimiv Java jar fail. Kui algne JPG fail AESiga krüpteerida saadi tulemuseks hoopis teist pilti sisaldav PNG fail, 3DESiga lahti krüpteerides on tulemuseks PDF jne. Või siis PDF fail mida eri rakendustega vaadates näeb kardinaalselt erinevat sisu ja printer prindib välja hoopis kolmanda sisu.
  • Computer Science in the DPRK Põhja korea IT ülikoolis õppejõuna töödanud ameeriklane rääkis kuidas seal riigis on lood ITga. Humoorikas moment oli siin peamiselt nende riiklik operatsioonisüsteem Red Star. Tegu on Linuxiga, mis nii välimusest kuni failisüsteemi paigutuseni on aetud nii Applei OS X sarnaseks kui võimalik.

RTK GPS base station

As I mentioned in an earlier post, Skytraq released a cheap GPS board that is able to output raw measurements. That makes it suitable for use with RTKLIB and allowed me to build my own stationary GPS base station for around 150€. This is a quarter of the cost of the previous cheapest solution I had found and only a small percentage of the price that one would pay for a commercial RTK base station.

RTK GPS basestation

RTK GPS basestation controller

and closeup of the antenna (Satmar-FME):
closeup of the GPS antenna

I will write another post describing how accurate this setup is once I have had a chance to test it better.

configuring a fake mail server for testing

When building systems that send out e-mails to the customers one has to find a way to test what the output looks like without actually sending the mail to the client.

This article describes how to set up such a fake mail server that can be used in the test environment as a drop in replacement for you actual mail gateway.
Incoming e-mails will be stored on the local inboxes based on the FROM address (the TO address is ignored).
This allows you to test multiple applications against the same test mail server assuming that the applications use different FROM address.

I will also show how to configure IMAP access to these test mailboxes.
This guide has been tested on Debian 7.

Postfix

We will use Postfix as our SMTP server and Dovecot for the IMAP support.

apt-get install postfix dovecot-imapd

In the file /etc/postfix/master.cf find a line that looks like this:

smtp      unix  -       -       -       -       -       smtp

and replace it with:

smtp      unix  -       -       -       -       -       discard

This tells Postfix to send all outgoing mail to discard instead of smtp.
discard will just happily accept whatever is sent to it and will always report successful delivery.

In order to keep a local copy of the the discarded mail for testing add the following line to the file /etc/postfix/main.cf:

sender_bcc_maps = hash:/etc/postfix/sender_bcc

This parameter tells where BCC copies of the mails should be sent based on the FROM address.

Create the /etc/postfix/sender_bcc with contents like this:

user@example.com test1@fake
@example.com fallthrough@fake

and run the command:

postmap /etc/postfix/sender_bcc

At this point the very basic setup is in place and if you restarted the postfix all the relayed e-mails would be dropped and local copies would be stored in mailboxes under /var/mail

To make testing a bit more convenient we will set up virtual mailboxes that will be stored under /var/vmail and can be accessed over IMAP using non-system accounts.

Add the following to the file /etc/postfix/main.cf:

virtual_mailbox_domains = fake
virtual_mailbox_base = /var/vmail
virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox
virtual_minimum_uid = 100
virtual_uid_maps = static:65534
virtual_gid_maps = static:8

Create the file /etc/postfix/virtual_mailbox

test1@fake test1/
fallthrough@fake test2/

Run postmap on it:

postmap /etc/postfix/virtual_mailbox

Create the mail directory:

mkdir /var/vmail
chown nobody:mail /var/vmail

Now restart Postfix.

postfix reload

At this point mail should be correctly be delivered to Maildir formated directories under /var/vmail for addresses that match entries in /etc/postfix/sender_bcc.

IMAP

Now we will configure access to these local mailboxes over IMAP using Dovecot.
We will use file based auth to keep things as simple as possible.

Create the file /etc/dovecot/conf.d/auth-plain.conf.ext with the following contents:

passdb {
  driver = passwd-file
  args = username_format=%u /etc/dovecot/passwd
}

userdb {
  driver = passwd-file
  args = username_format=%u /etc/dovecot/passwd
}

Now open /etc/dovecot/conf.d/10-auth.conf and add the following line at the end of it:

!include auth-plain.conf.ext

Create the file /etc/dovecot/passwd with contents similar to this:

test1@fake:{SSHA}ghZpew7L4psekJyC0MUoVA3Usg0SxAjm:65534:8::/var/vmail/test1::
test2@fake:{SSHA}c9yb4ibK+rpoMBR+OnoMBrNgyjD8KraL:65534:8::/var/vmail/test2::

Password hashes can be created with doveadm like this:

doveadm pw -s SSHA -p yourPassword

Edit the file /etc/dovecot/conf.d/10-mail.conf by replacing

mail_location = mbox:~/mail:INBOX=/var/mail/%u

with

mail_location = maildir:/var/vmail/%n

Finally restart Dovecot with:

/etc/init.d/dovecot restart

Safeguard

To make double sure that no test e-mails will leave this system we will also firewall outgoing SMTP and only allow connections over localhost:

iptables -A OUTPUT -p tcp -d 127.0.0.1 --dport 25 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 25 -j DROP

And to make this change permanent add it into the file /etc/network/interfaces so that it would be read in every time the interface comes up. Mine looks like this:

iface eth0 inet dhcp
        up /sbin/iptables -A OUTPUT -p tcp -d 127.0.0.1 --dport 25 -j ACCEPT
        up /sbin/iptables -A OUTPUT -p tcp --dport 25 -j DROP

quick and cheap RFID with RPi and rc522

To my great surprise it turns out you can nowadays get an RFID reader with 2 tags for somewhere between 7$ and 10$. Better yet, interfacing these to Arduino is well documented and several libraries are available for that purpose.

My friend who bought a couple of these asked me to see if I can read the tags directly from a Linux based ARM board (for example Raspberry Pi). It turned out to be rather easy as long as you aren’t interested in anything but the ID of the card. This can be done using rpi-rc522 library (NOT written by me). It sadly currently lacks any documentation or a Makefile so here are my notes on how to get it running.

First you have to connect the rc522 and RPi over the SPI interface. It will look something like this:

Raspberry pi and rc522 RFID reader

Raspberry Pi and rc522 RFID reader

Then you have to install the bcm2835 library. Assuming that you have gcc and other essential development stuff already installed you can achieve it this way:

wget http://www.airspayce.com/mikem/bcm2835/bcm2835-1.35.tar.gz
tar -zxf bcm2835-1.35.tar.gz
cd bcm2835-1.35
./configure
sudo make install

After that you can compile and run the rpi-rc522 with the following commands:

sudo apt-get install subversion
svn checkout http://rpi-rc522.googlecode.com/svn/trunk/ rpi-rc522-read-only
cd rpi-rc522-read-only/rc522
gcc config.c rfid.c rc522.c main.c -o rc522_reader -lbcm2835
sudo cp RC522.conf /etc/
./rc522_reader -d

You should see tag IDs in the output of the program as they are read. You can put these into the /etc/RC522.conf file and map each ID to a specific command to run there.

Skepticism @ Padise

I was at the Skepticism, Thou Shell of Death and Forgotten Sunrise gig in the ruins of Padise Monastery in Estonia yesterday (28.09.2013) . Considering that Skepticism seems to perform live only once every couple of years or so it was extremely surprising to see them perform so close to me.

Anyway the atmosphere of the monastery ruins is an extremely suitable place for listening to a good funeral metal band and at almost 2 hours the Skepticisms gig was longer than the previous ones I have been to. Aside from a couple of people constantly chatting, yelling and whistling in the front row there was nothing to complain about. The sound and the performance by Skepticism were just perfect.

The best that I could capture with my N900 is this:
20130928_skepticism

You can probably find much better pictures of the event from its Facebook page.

As a (lousy) guitarist I was very interested in how exactly does Skepticism achieve such a nice thick sound that sometimes sounds like they have 2 guitars playing so I took a picture of the guitarist’s rig:

20130928_skepticism_guitar_rig

The bottom row of pedals from left to right is:

  • Boss FV-50 volume pedal
  • Electro Harmonix Metal Muff (distortion)
  • Morley George Lynch Tripler Pedal (3 way output splitter)
  • Boss Metal Zone (distortion)
  • Boss Metal Core (distortion)

The single smaller pedal in the center seems to be some kind of Korg tuner since there’s nothing coming out of it. Can’t find an exact match though.

The first and the third channel of the Tripler splitter are active. Metal Muff is connected to the first channel and the two Boss distortions are connected to the third channel in series (probably not used at the same time). The second channel of the splitter is inactive and connected to the Korg tuner.

So to make the long story short the thick guitar sound seems to be achieved by using two different distortions on different amp channels in parallel.