Sähköpostin heikot kohdat

Mitä sähköpostin heikko tietosuoja käytännössä tarkoittaa? Ainakin tietojenkalastelua ja identiteettivarkauksia, murrettuja sähköpostilaatikoita, tietoliikenteen salakuuntelua, ja viestien sisällön kyseenalaista luotettavuutta.

Lähettäjän näkökulmasta heikko tietosuoja tarkoittaa osittain käänteisiä riskejä mitä vastaanottajalle. Jos vastaanottajan ongelmana ovat tietojenkalasteluviestit väärällä identiteetillä, lähettäjän ongelmana on oikean identiteetin todistaminen.

Tässä artikkelissa käsitellään lyhyesti seitsemän sähköpostin tietosuojan ongelmakohtaa lähettäjän näkökulmasta: 

1. Lähettäjän identiteetin todistaminen
2. Lähettäjän postilaatikon tietoturva
3. Viestin sisällön tietosuoja
4. Viestiliikenteen salaaminen
5. Vastaanottajan postilaatikon tietoturva
6. Tieto sähköpostin avaamisesta
7. Vastaanottajan identiteetin tunnistaminen

Miksi näissä kohdissa sähköpostin oletusarvoinen tietosuoja on heikko? Tähän vastaamiseksi on etsittävä selityksiä sähköpostin tekniikasta ja sen historiasta. Jokaisen kohdan lopuksi esitetään vaihtoehtoja, joilla tietosuojaongelman voi ratkaista.

 

1. Lähettäjän identiteetin todistaminen

Ongelma

Kuka tahansa voi käyttää lähettäjän nimeä ja sähköpostiosoitetta, tai organisaation visuaalista ilmettä.

Mediassa säännöllisesti varoitellaan tietojen kalasteluviesteistä, joissa tekeydytään tunnetuksi organisaatioksi, kuten finanssitaloksi tai internetjätiksi. Ehkä kuuluisin tapaus on kalasteluviesti John Podestan henkilökohtaiseen gmail-osoitteeseen, josta tämän artikkelin otsikkokuva on peräisin. Podesta toimi kalasteluviestin vastaanottaessaan Hillary Clintonin 2016 presidentinvaalikampanjan puheenjohtajana. Loppu on kansainvälisen tiedustelun historiaa.

Ongelman taustaa 

Sähköpostin formaatin ensimmäinen määrittely on RFC 733 vuodelta 1977. Määrittelyn mukaan From: -kentässä tulisi oletuksena olla työasemalle kirjautunut käyttäjä, RFC:n esimerkissä työasemalle Host kirjautunut käyttäjä Jones:

From: Jones at Host 

Määrittelyssä kuitenkin korostetaan, että From: -kentässä tulisi olla viime kädessä viestin kirjoittajan, ei lähettäjän nimi.

Jos toisella henkilöllä (Sarah) ei ole omaa sähköpostilaatikkoa, hän voi määrittelyn mukaan käyttää sihteerin laatikkoa (Secy) viestien lähettämiseen, ja määritellä vastausviestien osoitteen (Jones) erikseen:

From:     Sarah Friendly
Sender:   Secy at Host
Reply-To: Jones at Host

Sähköpostilaatikoita pystyi tuohon aikaan käyttämään vain oman organisaation päätteillä. Tämä on hyvin käytännöllinen selitys, miksi From: -kentän sisältö voi olla vapaasti määriteltävissä.

Vasta paljon myöhempi RFC 2822 vuodelta 2001 yrittää vaikuttaa asiaan, mutta on auttamattomasti myöhässä:

In all cases, the "From:" field SHOULD NOT contain any mailbox that 
does not belong to the author(s) of the message.

Ratkaisuja

• Sähköpostipalvelimien tunnistaminen. Lähettäjän nimipalvelussa määritellään SPF ja DKIM-tietueissa luotetut SMTP-palvelimet. Tällä tavoin voidaan validoida, että viesti on lähtenyt verkkotunnuksen (esim. gmail.com) luottamalta postipalvelimelta. Tässä ei siis identifioida lähettäjähenkilöitä, vaan organisaation sähköpostipalvelimia. Organisaation henkilö voi lähettää toisen henkilön nimissä viestejä, ja murretuista laatikoista lähetetyt viestit menevät domainin validoinnin läpi.
• Lähettäjä allekirjoittaa viestin digitaalisella allekirjoituksella. PGP ja S/MIME ovat tekniikkoja tähän.
• Lähettäjä käyttää hallinnassaan olevaa suojattua verkkopalvelua viestintään. Pankit ja vakuutusyhtiöt toimivat näin. Suojattua viestintäpalvelua ei kuitenkaan tarvitse rakentaa itse, vaan sen voi hankkia SaaS-palveluna. Esimerkiksi julkishallinnon Suomi.fi-viestit ja tietosi.fi -palvelut ovat tällaisia. Myös dokumenttien sähköiseen allekirjoitukseen tarkoitettuja verkkopalveluja voidaan hyödyntää.

 

2. Lähettäjän postilaatikon tietoturva

Ongelmat

• Viestit säilytetään työasemalla ja/tai postipalvelimella salaamattomina.
• Postilaatikkoon pääsee käsiksi heikolla salasanalla tai tietojenkalastelun seurauksena.

Ensimmäinen ongelma koskee työasemien fyysistä turvallisuutta. Jos sähköpostilaatikko on levyllä salaamattomana, työaseman varkaus tai luvaton pääsy levyyn voi johtaa viestien vuotamiseen. Toinen ongelma, heikot salasanat ja tietojenkalastelu eivät ratkea työaseman levynsalauksella. Vaikutus korostuu pilvipalveluna tarjottavassa sähköpostissa. Esimerkiksi Microsoft Office 365 -laatikot ovat kesällä ja syksyllä 2018 olleet aktiivisen tietojenkalastelun kohteena.

Ongelmien taustaa

Työasemien levyjen salaus yleistyi vasta 2000-luvulla, esim. tänä päivänä Windows-koneissa tavallisesti käytetty Bitlocker julkaistiin Windows Vistan ominaisuutena vuonna 2007. Salasanojen kompleksisuusvaatimus on kasvanut käytössä olevan laskentatehon lisääntymisen ja löydettyjen haavoittuvuuksien seurauksena, eikä postijärjestelmä välttämättä pakota riittävän vahvaa salasanaa tai aktiivisesti estä brute force -hyökkäyksiä. Tietojenkalastelun vaikuttavuus on kasvanut pilvipohjaisen sähköpostin yleistyttyä.

Ratkaisuja

• Postilaatikko salataan levyn salauksella.
• Käytetään monivaiheista tunnistautumista (multi-factor authentication, MFA) webmailiin. Esimerkiksi Viestintäviraston Kyberturvakeskus kehottaa kaikkia Office 365 -tuotteita käyttäviä yrityksiä ottamaan käyttöön kaksivaiheisen tunnistautumisen. Tämä hankaloittaa sähköpostin käytettävyyttä, mutta on ainoita suojautumiskeinoja kalasteluhyökkäyksiin.
• Käytetään postilaatikon viestit salaavaa sähköpostia kuten ProtonMail tai MailFence + kaksivaiheista tunnistautumista
• Käytetään omassa hallinnassa olevaa suojattua verkkopalvelua viestintään

 

3. Viestin sisällön tietosuoja

Ongelma

Sisältö luettavissa ja muutettavissa sähköpostia välittävillä palvelimilla.

Ongelman taustaa

Simple Mail Transfer Protocol (SMTP) -protokollan alkuperäinen määrittely (RFC 821) alkaa sanoilla:

The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently.

SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel.

Jo nimensä puolesta sähköposti on tarkoitettu yksinkertaiseksi. Viestien salaaminen koko viestinvälitysinfrastruktuurissa ei kuulosta simppeliltä eikä valmistajariippumattomalta. SMTP-protokollassa sähköpostiviestejä välittävä palvelin näkee ja voi muuttaa viestien sisältöä samalla tapaa kuin välitysketjun alkupäässä oleva viestin lähettäjä. SMTP-palvelintoteutuksissa viestit monesti tallennetaan ainakin lyhyeksi aikaa salaamattomina postipalvelimien levylle postijonoihin.

Ratkaisuja

• Salataan ja digitaalisesti allekirjoitetaan viesti. PGP ja S/MIME ovat tekniikkoja tähän.
• Toimitetaan vain vastaanottokuittaus sähköpostiin, ja käytetään viestien lukemiseen web-clientia. Tämä toimintaperiaate on monelle tuttu perinteisessä "turvapostissa", jossa salaava sähköpostiyhdyskäytävä huolehtii ilmoitusviestien lähettämisestä.
• Vaihtoehto on, että salaavan yhdyskäytävän ja tavanomaisen sähköposticlientin sijaan viestintöän käytetään pelkästään omaa suojattua verkkopalvelua.

 

4. Viestiliikenteen salaaminen

Ongelma

Selväkielinen tietoliikenne on salakuunneltavissa.

Ongelman taustaa 

SMTP-protokolla ja client-protokollat (POP/IMAP) ovat selväkielisiä. Vasta SMTP-protokollan ja client-protokollien laajennuksissa (RFC 3207, RFC 2595) on määritelty sähköpostin tietoliikenteen suojaaminen Transport Layer Security-protokollan (TLS) avulla.

Ratkaisuja

• Salataan tietoliikenne TLS-protokollalla. TLS:n pakottaminen on kuitenkin hankalaa, koska tällöin osa viesteistä ei mene perille. SMTP-protokollan STARTTLS -laajennus vaatii tuen sekä lähettävältä että vastaanottavalta osapuolelta, ja jos jompikumpi puuttuu niin tiedonsiirtoa ei voi salata. Googlen Transparency Reportin mukaan Googlen sähköpostipalveluissa tällä hetkellä yli 90% vastaanotetuista viesteistä kulkee salattuna ja lähtevistä viesteistä yli 85% voidaan välittää TLS-salattuna. Viestien sisällön lisäksi TLS salaa suuren osan metatietoa postipalvelimien välillä.
• Lähetetään sähköpostitse ainoastaan ilmoitusviestejä, ei salattavaa sisältöä. Luetaan viestit https-yhteydellä turvapostissa tai suojatussa verkkopalvelussa.

 

5. Vastaanottajan postilaatikon tietoturva

Ongelma

Lähettäjä ei voi vaikuttaa vastaanottajan postilaatikon suojaukseen.

Ongelman taustaa

Kyse on yleisemmästä digitaalisten aineistojen hallinnan ongelmasta. Kun vastaanottajalla on kopio viestistä, lähettäjä ei voi enää sen leviämiseen vaikuttaa.

Ratkaisu

Käytetään lähettäjän hallinnoimaa turvapostia tai suojattua verkkopalvelua, jossa viestin avaamista voi rajoittaa eri keinoin. Esimerkiksi viestin säilytysaikaa ja avauskertojen lukumäärää voidaan rajoittaa, ja sallia pääsy vain tietyistä IP-osoitteista. Tällä voidaan lieventää ongelmaa, mutta ei poistaa sitä, sillä vastaanottaja voi aina kopioida sisällön muualle talteen. Lähettäjä kuitenkin pystyy osoittamaan, että on tehnyt voitavansa asiassa.

 

6. Tieto sähköpostin avaamisesta

Ongelma

Lähettäjä ei saa kuittausta viestin vastaanottamisesta tai avaamisesta.

Ongelman taustaa 

Sähköposti on best effort -tyyppinen teknologia, jossa ei ole takeita viestin perillemenosta. Vastaanottajalta pyydettävään kuittaukseen vastaaminen on
vapaaehtoista, jolloin sähköpostien vastaanotto ja avaaminen ei ole auditoitavissa.

Ratkaisu

Tieto viestin avaamisesta voidaan tallentaa turvapostin webmailissa tai suojatussa verkkopalvelussa.

 

7. Vastaanottajan identiteetin tunnistaminen

Ongelma

Lähettäjä ei tunnista vastaanottajaa kuin sähköpostiosoitteella. Tunnistamisen auktoriteettina on vastaanottajan sähköpostiosoitteen myöntänyt organisaatio. Tämä ei usein riitä henkilöllisyyden todentamiseen, esimerkiksi jos viestitään ennestään tuntemattomalle yksityishenkilöasiakkaalle tämän Gmail-osoitteeseen.

Ongelman taustaa

Henkilön tunnistaminen perustuu uskottavan auktoriteetin toteuttamiin vahvoihin tunnistautumistapoihin, jotka ovat tyypillisesti kansallisia, kuten Suomessa TUPAS-pankkitunnistautuminen ja mobiilivarmenne. Asiakasviestinnässä paras auktoriteetti on usein lähettäjä itse, jolla on vahva käsitys vastaanottajan osoitteen oikeellisuudesta.

Sähköpostiosoite on kuitenkin hyödyllinen vastaanottajan organisaation tunnistamisessa sähköpostidomainin perusteella. TLS-protokollaa käytettäessä voidaan lisäksi tarkastaa vastaanottavan SMTP-palvelimen varmenteen oikeellisuus.

Ratkaisuja

• Manuaalinen kaksivaiheinen tunnistus: salataan viesti tai sen liitteet ja toimitetaan salasana SMS-viestinä
• Tunnistetaan turvapostin vastaanottaja matkapuhelinnumerolla ja SMS-kertakäyttösalasanalla.
• Tunnistetaan suojatun verkkopalvelun käyttäjä vahvasti pankkitunnuksilla tai mobiilivarmenteella.

 

Lopuksi

Sähköpostin välittäminen sähköpostipalvelimien kesken perustuu SMTP-protokollaan, jonka ensimmäinen määrittely on peräisin vuodelta 1982 (RFC 821). Legendaarisen Jon Postelin alkuaan kehittämä protokolla on yksi internetin menestystarinoita. Sen toimintalogiikka on kuitenkin hyvin avoin, protokollaa ei yksinkertaisesti ole suunniteltu luottamukselliseen viestintään nykyisen kaltaisessa internetissä. Tästä johtuen tehokkaimmat ja helppokäyttöisimmät suojauskeinot yleensä perustuvat muuhun kuin oikeaan sähköpostiin.