TLS 1.3 yleiskatsaus

Reading Time: 2 minutes

Perfect forward secrecy: yleisavain poistuu

Perfect forward secrecy tarkoittaa, että web-liikenteen tietoturva saa parannuksen; tallennettu verkkoliikennekin pysyy vain ja ainoastaan kahden osapuolen välisenä, eli tiedon salausta ei pystytä murtamaan. Nykyisellä, 10 vuotta sitten ratifioidulla teknologialla (TLS 1.2 vuodelta 2008) esimerkiksi tekninen tietohallinto on voinut avata liikennettä jälkikäteen. Avausmahdollisuus tarkoittaa myös yksityisen nettikansalaisen kannalta valitettavaa mahdollisuutta tietojen väärinkäyttöön.

TLS 1.3 korjaa tämän aukon.

Ennen tätä, salatun tietoliikenteen avaamiseen oli kaksi mahdollisuutta:

  • yrityksen tekninen ylläpito saattoi käyttää hallussaan olevaa avainta tietoliikenteen avaamiseen
  • kolmas osapuoli, “hakkeri”, tietomurtaja – saattoi saada jollain tapaa avaimen käsiinsä ja tehdä tietoliikenteen avaamista

TLS 1.3 -standardissa tämä “yleisavain” poistetaan. Tämä herätti närää viime metreillä, alkuvuodesta 2018. Pankkien tekninen edunvalvontajärjestö BITS

Miksi palvelimen avain on ollut heikko lenkki TLS 1.2 ja aiemmissa?

Käytännössä monet ylläpitotahot eivät välttämättä ymmärrä kuinka kriittinen asia salainen avain(puolisko) on.

Avainta ei saisi koskaan..

  • jättää suojaamatta tiedostotasolla (ACL – access control list)
  • kopioida, koska kopiosta itsestään voidaan aina ottaa kopio

Yllä olevat kaksi heikkoa lenkkiä eivät välttämättä ole ainoat syyt, miksi palvelimen avain joutuisi vääriin käsiin.

Avaimen julkistus voi tapahtua useasta eri syystä johtuen:

  • palvelimen ylläpidon osaamattomuus
  • ylläpidon hetkellinen huolimattomuus avaimen tietoturvassa
  • tahallinen hyökkäys ulkoa käsin, jossa hyökkääjän tavoitteena on avaimen varastaminen
  • avain voi joutua hakoteille esimerkiksi palvelimen (tietokoneen) jouduttua laillisen tutkimuksen kohteeksi

Miten TLS 1.3 standardi valittiin?

Vedos 28 meni läpi maaliskuussa 2018. IETF äänestää, Working Groupit vahvistavat viime kädessä päätökset. Toteutus tapahtuu kentällä, IT-teollisuudessa. Kyseessä on siis kuitenkin RFC-dokumentti, joka ei ole lakitekstiä. RFC:t ovat Internetin alkuajoista saakka olleet “parhaita käytäntöjä”, selkeitä dokumentteja, joissa on tiivistetty keskeisten toimijoiden ymmärrys erilaisista teknologioista. Käytännössä RFC:t ovat Internetin perustavanlaatuisia standardeja, jotka mahdollistavat kyseisen teknologian toiminnan.

Tietoturva paranee hiljalleen, sitä mukaa kun maailma siirtyy käyttämään TLS 1.3 -standardia web-liikenteessä. Erityisesti suojaus lisää sellaisen datan turvaa, joka on kaapattu verkossa – matkan aikana – ja tallennettu pysyvästi odottamaan sopivaa hetkeä.

Mikä on muutoksen aikataulu?

Nykyinen TLS 1.2 tulee hiljalleen väistymään TLS 1.3 -standardin tieltä. Samoin TLS 1.2 :ää vanhemmat standardit väistyvät eli ne poistetaan käytöstä. Parhaita arvioita voi kuunnella esimerkiksi Steve Gibsonin ja Leo Laporten podcastista, Security Now episode 658: Deprecating TLS 1.0 and 1.1

Bulbs re-lit: productivity paradox

Reading Time: 5 minutes

One of the curious things of “today”, ie. the tech landscape of post-2010, seems to be productivity paradox.

Software serves actually two very different roles:

  • software as a product
  • software as a utility, a build-block for other software engineers

I’m talking of the latter use, software as a utility.

Several decades back, software was in rather esoteric and almost completely invisible role, controlling devices. Printers needed control software, in order to draw the glyphs (characters) that a computer fed to them. Mainframe computers needed specialized operating system software. So called general purpose (or, later: Personal Computers, PCs) were not yet established as an everyday consumer tools.

The software development was not considered very much of a value. Software was said to be a necessary thing, but not of business value per se. The roots of open source and “public domain” licenses goes back to the 1960s, I believe. The phemonom probably originates from exactly this reason, that not yet there was such closely-guarded proprietary projects competing each other.

Today I had a live rant about some things mentioned above. I was talking with my colleague over Slack. We have slightly different points of view perhaps. Both of us have been in the trade for a considerable time, ie we are experienced (a total of 20+ years).

I originally had a memorable glimpse of almost this same kind of discussion in 2015, when my former team boss mentioned the paradox. He’d overseen a total development force of over 1000 employees, doing a very large-scale embedded (hardware + software) project in telecom industry for a bit less than a decade. His experiences were that of slight frustration and lack of understanding how, back in traditional (and mobile) apps, the modern software stacks did not give the power boost that one would expect. So the situation was that a product included tens of thousands of lines ready code libraries, but still there were considerable obstacles in utilizing the force within.

I remember vividly his words…
“the last 30 years the productivity hasn’t actually changed a bit (in software industry)”

It really stroke me then, but later became to understand what that meant. On the surface it seems counter-intuitive: how come, if we can nowadays just “plug and play”, or import a lot of the software corpus that we’re going to use, it’s still relatively laborious to produce products?

That particular year, 2015, was in the middle of an era where front-end development, at least on the Javascript front, was going through a very rapid progress. Javascript was being made into a full-fledged, respectable language with which ever more complex projects were implemented. Before this, one could say, Javascript was but a “pretty frosting”, a decorative finish on top of web-facing software.

I investigated a bit further, and remembered also the foundations of this going as far back as 1970s. Back then, it was of course the Fred Brooks and his book “The tar pit”. The phenomenon of the tar pit is about originally quite fast progressing project that starts to magically slow down. Things become more difficult to change. This phenomenon, in my opinion, hasn’t changed much during the years.

Life cycle of a software

Skipping a lot of theory (called SDLC), we can compress things in a nutshell:

It’s really easy to protype something between 100 and 1000 lines. These small sketches of an app serve the purpose of making feasibility studies: does it feel we’re generally capable of doing the actual, larger project? Do theories play in reality, as we have come to expect? Etc.

When you go beyond a few thousand lines, you start to feel the initial resistance. Human memory plays part of this; that’s inevitable. The namespace (naming of things) becomes a bit harder, as some of the obvious ones you have already occupied – you need to watch not stepping over parts that are useful. Depending on technical choices over the software stack, your IDE (editor and tooling) may or may not be helpful in coping with a larger source code.

When you push farther, over 10000 lines, there’s often more and more of the support processes within software engineer that “just need to be done”. The progress isn’t linear. It’s also quite seldom that one person alone manages a large program, so others need to be taken to the project.

Team play: the vision, communication, grooming

Looking after quality and communicating of the purpose, schedule, and requirements takes its share. This is however quite inevitable and a healthy sign, also. Software is team play. Much more worrisome than communications issues is when there’s a lack of communications. “No news” in software projects is often a sign of something bigger coming up later – minds have parted, and the gap has grown. What easily follows this kind of situation is phrases like “Oh?! I thought.. X” and “Hey, we’re no longer actually doing… Y”. So, it’s very good idea to synchronize early, synchronize often.

However, I wasn’t so much sparked today about the technicalities of software or the productivity paradox. Much more than that what sometimes surprises me is the question of a sort of “rush” and gap between the quality of a good overview documentation about a software, and the speed with which the actual code is being written. There’s many sides to this question.

I’m a staunch advocate of good quality docs.

The mind and programming

Flow is a very powerful and enjoyable feeling. This is something that happens often in programming. As developer, we’re having all the wires and bits in our fingertips, and creating new stuff and solving business problems is easy. Leave this state for just a couple of weeks, and you feel quite a dramatic effect: coming back to the project, looking at the source code, all the names of functions, variables, and so on – it doesn’t feel somehow “the same”. The reason is that perhaps the valence, the emotional strength and meaning of those words have a bit different representational aspect in our mind, now.

First step into a subjectively novel project

Now take a completely outsider’s view: you enter into a existing project, where there’s a 100,000 lines of code. There’s probably somewhere between 100 – 1000 different files, and hundreds of function names. When you zoom in closer, you will the sub-surface structure of the code: variables, code statements, some tricks here and there. Some of the logic is invisible, most likely: things happen because of the author of code knows the actual possible states of the variables better than you do.

You versus the original author: differences

The author knows kind of mental shortcuts to the code. The author also knows the history of the code, and the interaction relations between different objects and parts.

I like to often think of the symmetry of services: Do functions have their logical counterparts? If I open, can I close? If I write, can I read? And so on. Sometimes there’s inherent beauty in the design of software – things feel very natural. The opposite of this is kludgy implementation, where you simply have to know that certain things are exceptional; the symmetry is severely broken. Some of this however is also about the flavor and style of the whole underlying stack: many frameworks are opinionated; as you spend time using a framework, you start picking the culture and “the way things are done around here”.

My advocacy to good quality docs doesn’t mean that documentation should be superbly lengthy, but it should be to the point; understandable, and cover the immediate burning questions that a complete newbie would have when entering a new project.

I wrote, poignantly, in a chat: “If there’s 4 things that are mentioned in the docs of open source project, the order seems to be…” (part 2 coming up)

Errata: edit on 19.4.18 7th paragraph, word added
.."a product included tens of thousands of lines ready code libraries.."

Railsin rakenne

Reading Time: 2 minutes

Rails on mukava, koska

  • saat paljon Railsista valmista rakennetta sovellukselle
  • tyyli ja laatu on kohdillaan Railsin valmiissa palasissa
  • Ruby-yhteisö on tunnettu avuliaisuudestaan – ja erittäin selkeästä englannista
  • Rails (ja Ruby-kieli) on taistelutestattu ja ollut olemassa oikeasti pitkään
  • Rails uudistuu jatkuvasti, mutta tahti ei ole niin älytön että stressaisi

No niin… Ruby alta pois ensin!

Viihdyn uutta oppiessa. Toki kokemuksia on erilaisia. Aiemmat pidemmät / laajemmat suhteet ovat olleet:

  • BASIC
  • C
  • Java
  • PHP
  • JavaScript
  • TypeScript
  • React Native

ja toki liuta muuta, kotitarpeisiin.

Raiteille! Rails soikoon

Rails on Rubyn päälle rakennettu “systeemi”. Ruby on siis varsinainen ohjelmointikieli siellä taustalla. Rubyyn kielenä voi tutustua vaikka erinomaisen Wikipedian kautta. Ja oppimiseen löytyy reippaasti resursseja. Ruby on kielenä mielestäni “varsin jees”.

Viimeisen ~8 vuoden ajan en ole koskenut Windowsiin, ja sitä kautta mm. sh- skriptat tulleet paljon tutummiksi. Rubyssa kielenä on jotain erityisen kivaa, syntaksi on aika selkeä, ja silti sallii pieniä hemmotteluja; shorthandeja. Jos on tottunut tosi säännölliseen kieleen, esimerkisk

Erikoisuutena on aika siisti ja sallivakin syntaksi. Kun olen kirjoitellut kohtuu paljon erilaisia bash-skriptejä ja sitä ennen myös muilla järjestelmäliimoilla tilkinnyt systeemejä, tuntui kotoisalta huomata että Rubylla voi kirjoittaa varsin samaan tyyliin hyvin kompakteja, lyhyitä ohjelmia. Ruby kuitenkin on varsin puhdas designin puolesta, joten se ei ole omiaan suosimaan spagettityyliä.

Oma käsitykseni Rubysta kehkeytyi siten, että aluksi kieli tuntui kovin suppealta ja jollain tavalla “ei riittävän ilmaisuvoimaiselta”. Sitten myöhemmin huomasin, että kieli on omalla tavallaan varsin elegantti. Se ei ole kuitenkaan niin puristinen kuin voisi ääritapauksessa kuvitella. Rubyssa on pyritty tuomaan luonnollisuutta (pragmaattisuutta) ja esimerkiksi kieleen on rakennettu villejä veikkauksia yleisimmistä tavoista, joilla kieltä tuntematon ohjelmoija voisi haparoida metodeja. Eli, vaikka aina ei muistaisi, oliko se jonkun asian pituutta (ts. alkioiden määrää mittaava) metodi .size vai .length – molemmat käyvät!

Ruby on tulkattava kieli, käytännössä “väistämättä”, sen ominaisuuksien tarvelistasta johtuen.

Entä se Rails?

Söpö. Timmi. Hyvin dokumentoitu. Neuvotteleva. Aika DRY. Funktionaalinen. Sallii kaiken, tarvittaessa.

Railsin kautta saa varaslähdön erittäin runsaasti varusteltuun laadukkaaseen ekosysteemiin. Kun katselee esimerkiksi tutorial-tason tai pidemmälle vieviä videoita (vink: Railscast Youtubessa), huomaa jälleen, että laatu on kauttaaltaan hyvä: asiat on usein mietitty, opetuksen pedagogiikka on keskivertoa parempaa.

Teemat toki toistuvat Ruby on Railsissa aika lailla kuten monissa muissa.

Ja se rautatielogo!! Kaikki tykkäävät salaa sydämmessään rautatiekulttuurista.

Rails itse on kirjoitettu kokonaan Rubylla. Koko tekniikkapino on täysin avoin, joten yksityiskohtiin voi tutustua mm. Githubin kautta.

Toki se on vain jonkinlainen tunne, mutta ainakin itse luen Github:n projekteista heti ensifiiliksiä. Eräs kohtuu tärkeä asia, varsinkin jos on useita eri vaihtoehtoisia projekteja jotka ajavat saman asian, on käytettyjen teknologioiden kirjo. Tämä analysaattori  tunnetaan yleisesti (?) nimellä Linguist (Github). En pidä kovin paljoa hyvin tilkkutäkkimäisistä teoksista. Jos projektiin on lätkäisty 6 eri ohjelmointikieltä ja vielä lisämausteet päälle, alkaa puistattaa. Kynnys pureutua projektiin nousee välittömästi. Rails-projekteissa monesti tämä kirjo on hyvin matala – usein jopa koko projekti on kirjoitettu vain yhdellä kielellä: Rubylla, eli Railsin alla olevalla kantakielellä.

Mikä Railsista tekee “kivan” ?

Heitän näitä aika naiivista näkökulmasta. Vielä ei ole kilometrejä alla kovin paljoa. Tein periaatteessa ensimmäiset “hieman isomman” Rails-softan 2018. Sitä ennen testailin oikeastaan pelkästään Rubya, sellaisenaan, kielenä – ilman Railsia.

Rails

Rails on minikokoinen öljynporauslautta web-palveluille. Sisältä löytyy kaikki, kuntosalia ja elokuvateatteria myöten, mutta jos haluat plaanata aalloilla nokka pystyssä custom-sikariveneellä 50 solmua tunnissa, Rails ei välttämättä ole oikea valinta. Kuten kaikissa uusissa teknologioissa, kokeneen mentorin antama opastus on kullan arvoista myös Railsin kohdalla. Monista muista jutuista poiketen, Railsistä on myös erittäin hyvälaatuista materiaalia netissä, sekä Youtube-videoina että webissä mm. Ruby on Rails Guides sivustolla.

Get a clutter-free Dia editor

Reading Time: < 1 minute

I love doing both formal and informal modeling in Dia. However, sometimes the grids and other visual clutter bothers. There’s 2 in-page items (the Grid, and Page Breaks) and the Rulers.

The Page Breaks were difficult to turn off.  It took me a lot of time to find the correct place for that. That’s why I want to share it.

We’re aiming for this:

dia_blank_good_looks

Turning off Grid, Rulers and Page Breaks

  1. Click View -> Show Grid (to turn off showing the grid)
    dia_toggle_menuGrid
  2. Click View -> Show Rulers (turn off)
  3. Click File -> Preferences -> [View defaults] -> “Page Breaks” -> Visible (turn off)
    dia_toggle_prefBreaks

That 3rd step was the thing I had been looking for a long time!

Seis, Intel – palataan kesällä!

Reading Time: < 1 minute

Yksi ikävimmistä tavoista aloittaa päivä on huomata, että oma kone ei toimi.

Näillä ohjeilla pistät Intelin mikrokoodi epävakaat jakelut toistaiseksi paussille, apt-pohjaisissa Linuxeissa kuten Ubuntussa.

(Microsoft-laitteille tietoiskua Microsoftin sivulta)

Jos pääsiäisen 2018 tienoilla yhtäkkiä Ubuntu-tietokoneenesi tuntuu “hajoavan”, esimerkiksi näyttämällä kernel panic, tarkista ensin onko kyseessä vain huono ohjelmistopäivitys. Saatat selvitä turhan uuden laitteen ostamiselta, ja kaikelta muulta rumbalta mikä siihen monesti liittyy.

TL;DR: Jos haluat estää mikrokoodipäivityksen

  1. Avaa shelli
  2. sudo apt-mark hold intel-microcode
  3. Tarkista, että meni perille.
  4. Seuraa uutisia seuraavan 3-6 kk aikana aika-ajoin
  5. Kun intel-microcode paketti on alkanut stabiloitua ja kaatumisuutisia ei kuulu, voit ottaa päivitykset käyttöön:
    sudo apt-mark unhold intel-microcode

Tarkista hold ajamalla vielä yksi komento

Helppo tarkistaa, menikö hold perille:

$ apt-mark showhold
intel-microcode

Muista tarkistella aika ajoin miten asia kehittyy. Nyt toistaiseksi, jos pidät muuten koneesi tietoturvallisena, eli Linuxissasi ei ole potentiaalisesti tuntemattomia käyttäjiä sisällä, en näkisi ongelmatilanteen estämiseksi mikrokoodipäivitysten lykkäämistä huonona ideana.

Tasapainottelua: teoreettinen ongelma vai kaatunut kone?

Käsittääkseni kotikäytössä koko Meltdown-ongelma on varsin pieni. Meltdown sallii sivukanavaa pitkin tapahtuvan tiedon lukemisen; käytännössä monen käyttäjän servereissä kernelin muistisuojaus pettää, koska modernien prosessorien cachet ja predictive branching sallii käytännössä prosessille tilaisuuden vakoilla limittäin tapahtuvan laskennan tuloksia niiden jättämien jälkien (“sivuvaikutusten”) perusteella.