Skal STARTTLS være et krav for følsomme email

Martin Thomson har skrevet et lidt kontroversielt Internet-Draft der oprindeligt havde titlen "Postel Was Wrong", som dog blev tampet lidt ned i senere versioner:

https://tools.ietf.org/html/draft-thomson-postel-was-wrong-03

Det er aldrig blevet en officiel RFC, hvilket heller ikke var Martins hensigt, han ville bare have folk til at tænke over tingene.

Man kan naturligvis begræde det InterNet vi kendte og elskede ikke existerer mere, men vi bliver nødt til at se øjnene at 90% af dem der implementerer protokoller er inkompetente, 8% skal "bare have det til at virke" og 2% gør det med fjendtlig hensigt.

Præcis hvor det stiller os med TLS og email er så et godt spørgsmål.

Jeg har personligt først for nyligt enablet STARTTLS på min mailserver, af hensyn til min bank & revisor og jeg tillægger det ikke nogen konstruktiv rolle i beskyttelsen af mit privatliv.

Tværtimod faktisk, jeg har nu en TLS implementering som forøget angrebsflade...

Jeg bruger ikke STARTTTLS på min personlige mailserver. At drive en mailserver synes jeg ikke er en glæde, og jeg nyder ikke specielt at gøre det, ej heller har jeg nogen synderlig kompetence eller talent for det. Jeg gør det mest af princip, fordi jeg går ind for decentralisering, og jeg mener det bør være realistisk for et almindeligt teknisk interesseret menneske at drive en mailserver som resten af Internettet gider interagere med. Bemærk at jeg i denne henseende definerer "almindeligt teknisk interesseret" som en type som mig selv, der har en PhD i datalogi (omend ikke i et netværksrelateret felt) og har brugt Linux/Unix dagligt siden 2003 (min mailserver kører OpenBSD).

Mit problem er at mange af disse sikkerhedsmekanismer ikke er automatiske. De kræver opsætning separat fra "grundprogrammet" (mailserver/HTTP-server), generering af certifikater (som skal vedligeholdes jævnligt), og de er typisk fail-silent. Det er absolut nontrivielt at opsætte nok overvågning til at jeg kan stole på at jeg får besked hvis noget går galt, inklusive hvis overvågningssystemet fejler. På min mailserver bruger jeg DMARC og DKIM, hvilket var en nødvendighed for at andre ville tage imod min post, og det virker skam nu, men jeg har en eller anden svag erindring om at DKIM-nøglerne vist nok udløber engang. Når det engang sker (jeg husker ikke hvornår, eller hvordan jeg tjekker, for dette er noget jeg har læst som een gang for flere år siden), så opdager jeg det ved at min post bare ryger i spamkassen.

Jeg har indtil videre formået at holde teltet nogenlunde tørt (inklusive LetsEncrypt til mine HTTP-behov), men jeg synes gradvist at Internettet begynder at blive mindre decentraliseret - ikke af tekniske årsager, men fordi den kompetencemæssige barrier to entry bliver højere og højere. En af de primære årsager til at jeg nu bruger OpenBSD er netop fordi konfigurationsmulighederne er færre, så jeg har en chance (som amatør) for at sætte mig ind i hvad jeg skal slå til for at få en fungerende opsætning, og samtidigt nogenlunde forstå hvordan det fungerer. Jeg ved ikke om der er en teknisk løsning på problemet.

Det var oppe at vende først på året ifm. Datatilsynets skærpede krav til kryptering af mails "in transit". Så jeg fik et udtræk af top-100 domæner, som vores kunder har givet os som deres mailadresse. Jeg mener vi har tæt på en million mail-adresser i kundekartoteket, så det burde være et ret god repræsentation af hvad der er normen blandt private danske mail-modtagere.

Bortset fra at det er overraskende hvor mange der staver deres mail-adresse forkert (gnail.com, anyone?), så var det ud af top-100 kun et eneste domæne (vist nok nede omkring #60) hvis mailserver ikke understøttede STARTTLS.

Vi kræver dog ikke at al mail skal via en krypteret forbindelse, kun på visse domæner. Der er stadig lidt nervøsitet hvis nu direktørens ultra-vigtige mail ikke kom frem.

Måske det var på tide at slå det til for storner.dk ...

Kræv STARTTLS, nedlæg e-boks/Digital post.

Evt. kan tjenesten få lov at køre videre som en almindelig emailservice til folk der ikke kan finde ud af at få sådan en et andet sted fra.

Kræv STARTTLS, nedlæg e-boks/Digital post.

Jeg har selv haft mine egne udfordringer med e-boks.

Jeg oplevede at min mail server smed konsekvent mails ud som kom fra e-boks. I ved de der: "Der er en ny mail i din e-boks"-mails.

Årsag:

Man kan ikke lave DNS lookup på e-boks udgående server, så min server kunne ikke verificere at mailen kom fra en legitim afsender.

Med andre ord kunne min mailserver ikke se forskel på en spambot og legitim mail fra e-boks. :-(

... Jeg syntes at have set en RFC om dette...

Jeg endte med at tilføje e-boks mailservere til min hosts-fil, men det er ikke optimalt.

Jeg havde mx-hotel (gratis DNS) som postbox for vores private domain, de har indført tvungen kryptering. Pludselig modtog jeg ikke notifikationer fra kommunen omkring tømning af skraldespanden / papircontainer mm, og jeg modtog ikke nodifikationer fra Viggo (Efterskolernes intra) om beskder. Da jeg dermed mistede post gik den ikke, især ikke fordi man ved ikke havd man mister f.eks. mistede jeg også fra erhversministeriet og opdagede det først, da jeg rykkede pr tlf, det går bare ikke..... idag ligge vores postkasser på unoeuro.com, jeg var tæt på at sætte min egen postfix op, men for vist nok 18 kr om måneden faldt valget på en købeløsning.

Prøv li' at hør her - vi skriver 2019 og vi diskuterer hvorvidt STARTTLS skal sættes per default?? Allermest bliver jeg en lille smule trist over at vi ikke er kommet videre...

I februar i år var jeg i San Francisco og sad med i et panel omkring DANE og adoption raten i et rum der var fyldt med folk fra Comcast, Google, Facebook, Microsoft etc. - rimeligt grænseoverskridende at dele vores case-story for det publikum. Årsagen var at vi kort før havde krydset grænsen og havde nået mere end 1 mio DANE enablede domæner world wide. Prøv selv at kigge med her: https://stats.dnssec-tools.org/#summary Den der lodrette streg på grafen i December 2018 - den har jeg (og en masse andre hos one.com) arbejdet hårdt for - og vi er fortsat med at enable for flere TLD'er lige så stille siden da. :-)

Så skal du bruge STARTTLS som default - JA - men det er jo bare mimiumskriteriet på internettet idag.....gør som os andre tag skridtet fuldt ud og "Make DANE great again" ;-)

P.S Jeg tænker at jeg skal have lavet en opdatering af mit gamle blog-opslag om fremtidens mailstandarder, som fortæller hvor vi er idag.

Tværtimod faktisk, jeg har nu en TLS implementering som forøget angrebsflade...

Og letsencrypt er "nemt", man skal bare lade certbot køre på sin maskine - for at letsencrypt kan 'snakke med den'.

Jeg får 'fnidder' ved tanken om at skulle lade noget "unødigt" køre - og down/up-loade noget - på min maskine.

Heldigvis kan en "tom" virtuel maskine være certbot-bot ;-)

K

Er kryptering af emails i transit ikke bare falsk trykhed?

Min erfaring med Randers kommune og deres borgere, har fortalt mig at kryptering i transit ikke hjælper en flyvende fis. Folk skriver forkert så ofte, at vi på ingen måde må opfordre folk til at sende noget som helst følsomt på email.

Hvis Folk for den opfattelse at emails er sikre, hvis alt er krypteret i transit, gør vi sikkerheden dårligere.

For at fortsætte med, hvad Troels skriver, så vil jeg sige, at alt det her drejer sig om usability, UX og UI. Altså hvor nemt gør vi tingene, og hvor ligefrem er det i dagligdagen at vedligeholde. Når selv verden bliver for kompleks for nørder, så skal der noget til for at gøre verden nemmere og overskuelig.

Et forslag: Man kan vælge at støtte et af de projekter, der laver alt-i-én-løsninger, der pakker kompleksiteten ind (men på en transparent/gennemsigtig måde) - fx et projekt, der er skrevet i et sprog, hvor man selv kan bidrage med kode m.m.

Alternativt: Komme med nye idéer til at give overblik m.m. Fx noget jeg kunne bruge ville være et værktøj, der giver grafisk overblik: 1. nem opsætning af det, der er væsentligt. 2. alarmer/early warnings inden certifikater udløber og/eller værktøjer, der gør det automatisk. 3. dual view: grafisk opsætning og fx et delt view, der viser de genererede konfigurationer (gennemsigtighed). 4. køre det som et open source projekt. 5. give/have anbefalinger og linke til hjælpesider/guides vedr. projektet/produktet samt viden om standarder/rfc'er m.m.

Hvad har jeg i tankerne - fx noget af samme vigtighed/tilgængelighed som pfSense og LibreOffice.

Til at starte med ville det nok være en god idé at lave noget research af alle eksisterende alt-i-én-løsninger for at afdække deres brugbarhed og mangler, samt hvor nemt det er at udvikle/udvide på dem.

Ja, SMARTTLS er kun kryptering mellem mail servere, det er ikke end to end sikkerhed. Fra afsender til modtager kan der være flere servere, og dem i midten kan se med.

Det bedste ville være hvis alle lærte at sende rigtig krypterede mails når noget vigtigt skal frem. Desværre vælger den normale borger de nemme gratis mail løsning som hotmail og gmail, og disse løsninger vil helst ikke kryptere noget, for så kan de jo ikke se med. Du får f.eks. proppet gmail i halsen når du køber en Android smartphone.

Værre er det at mange efterhånden mere bruger Messenger til små beskedder fremfor SMS eller e-mail. Vi skal passe på hvad vi skriver.

Fra afsender til modtager kan der være flere servere, og dem i midten kan se med.

Det bedste ville være hvis alle lærte at sende rigtig krypterede mails når noget vigtigt skal frem.

Det er der løsninger der gør: * PGP * SePo - som virker i princippet som en automatiseret PGP løsning

De har visse udfordringer: * PGP kræver så vidt jeg ved manuel udvæksling af certfikater * SePo koster penge (i hvert fald for den ene ende) og virker potentielt set kun i DK (det er et eDagX - jeg kan ikke huske om det var 2 eller 3 - initiativ)

Det elegante ved TLS er at brugeren ikke blandes ind i processen men brugeren selv er så ansvarlig for sikkerheden i sin ende - og ja, det er langt nemmere at angribe brugeren end at opfange mailen undervejs. Kryptering undervejs er mere for at forhindre at mails kan læses direkte via en snifferport end for at give brugeren ægte sikkerhed.

For at få ægte end2end kryptering til at virke er det nødvendigt at der oprettes trustworthy CA'er til borgerne som vel at mærke drives GRATIS - det er der nok ikke den store politiske tilslutning til.

Mit problem er at mange af disse sikkerhedsmekanismer ikke er automatiske.

Se her er et punkt hvor vi absolut kan blive enige.

Der er alt for meget mumbo-jumbo forbundet med at lave en sikker mailserver - bare søg på f.eks. DMARC, og der kommer en halv milliard opskrifter frem, som på ingen måde er ens (eller specielt læsbare).

Og det er lidt ærgerligt det skal være sådan et minefelt af fejlmuligheder, som gør at rigtig mange enten intet gør, eller misligholder tingene - og et eller andet sted mener jeg faktisk at bruge en halv dag på at sætte noget op (og sådan ca. 100.000 andre sysadms gør det samme i parallel) som burde være trivielt er uhyggelig lang tid, for noget som vel hvis man havde overblikket kunne klares i et 10-15 linjers script (måske lidt overdrevet, men ikke helt).

Det absurde (hvis ellers man må bruge sådan et "nasty" udtryk) er altså, at der sidder en masse som hver især prøver at dechifrere hvordan det skal gøres (citat: "Plus lidt andre indstillinger, som I må google jer til.") for noget som burde kunne standardiseres.

Men det er vel egentlig meget karakteristisk for hele mailområdet, det er stadig gennemsyret af et tankesæt fra computerens barndom, og en forhippelse på at alting helst skal udføres vis kommandoer på to-tre tegn, og bytes er kostbare, så lad os gøre det kryptisk og i hvert fald ikke læsbart.

Imo burde hele mail paradigmet moderniseres, herunder burde relaying ikke være nødvendigt i 2019, og post burde håndteres efter et challenge-response princip - dvs. jeg vil sende en mail til hk@kramse.com, så henvender jeg (dvs. min mailserver) mig til kramse,com og siger jeg har en mail, hvorefter kramse siger, jeg vender tilbage. Dernæst laver kramse dnsopslag på mig, og vender tilbage til mig (som skal være på et validt domæne) og siger; ja hvad så. Sluttelig siger jeg at jeg har mail til hk, og hvis ellers kramse har en bruger der hedder kh, ja så vil han gerne modtage mailen.

Det har godt nok ikke så meget med kryptering at gøre, men det kunne eleminere næsten al spam, og sikre leveringsruten, da et krav for at sende mail er et validt domæne, som jo kan nedlægges ved misbrug - karantænetid kan være medbringende til at gøre det endnu bedre.

Herudover, så er jeg helt enig med din betragtning om decentralisering (og ingen gørglesnagning), fuldstændig som jeg gerne vil have at den smule post hvor PestDK ikke helt har skræmt kunderne væk, leveres i min brevkasse, ikke at jeg skal gå over på posthuset og allernådigst bede en funktionær der om at udlevere det åbnede brev til mig.

Der er alt for meget mumbo-jumbo forbundet med at lave en sikker mailserver - bare søg på f.eks. DMARC, og der kommer en halv milliard opskrifter frem, som på ingen måde er ens (eller specielt læsbare).

De store syndere i den henseende er de professionelle email leverandører. Jeg kan kun lige komme i tanke om Amazon SES som giver teknisk korrekt information, vejledning er lidt knudret skrevet, så folk ender typisk alligevel med at misforstå den.

Der er alt for meget mumbo-jumbo forbundet med at lave en sikker mailserver - bare søg på f.eks. DMARC, og der kommer en halv milliard opskrifter frem, som på ingen måde er ens (eller specielt læsbare).

De store syndere i den henseende er de professionelle email leverandører. Jeg kan kun lige komme i tanke om Amazon SES som giver teknisk korrekt information, vejledning er lidt knudret skrevet, så folk ender typisk alligevel med at misforstå den.

De store syndere i den henseende er de professionelle email leverandører. Jeg kan kun lige komme i tanke om Amazon SES som giver teknisk korrekt information, vejledning er lidt knudret skrevet, så folk ender typisk alligevel med at misforstå den.

Men hvorfor er det sådan Henrik?

Tag nu bare DMARC og DKIM som du anser for trivielle, fordi du har knækket nødden - burde der ikke kunne laves et forståeligt regelsæt, på samme måde som man lave lover og betænkninger, da der alt andet lige ikke kun er tale om hobbyting-man-selv-må-finde-ud-af, men noget som er vitalt for alle postservere?

I øvrigt kan jeg anbefale DigitalOceans faq, den er ganske glimrende og til at forstå.

Hvis jeg laver en ny service, som blandt andet baserer sig på følsomme data. Det kunne være en pensionskasse, patientjournaler, forsikring eller lignende. Burde den slags sites og services ikke straks KRÆVE TLS?

Jo, det burde de. Ikke på e-mail, men på deres kundeportal. Der er TLS opsætning rimelig standardiseret. E-mail har ikke kunne følge med og der har været for mange kokke til at fordærve maden [Indsæt XKCD om standarder].

Bruger den nye service e-mail, så bør det være noget ala

[quote] Kære kunde

Der er indhold i vores kundeportal, som kræver din opmærksomhed.

Med venlig hilsen Din personfølsomme serviceudbyder [quote]

Bør de stadig implementere DMARC, DKIM og SPF? Ja, det bør de.

SMTP over TLS / StartTLS give ikke megen sikkerhed, men det er reelt blevet et krav herhjemme. Hele problemet ligger i, at der ikke er nogen måde at validere certifikatet på, så man kan lege aktiv Monkey-in-the-Middle og bruge sit eget cert.

Personlig mener jeg, at der burde laves en RFC der pålægger at man smider godkendte certifikater i DNS. Evt noget SPF lignende hvor man fortæller hvor et cert kan hentes. Ofte er MX record noget der peger et andet sted. Og man skulle gerne kunne sætte op til at acceptere eksempelvis MX'ens cert.

End-to-end kryptering kræver mere, og der er uenighed om certifikater, de skal udveksles først etc. Det bør laves så man kan slå op på user.mailserver.domæne.com og hente public key der. Så kan tingene automatiseres. Men samtidig kan mail adresser trawles, medmindre man lave aktivt forsvar ved at levere public keys til alle opslag.

Personlig mener jeg, at der burde laves en RFC der pålægger at man smider godkendte certifikater i DNS.

Ej hvor er det sjovt du nævner det - har du kigget på: DNS-Based Authentication of Named Entities (DANE), a protocol that enables increased security for email communications. DANE allows a domain owner to specify which CA is allowed to issue certificates for a particular resource, which solves the problem of any CA being able to issue certificates for any domain.

https://tools.ietf.org/html/rfc7672

Men hvorfor er det sådan Henrik?

Tag nu bare DMARC og DKIM som du anser for trivielle, fordi du har knækket nødden - burde der ikke kunne laves et forståeligt regelsæt, på samme måde som man lave lover og betænkninger, da der alt andet lige ikke kun er tale om hobbyting-man-selv-må-finde-ud-af, men noget som er vitalt for alle postservere?

I øvrigt kan jeg anbefale DigitalOceans faq, den er ganske glimrende og til at forstå.

Amazon SES vejledningen misforstår folk fordi de ikke læser det hele, men kun til det punkt hvor de ser en stump SPF record :-) DMARC er der ikke så meget i, det er bare end DNS record. DKIM derimod der kan godt være lidt besværligt alt afhængig af hvilken udbyder man anvender. Men de helt store problemer ligger i noget så basalt som at få strikket en SPF record sammen som er valid. Det er den del der nærmest saboteres af fejlagtige vejledninger fra de professionelle leverandører.

Altid sjovt at læse disse indlæg og folks kommentar, de fleste tænker for simpelt og forstår derfor ikke hvor mange faktor som kan/får implementeringer til at fejle.

Plus udtryk som sikkermail, er misbrugt for hvad er sikkerhed for en, er til grin for andre, og i forbindelse med TLS/StartTLS giver det et helt forkert billede, da mailen ikke er krypteret ved stilstand, kun under transport.

Sikkerhed skal tænkes ind i designet, og ikke prøves at løses senere, og følsomme data skal være i kontrol af Ejer af disse data, med andre ord fjern det person-følsomme fra data direkte, så de kun bliver følsomme når man har de rigtige forbindelser/sammenhæng mellem data og personen hvis personen har givet lov til dette.

PGP er både forsimplet og for besværligt, med det mener jeg da der er meget besvær med at udveksle Public/Offentlig nøgler, så bruges der næsten 100% af gangene hvor PGP eller S/MIME er i stil kun et sæt nøgler, hvorfor det er for simpelt og nemt at spore og hacke. (Google CitizenKey, vi skal ha løst problemet med CPR/NemID/E-boks/osv. )

StartTLS default, har de fleste købet mail systemer som standard, men med dette menes "Opportunistic TLS"/"Opportunistiske TLS", hvor Self-Signed nøgler standard bruges og accepteres, så ja transporten bliver krypteret hvis muligt, men du ved ikke hvem afsender eller modtager i virkeligheden er, så hvor sikkert er er det lige? (svare lidt til at ”beskytte” en ZIP fil med koden ”password” eller at koden sendes sammen med filen i en mail.

Vil ikke forklar alle de mulig Postfix/TLS-tilstande der er, men bare lige liste dem, så man tydeligt kan læse hvor simpelt denne artikel og tråd stiller det op

http://www.postfix.org/TLS_README.html none (No TLS.) may (Opportunistic TLS.) encrypt (Mandatory TLS encryption. ) dane (Opportunistic DANE TLS. ) dane-only (Mandatory DANE TLS. ) fingerprint (Certificate fingerprint verification. ) verify (Mandatory server certificate verification. ) secure (Secure-channel TLS. )

SANS ISC har idag posted et indlæg med titlen "Is it Safe to Require TLS 1.2 for E-Mail". Det virker relevant for dette blogindlæg.