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

Af 23

Officielle lydspor til dette indlæg er Carpenters: Please Mr. Postman
https://open.spotify.com/track/74jZhGv0fdLaf9q8AZZ15k?si=t011UjoGQlCcrXE... og Elvis Presley: Return to Sender https://open.spotify.com/track/2cdzutoqFK6sfW6exi7oXh?si=fcCLVYCgQZ2NG7i...

Jeg driver min egen mailserver, med de sædvanlige værktøjer Postfix og Dovecot, hvilket er en glæde. Når jeg siger glæde er det indkluderet leg med scripts og konfigurationen. Jeg nyder at pille ved min løsning og drive en ordentlig server.

Det er en service som jeg driver for mig selv, mit firma, og enkelte andre. Vel og mærke uden at snage i andres email. Gmail og de andre miner jo vores data, og det er jeg ikke ok med.

Hvorfor er du selv OK med at bruge en service som snager i dine private data? Den er jo ikke gratis.

Nå, men i en måneds tid har min ekskone tålmodigt fået advarsler om at jeg havde skiftet certifikatet, til et nyt self-signed. Det er selvfølgelig ikke iorden, men camps som BornHack og scatterbrain gjorde at jeg først fik set på det igår.

Igår brugte jeg så den indbyggede client acme-client på OpenBSD, til at bede om Lets Encrypt certifikat, ved hjælp af indbyggede httpd på OpenBSD. OpenBSD OpenBSD OpenBSD! YAY! Det er virkeligt rart når et operativsystem tilbyder sikre og gode enkle services der opfylder de fleste krav.

Faktisk skulle jeg blot tilføje domænet/navnet til konfigurationsfilen /etc/acme-client.conf :

domain mail.kramse.org {
  domain key "/etc/ssl/private/mail.kramse.org.key"
  domain certificate "/etc/ssl/mail.kramse.org.crt"
  domain full chain certificate "/etc/ssl/mail.kramse.org.pem"
  sign with letsencrypt
}

Derefter kan acme-client køres og automatiseres med crontab. Lækkert og nemt.

Når filerne så lå der skulle de blot bruges, key blev genereret uden en lang uforståelig OpenSSL kommando, og kunne sammen med certifkat bruges direkte:

/etc/postfix/main.cf:smtpd_tls_cert_file = /etc/ssl/mail.kramse.org.pem
/etc/postfix/main.cf:smtpd_tls_key_file = /etc/ssl/private/mail.kramse.org.key
/etc/dovecot/dovecot.conf:ssl_cert = </etc/ssl/mail.kramse.org.crt
/etc/dovecot/dovecot.conf:ssl_key = </etc/ssl/private/mail.kramse.org.key

Plus lidt andre indstillinger, som I må google jer til.

Udover lidt oprydning og andet på serveren tog det relativt kort tid. Vi taler om at en dygtig sysadmin type vil kunne gøre det fra nul til fungerende på en halv dag.

Derefter kom jeg til min næste tanke, hvorfor kæmper vi med at slå SSLv2 og SSLv3 fra, når vi tillader helt ukrypteret aflevering af email?! Det er sgu da tosset. TLS all teh things!

Der kom også fra Datatilsynet sidste år: Skærpet praksis ift. krypteret e-mail Publiceret 23-07-2018 https://www.datatilsynet.dk/presse-og-nyheder/nyhedsarkiv/2018/jul/skaer...

Jeg spurgte derfor på Twitter:

Når vi skriver 2019 har STARTTLS eksisteret i ca. 20 år.

SMTP Service Extension for Secure SMTP over TLS, January 1999
https://tools.ietf.org/html/rfc2487

og opdateret med:
SMTP Service Extension for Secure SMTP over Transport Layer Security
https://tools.ietf.org/html/rfc3207

I begge to står,

A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally. This rule prevents the STARTTLS extension from damaging the interoperability of the Internet's SMTP infrastructure. A publicly-referenced SMTP server is an SMTP server which runs on port 25 of an Internet host listed in the MX record (or A record if an MX record is not present) for the domain name on the right hand side of an Internet mail address.

Så jeg /må ikke/ - men altså ser vi på email er det jo generelt en stor bunke valgfrie standarder med et ton overbygning, koblet med DNS, koblet med SPF, DKIM, DMARC og flere andre.

Så hvem skal bestemme om min lille server er lidt mere krakilsk?! Det gør jeg.

Mandatory TLS

Derfor slog jeg det til, troede jeg. Jeg glemte dog at Postfix har TO indstillinger, så den rigtige metode er:

smtpd_tls_security_level = encrypt
smtp_tls_security_level = encrypt

Når begge er sat vil en server eller klient der prøver at sende via SMTP uden STARTTLS opleve følgende:

...
RCPT TO: hlk@kramse.org
530 5.7.0 Must issue a STARTTLS command first
DATA
530 5.7.0 Must issue a STARTTLS command first

Altså ikke få lov til at aflevere email. Det var ønsket, men går det?

En der svarede hurtigt på mit tweet igår var Brian R. Jensen
@BrianRJensen, tak for hurtigt svar!

Det bekræftede mig og jeg glæder mig til at se hvad der sker. Jeg vil også godt høre andres erfaringer.

Når vi så har lidt erfaringer, hvad er så vores holdning til en "ny" service som sættes på internet.

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?

Jeg er med på supportproblemet der kan opstå, kunde der ikke modtager email, men er det ikke værre at de bliver sendt ukrypteret.

Addendum

Jeg ved godt at STARTTLS kan udsættes for aktivt person-in-the-middle angreb, men det kræver en del.

Jeg er også opmærksom på at mange servere har certifikater som er udløbet, fejlkonfigurerede, self-signed uden mulighed for check osv.

Vi er dog nødt til at gøre noget ved ukrypteret email! Google har statistik over kryptering outbound og inbound, Email encryption in transit https://transparencyreport.google.com/safer-email/overview som siger 92% og 94% - så det lyder jo godt. Resten som ikke understøtter kryptering må sgu lige bruge en halv dag!

Kom gerne med eksempler på organisationer som burde understøtte TLS - og DMARC. Check Henrik Schacks https://dmarc.dk/dmarc-hall-of-shame/ og skub til dem du kender.

Specielt vil jeg gerne høre dit argument for IKKE at slå det til - og husk at du dermed argumenterer for at sende data ukrypteret over internet, inkl. kodeord til login.

Relateret indhold

Kommentarer (23)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Poul-Henning Kamp Blogger

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...

  • 2
  • 0
Henrik Kramshøj Blogger

Helt enig.

Indenfor DNS er der også en "revolution" igang, på godt og ondt.

Grundet gamle standarder som er uhensigtsmæssige i det moderne internet, har man aftalt "flag days" - hvor større spillere aftalte at slå support for visse ting fra. Der var en i 2019 og en ny på vej i 2020.
https://dnsflagday.net/2020/

en anden pudsighed er at klienterne på vores internet idag er iPhones og andre mobile enheder med en ALT for kort levetid.

Så meget IT-skrald :-(

  • 2
  • 0
Troels Henriksen

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.

  • 11
  • 1
Henrik Størner

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 ...

  • 5
  • 0
Lasse Mølgaard

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.

  • 6
  • 1
Peter Holm Jensen

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.

  • 5
  • 0
Sidsel Jensen Blogger

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.

  • 11
  • 0
Kenn Nielsen

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

  • 0
  • 1
Anders Lorensen

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.

  • 4
  • 3
Anders Lind

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.

  • 3
  • 0
Torben Jensen

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.

  • 1
  • 0
Maciej Szeliga

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.

  • 1
  • 0
Christian Nobel

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.

  • 5
  • 0
Henrik Schack

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.

  • 0
  • 0
Henrik Schack

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.

  • 0
  • 0
Christian Nobel

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å.

  • 0
  • 0
Martin Storgaard Dieu

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.

  • 1
  • 0
Povl H. Pedersen

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.

  • 0
  • 1
Sidsel Jensen Blogger

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

  • 8
  • 0
Henrik Schack

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.

  • 3
  • 1
Gert Jürgensen

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. )

  • 4
  • 0
Log ind eller Opret konto for at kommentere
Job fra Jobfinder
Tip redaktionen