Datatilsynet: TLS er kun minimumskravet til kryptering af mails

Illustration: Jana Runde, Ruhr University Bochum/Electronic Frontier Foundation
Alle virksomheder, offentlige som private, skal have krypterede emails på TLS fra januar næste år, men yderligere kryptering kan også være påkrævet.

Fra januar næste år skærper Datatilsynet deres krav til email-kryptering og det betyder, at offentlige myndigheder og private virksomheder fremover skal sikre et højere krypteringsniveau af deres emails.

Der har dog både her på Version2s kommentarspor og på andre dele af nettet været forvirring omkring udmeldingen fra Datatilsynet, samt hvor og hvad, der konkret skal krypteres. Vi bad dem derfor specificere kravene.

»Den pressemeddelelse vi har sendt ud omhandler kryptering på transmissionslaget,« fortæller Allan Frank, der er it-sikkerhedsekspert og jurist hos Datatilsynet.

Læs også: Datatilsynet skærper praksis: Private virksomheder bør kryptere emails

TLS er ikke altid nok

Det er nemlig blevet så udbredt og så let at sætte op, at Datatilsynet mener, at alle virksomheder i Danmark som minimum skal have TLS kryptering, og at det som minimum skal være den næstnyeste version, TLS 1.2. Yderligere skal man tjekke mailserverens indstillinger og sørge for, at version 1.2 bliver brugt under hele transmissionen, da krypteringen ellers kan risikere at blive nedgraderet af en server, som ikke har denne version.

Det kan i værste fald resultere i såkaldte downgrade-angreb, hvor en angriber tvinger forbindelsen til at bruge en ældre protokol, som angriberen ved, hvordan man kan knække, hvorved krypteringen brydes.

Ingen garanti

At en mailserver har TLS betyder dog ikke, at man bare kan sende derudad. Det er som sagt kun udgangspunktet for email-sikkerhed, og sender man f.eks. fortrolige oplysninger og særlige kategorier af data, så skal man vurdere yderlige sikkerhedstiltag som f.eks. end-to-end kryptering.

»Det man skal huske på er, at GDPR forordningens artikel 32 siger, at den dataansvarlige skal sørge for, at der er passende sikkerhed, og der er jo en masse kriterier man skal afveje,« siger Frank.

Læs også: Kommuners ukrypterede mail-svipsere er ‘dybt ulovlige og tegn på umodenhed’

Det er en såkaldt risikobaseret tilgang til sikkerhed, men bare fordi forordningen ikke nævner en specifik form for kryptering, betyder det ikke at TLS nødvendigvis er nok alene.

En vægtet vurdering

»Når man foretager sin artikel 32 vurdering, om hvorvidt man har passende sikkerhed, så skal man stå med den registreredes rettigheder i den ene hånd og sine sikkerhedsmekanismer i den anden. Jo større risiko for den registrerede, jo mere sikkerhed skal man have,« fortæller Frank.

Til TLS kryptering anbefaler Datatilsynet, at man bruger en anerkendt standard såsom AES der er standarden for de offentlige myndigheder i USA. Til end-to-end kryptering anbefaler styrelsen PGP eller S/mime.

Lever man ikke op til kravet om TLS eller yderligere krypterings- eller sikkerhedsforanstaltninger risikerer man advarsler og bøde som udmålt i GDPR forordningen.

Redigeret d. 03/08-2018: Rettede en fejl i sidste afsnit, hvor det nu fremgår at Datatilsynet anbefaler AES til TLS kryptering og PGP og S/mime til end-to-end kryptering.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (53)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Mads Jensen

AES er symmetric crypto!

Man bruger Asymmetric crypto og PKI til kommunikations kanaler som e-mail.

Utrygt at IT-sikkerhedseksperter fra Datatilsynet ikke har en teknisk basisforståelse for det de arbejder med.

Det er "data at rest", de offentlige myndigheder i USA vil have krypteret med AES.

Det virker som man blot slynger TLS 1.2 og AES ud, uden at vide hvad det er.

og der er jo en masse kriterier man skal afveje,« siger Frank.

Med mindre din virksomhed lever af at sende ligegyldig spam ud vil TLS 1.2 aldrig være nok.

Når det så er sagt behøver I vidst ikke at frygte GDPR bøder fra Datatilsynet. Hvis I smider kommunikationen op på reddit er den TLS 1.2 krypteret. Alle kan læse den, men den opfylder minimumskravet til transmission ;-)

I rest my case!

  • 4
  • 2
Bjarne Nielsen

AES er symmetric crypto!

Man bruger Asymmetric crypto og PKI til kommunikations kanaler som e-mail.

Utrygt at IT-sikkerhedseksperter fra Datatilsynet ikke har en teknisk basisforståelse for det de arbejder med.

Hvad?

Fra Wikipedias (!) artikel om TLS:

The connection is private (or secure) because symmetric cryptography is used to encrypt the data transmitted. The keys for this symmetric encryption are generated uniquely for each connection and are based on a shared secret negotiated at the start of the session (see TLS handshake).

Der er flere gode grunde til, hvorfor man ikke udelukkende bruger asymmetriske algoritmer, men hurtigt bootstrapper ind i en symmetrisk.

Og TLS findes da også baseret på DES og 3-DES, hvilket er grunden til at der advares imod downgrade-attacks - se f.eks. https://sweet32.info/

I øvrigt så læser jeg klart Datatilsynet på den måde, at tilstrækkelig god TLS er en nødvendig, men næppe en tilstrækkelig betingelse. Mao. bruger du ikke god TLS, så gør du det helt sikkert forkert, men det er langt fra sikkert, at det er godt nok - det kommer helt an på situationen.

  • 10
  • 0
Jørn Wildt

Er der nogen som har et bud på hvordan det skal foregå i praksis? Jeg kan ikke regne ud hvordan hverken Hr og Fru Hakkebøf kan sætte PKI crypto op på deres mailkonto - eller hvordan en mindre virksomhed uden IT-kyndighed kan sætte deres mailkonto op til at sende krypteret? Altå "krypteret" som i "krypteret indhold - ikke kun forsendelse".

Yderligere har jeg ikke været i stand til finde ud af hvordan det kan gøres med fx gmail? Jeg kan kun se at gmail bruger TLS til forsendelse hvis muligt - men ikke noget om indholdskryptering.

Og, ja, jeg ved godt at gmail/webmail så bliver nød til at have adgang til den private nøgle for kryptering ;-) Men jeg vil forvente at den nøgle kun bruges til det ene formål - og gmail har alligevel 100% adgang til at sende på mine vejne. Så jeg kan ikke umiddelbart se et problem i det?

  • 2
  • 0
Bjarne Nielsen

Lad mig først understrege, at jeg er helt enig i, at det er på høje tid at få strammet op på sikkerheden ifm. kommunikation via email.

Men det er altså ingen silver-bullet. Jeg er ikke den eneste, som hedder Bjarne Nielsen, og jeg har også oplevet forbistringer med almindelig papirpost pga. af der var andre i mit daværende firma med mit navn (helt ærligt, kære forældre, kunne I ikke have gået til numerolog, da I fandt på mit navn?).

Så ja, kryptering vil hjælpe, hvis du har min nøgle og bruger den til at kryptere en besked til mig, som du efterfølgende sender til bni@example.org.

Men det hjælper altså ikke noget, hvis du slår nøglen op via bni@example.org i den tro, at det er mig. Og det er der rigtigt mange systemer, som gerne vil hjælpe dig med.

  • 3
  • 0
Bjarne Nielsen

Er der nogen som har et bud på hvordan det skal foregå i praksis?

Ikke nogen, som jeg ville kunne forklare min mor. Ah, måske netop lige min mor er en undtagelse, men du forstår, hvad jeg mener.

Og, ja, jeg ved godt at gmail/webmail så bliver nød til at have adgang til den private nøgle for kryptering ;-)

Ikke nødvendigvis. Det kan lade sig gøre at kryptere beskederne inden de bliver givet til Google. Og der findes også andre udbydere af webmail, som er gået væsentlig længere end Google.

Men det falder på at enten, så er der tale om isolerede løsninger, så man alle skal bruge samme udbyder, for at det virker, eller også er det simpelthen for besværligt (og desværre ofte begge dele).

Det er ikke klart, om det er opgave, som kan løses, men jeg kender da til eksempler på, at man prøver. Man er bare ikke nået i hus, hvis du spørger mig.

  • 0
  • 0
Bjarne Nielsen

Yderligere har jeg ikke været i stand til finde ud af hvordan det kan gøres med fx gmail?

Google og Gmail ligger nok på kanten af emnet for debatten her, så lad mig henvise til: https://www.wired.com/2017/02/3-years-gmails-end-end-encryption-still-va...

Efter min mening, så er de to væsentligste pointer her:

  • at det er sværere end man tror (og også sværere end google egne teknikere troede)
  • at der er parter med interesse i at opretholde status quo
  • 1
  • 0
Jan Nielsen

S/MIME er i princippet uafhængig af mailudbyder.
Hvis man kan tilgå sin mailkonto via IMAP eller POP og sende med SMTP - så er det mailklienten der afgør om man kan bruge S/MIME.
Gmail kan tilgås med IMAP med f.eks Thunderbird, Apple Mail eller Outlook

  • 3
  • 0
Jørn Wildt

S/MIME er i princippet uafhængig af mailudbyder.
Hvis man kan tilgå sin mailkonto via IMAP eller POP og sende med SMTP - så er det mailklienten der afgør om man kan bruge S/MIME.
Gmail kan tilgås med IMAP med f.eks Thunderbird, Apple Mail eller Outlook

Tak - og så behøver gmail ikke engang at kende dine nøgler. Men så kører du ikke længere en webbaseret klient. Jeg ledte efter en løsning som ikke tvinger slutbrugeren til at bruge en standalone non-web klient.

  • 2
  • 0
Bjarne Nielsen

... først nu så jeg at "s/mime" er hvad man skal søge efter - og fandt at G Suite faktisk understøtter det

For virksomheder. Ikke lige for private.

Og det er også en af de kløfter, som vi skal have krydset på en eller anden måde: PGP vs. S/MIME.

Privat-Bjarne bruger PGP, firma-Bjarne bruger S/MIME. Og det lader også til at være gældende for langt de fleste andre.

Bevares, privat-Bjarne kan godt forstå S/MIME, hvis du insisterer, men det bliver op ad bakke hele vejen. Og vice versa for firma-Bjarne. Og i høj grad af grunde, som kan føres tilbage til tradition og ideologi.

Jeg har ikke kigget dybt nok i de to formater til at kunne svare på, om det kun er formattering, eller om de er grundlæggende uenige. Og om der i det hele taget kunne etableres en del-mængde af de to, som ville kunne oversættes, hvis man vil det nok. Jeg tvivler som udgangspunkt.

  • 2
  • 0
Christian Nobel

Dybest set har jeg svært ved at se at det gør den helt store forskel, da end-to-end kryptering imo er den eneste rigtige måde at gøre det på - men det fordrer så lige at vi har en rigtig digital signatur, men den har Digitaliseringsforstyrrrelsen jo effektivt smidt ud med badevandet.

Nå men rent konkret, så må det åbenbart fordre at der skal installeres et certifikat på mailserveren, formoder at det kan klares vha. Let's Encrypt?

Men hvis vi så tager Postfix, skal vi så sætte "smtp_tls_security_level" lig "may" eller "encrypt"?

Hvis man skal vælge det sidste, så forudser jeg en masse bøvl i en lang overgangsperiode.

I øvrigt, tankevækkende kommentar på Postfix's hjemmeside:

"NOTE: By turning on TLS support in Postfix, you not only get the ability to encrypt mail and to authenticate remote SMTP clients or servers. You also turn on hundreds of thousands of lines of OpenSSL library code. Assuming that OpenSSL is written as carefully as Wietse's own code, every 1000 lines introduce one additional bug into Postfix. "

  • 2
  • 1
Lasse Mølgaard

You also turn on hundreds of thousands of lines of OpenSSL library code. Assuming that OpenSSL is written as carefully as Wietse's own code, every 1000 lines introduce one additional bug into Postfix.

Du er ikke tvunget til at bruge OpenSSL.

Der findes alternativer: LibreSSL (OpenBSD fork), BoringSSL (Googles fork), NSS (Mozillas implementation).

... men amatører får nok problemer med at bruge dem, frem for OpenSSL.

  • 2
  • 0
Christian Schmidt

Yderligere skal man tjekke mailserverens indstillinger og sørge for, at version 1.2 bliver brugt under hele transmissionen, da krypteringen ellers kan risikere at blive nedgraderet af en server, som ikke har denne version.

Dvs. Datatilsynet anbefaler, at man konfigurerer sin udgående postserver til kun at aflevere post via TLS? Jeg har ikke prøvet, men jeg gætter på, at man derved afskærer sig fra at aflevere post til visse modtagere med gamle e-mailservere. Det er selvfølgelig meget godt, hvis man typisk udsender e-mails med følsomt indhold, men det er til gengæld også træls, hvis man slet ikke kan sende en fødselsdagshilsen til en gammel ven, der benytter en gammel e-mailserver.

Men måske er det ikke store problem i praksis. Er der nogen her, der har erfaring med dette?

  • 0
  • 0
Claus Haulund

Tjaa, men man er nød til at sætte det op så der kan downgrades automatisk ellers kommer der vist ikke mange mail igennem mellem de danske virksomheder og offentligheder. Jeg mener Exchange 2016 gør følgende default:
Protocols Cipher Suite PFS Cipher/Strength
TLS1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384 Yes AES/256
TLS1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256 Yes AES/128
TLS1.0|1.1|1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384 Yes AES/256
TLS1.0|1.1|1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 Yes AES/128
TLS1.2 TLS_RSA_WITH_AES_256_CBC_SHA256 No AES256
TLS1.2 TLS_RSA_WITH_AES_128_CBC_SHA256 No AES128
TLS1.0|1.1|1.2 TLS_RSA_WITH_AES_256_CBC_SHA No AES/256
TLS1.0|1.1|1.2 TLS_RSA_WITH_AES_128_CBC_SHA No AES/128
TLS1.0|1.1|1.2 TLS_RSA_WITH_3DES_EDE_CBC_SHA No 3DES/192
TLS1.0|1.1|1.2 TLS_RSA_WITH_RC4_128_SHA No RC4/128

  • 2
  • 0
Christian Schmidt

Hvis man selv bestyrer en indgående postserver, bør man overveje at implementere DANE og/eller MTA-STS (som tidligere omtalt på Version2).

Herved signalerer du til omverden, at du er i stand til at modtage post via TLS, dvs. at afsenderen kan verificere, at de har hul igennem til rette server og ikke er udsat for et downgrade-angreb.

Det kræver selvfølgelig, at afsenderen understøtter dette, for at det skal have nogen effekt. Det er der ikke mange, der gør pt., så det er som med hønen og ægget. Dog har især MTA-STS vistnok opbakning fra Google og Microsoft, så mon ikke der sker noget på den front. Under alle omstændigheder skader det ikke noget at implementere disse standarder, dvs. de er fuldt bagudkompatible og falder blot tilbage til det nuværende lave sikkerhedsniveau, hvis ikke både afsender og modtager understøtter dem.

Desuden bør man implementere DMARC. Det har ikke noget med kryptering at gøre, men det forhindrer uvedkommende i at udføre phishing-angreb mod dine kontakter ved at afsende mails i dit navn.

  • 6
  • 0
Christian Nobel

Jeg savner stadig at mails bliver lavet efter en challenge-response model:

Jeg skal sende en mail til dig:

  1. Min mailserver kontakter din mailserver og siger der er en mail fra aa@mig til bb@dig.

  2. Din mailserver siger til min: fint, jeg vender tilbage.

  3. Din mailserver henvender sig til min mailserver efter DNS opslag.

  4. Din mailserver spørger min mailserver om den har en mail i kø fra aa@mig til bb@dig.

  5. Hvis det kan bekræftes, dvs. der dels findes en bruger aa på domænet mig, og der vitterlig er en mail i kø fra aa@mig til bb@dig, så beder din mailserver om mailen.

På den måde kan spammail elimineres, for der kan kun sendes mails fra en legitim server.

Derudover skal der selvfølgelig være end-to-end kryptering.

  • 4
  • 0
Tobias Tobiasen

Dvs. Datatilsynet anbefaler, at man konfigurerer sin udgående postserver til kun at aflevere post via TLS? Jeg har ikke prøvet, men jeg gætter på, at man derved afskærer sig fra at aflevere post til visse modtagere med gamle e-mailservere. Det er selvfølgelig meget godt, hvis man typisk udsender e-mails med følsomt indhold, men det er til gengæld også træls, hvis man slet ikke kan sende en fødselsdagshilsen til en gammel ven, der benytter en gammel e-mailserver.


Ja, det tænke jeg også. Hvis modtageren ikke har TLS på sin mailserver så kan afsenderen jo ikke sende med TLS.
Jeg har ikke talene men jeg tror der findes en del mail servere der enten ikke har TLS eller har selfsigned certifikater.
Så dem kan virksomheder ikke sende ikke følsomme mails til?

Så er der også problematikken om mail nogengange kommer gennem flere servere. Måske din mailserver sender den videre til din isp mailserver. Så er det svært at sikre sig at det næste hop bruger TLS. Men det må man så måske ikke mere?

Lad os håbe at den gode Allan Frank svarer ind i en kontekst af hvordan man sender mails med personfølsomme informationer og ikke alle mails.

  • 0
  • 0
Christian Nobel

Hvorfor ikke bare bruge SPF/DMARC?

Fordi den anden model vil være umådelig ukompliceret i forhold til SPF/DMARC, og det ikke indbefatter opsætninger i selve DNS siden, eller at det er "postbuddet" der skal checke identitet.

Jeg er stor tilhænger af man prøver at gøre tingene enkle, i stedet for at klistre lag på lag på (ligesom med "antivirus").

Hvis ikke brugeren aa er oprettet på det valide domæne mig, så hentes der simpelthen ikke nogen mail.

Det er enormt enkelt at implementere i selve serversoftwaren (jævnfør Wietse's rant), og enormt simpelt at opsætte (det kan faktisk være default ud af boksen).

Selvfølgelig vil det så udelukke enhver form for relaying, da der skal være en en-til-en forbindelse mellem afsendende og modtagende postserver, men det kan man da kun græde tørre tårer over.

Hvis der så af en eller anden uransagelig grund så kommer spam fra min server, så er den kompromitteret, men i og med den er helt kendt, så er det bare at dunke ejeren voldsomt i hovedet, eller blackliste domænet.

  • 2
  • 0
Christian Nobel

Så dem kan virksomheder ikke sende ikke følsomme mails til?

I en overgangsperiode, så burde Postfix's "may" vel være en løsning - det betyder så på den anden side at det faktisk slet ikke er nogen løsning.

Hønen og ægget - men typisk gratis omgang fra bureaukraterne.

Så er der også problematikken om mail nogengange kommer gennem flere servere. Måske din mailserver sender den videre til din isp mailserver. Så er det svært at sikre sig at det næste hop bruger TLS. Men det må man så måske ikke mere?

Relaying er et misfoster - hvis ens ISP ikke tillader at port 25 benyttes, så må man finde en ordentlig ISP i stedet.

  • 2
  • 0
Henrik Schack

Fordi den anden model vil være umådelig ukompliceret i forhold til SPF/DMARC, og det ikke indbefatter opsætninger i selve DNS siden, eller at det er "postbuddet" der skal checke identitet.


Ukompliceret? Der er sgu'itte noget ukompliceret i at lave grundlæggende om i måden hvorpå email fungerer :-) Det vil være en process der kommer til at tage mange år.
DMARC derimod kan i mange tilfælde implementeres på uger/dage, ja i nogle tilfælde på få timer.

  • 2
  • 0
Tobias Tobiasen

Jeg savner stadig at mails bliver lavet efter en challenge-response model:
...På den måde kan spammail elimineres, for der kan kun sendes mails fra en legitim server.


Ja, helt klart.
Men... problemet er at vi ikke er i 80erne og er ved at opfinde emails. Vi lever i en verden med mange mail servere der har mange forskellige features.
Så vi skal finde på en løsning der virker i en transition indtil alle er opdateret til den nye mere bedre måde. Jeg har svært ved at se hvordan transitionen skal ske med dit forslag? For hvis du begynder at gøre det i dag så får du ikke flere mails i lang tid.

Fordellen ved SPF er at det kan konfigureres i dag og har en effekt med det samme. Når/hvis det er udbredt nok så kan mail modtage vælge kun at modtage mails fra domæner med SPF records og vupti så får man mindre spam.

  • 1
  • 0
Christian Nobel

Ukompliceret? Der er sgu'itte noget ukompliceret i at lave grundlæggende om i måden hvorpå email fungerer :-)

Jeg taler om at selve metoden er umådelig ukompliceret.

At omstilling så ikke vil være det, fordi man har malet sig ind i krog fra forrige årtusinde er en helt anden sag.

Men ligesom med "may" fsva. TLS, så kunne man også implementere en tilsvarende metode i en overgangsperiode - og når der så er gået passende tid til at folk kan få nosset sig færdige kan man sætte tommelskruen på.

Det vil være en process der kommer til at tage mange år.

Så moralen er, at fordi en process vil tage mange år, så vil vi ikke gøre noget?

Hvis svenskerne havde haft samme slappe holdning, så ville de stadig køre i venstre side af vejen!

Og nåeh ja, IP-V6 det er jo osse en langvarig proces, så lad os hellere stikke strudsehovedet i jorden!

Det er fuldstændig ligesom software ellers - vi laver ikke ordentlig software mere, men benytter opulente frameworks, og klistrer lag på lag på lag ovenpå, så en "Hello World" fylder 50MB og er smækfyldt med fejl.

  • 3
  • 0
Christian Nobel

Vi lever i en verden med mange mail servere der har mange forskellige features.

Mailserverens features har ikke ret meget med selve forsendelsen af post at gøre.

Så vi skal finde på en løsning der virker i en transition indtil alle er opdateret til den nye mere bedre måde. Jeg har svært ved at se hvordan transitionen skal ske med dit forslag?

Det kunne være ved at afsendende mailserver spørger modtager om han respekter c-r.

Hvis det er en gammel mailserver, så vil den bare svare med et "huh?" og så leveres mailen.

På den modtagende side kan man checke om afsender har sendt en c-r forespørgsel, og så kan man jo når tilstrækkelig mange er kommet med på vognen sige at man ikke vil modtage noget fra mailservere der ikke spørger om c-r.

Hvis bare man kan få lokket de store (MS, Google, et al) til at implementere det, så kan det komme forholdsmæssigt hurtigt på plads - selve pachen til mailserveren vil være minimal.

Fordellen ved SPF er at det kan konfigureres i dag og har en effekt med det samme. Når/hvis det er udbredt nok så kan mail modtage vælge kun at modtage mails fra domæner med SPF records og vupti så får man mindre spam.

Nu er SPF jo så absolut også den letteste del, men der skal jo så også klistres DKIM/DMARC plus nu også DANE og MTA-STS ovenpå.

  • 3
  • 0
Henrik Schack

Så moralen er, at fordi en process vil tage mange år, så vil vi ikke gøre noget?


Nej jeg tænker mere, vi har brug for nogle ændringer nu. Standarderne ligger klar, og venter blot på folk kommer igang.
SPF kunne være et godt sted at starte, der eksisterer omkring 1,3 millioner DK domæner, ca. 1 million af dem har ikke nogen SPF record.
datatilsynet.dk er iøvrigt et af dem :-)

En ny standard for email starter ikke ved at "få lokket nogle af de store med" den starter på ietf.org ligesom alle andre Internet standarder.

  • 2
  • 0
Tobias Tobiasen

TLS not enforced.

De her virker også fint:
SSLVersion in use: TLSv1
SSLVersion in use: TLSv1.1

Melder Datatilsynet til sig selv til Politiet eller hvordan foregår det? ;-)

Kravet er at afsender sørger for at der bliver brugt TLSv1.2. Så det er ikke Datatilsynet der overtræder reglerne. Men måske må virksomheder ikke længere sende mails til Datatilsynet....

  • 1
  • 0
Niels Danielsen

Hvordan skal reglerne for personfølsomt følsomt information fortolkes?
Skal afsender sikre sig at data ikke havner noget sted 'at rest' som ikke overholder GDPR (medmindre det er modtagerens private system?).
Selv om mail sendes som PGP eller S/MIME er der ikke nogen sikkerhed for at (web) mail systemet i den anden ende har adgang til kundes private nøgle, og/eller ikke overholder GDPR.
Det betyder vel i praksis at man som afsender skal have en white list over mail udbydere som overholder GDPR, eller hvor det kun er modtageren der har den private nøgle?
Det gør det svært at anvende alm. PGP email, og vi er låst til e-Boks...

  • 0
  • 0
Jan Nielsen

Selv om mail sendes som PGP eller S/MIME er der ikke nogen sikkerhed for at (web) mail systemet i den anden ende har adgang til kundes private nøgle, og/eller ikke overholder GDPR.
Det betyder vel i praksis at man som afsender skal have en white list over mail udbydere som overholder GDPR, eller hvor det kun er modtageren der har den private nøgle?

Den bedste metode er nok at modtageren sender en mail, som de signerer med deres offentlige nøgle.
Hvis de kan signere, kan de nok også læse en krypteret mail. Desuden sikrer du dig at det er den nøgle folk helst vil anvende til kryptering (man kan jo sagtens have forskellige nøgler til samme email)
Mht. whitelist kan man slå op i den Offentlige certifikatdatabase
Her skal man bare være opmærksom på at private borgere kan have aktiveret deres certifikat, men ikke har det installeret på deres mail-klient

  • 0
  • 0
Hans Nielsen

Måske delvis løsning ? https://tutanota.com/da/ hvor privat livet er en grundlæggende menneskeret, beskyttet af grundloven.

Det er forholdsvis simple, men kræver selvfølge at begge parter har det for at virke optimalt.
Men du kan sende en mail krypteret, også til andre der ikke bruger tutanota. Man skal så inden have udvekslet en fælles nøgle.

Men det virker og det er enkelt at bruge som privat også selv om man ikke er nørd.
Det findes også en virksomhedsløsning, den kender jeg ikke.
Tror også man med fordel kan vælge det tyske Domain, i forhold til databeskyttelse.

Disclaimer. Har intet at køre med tutanota, men har doneret på grund af deres idealistisk tilgang . Og synes at kampen for en ret til privatliv også på nettet er værd at hjælp.

Join us in our fight for privacy!
In the future Tutanota will be our replacement for Gmail with a calendar, notes, cloud storage - everything encrypted by default! This is our dream of the future Internet and we are truly amazed by the feedback and the support we have received from you so far. We invite all of you to get in touch and to support our goal in bringing privacy and security to the world. It's really easy.

  • 0
  • 0
Niels Danielsen

Den bedste metode er nok at modtageren sender en mail, som de signerer med deres offentlige nøgle.
Hvis de kan signere, kan de nok også læse en krypteret mail. Desuden sikrer du dig at det er den nøgle folk helst vil anvende til kryptering (man kan jo sagtens have forskellige nøgler til samme email)


Det beskytter ikke imod at modtageren bruger et system der er usikkert.. (Folk vil gerne havde det nemt og billigt)
En mail udbyder (feks. google) kan implementere et system hvor udbyderen hjælper med at 'sikre' at den private nøgle ikke tabes.
Det betyder at krypterede mails der ligger på serveren f.eks. kan bruges til målrettede reklamer..(og andet..)
Det at en mail er PGP krypteret betyder ikke at det kun er modtageren der kan læse mailen.
ProtonMail virker ret gennemtænkt, og sikkerheden ligger i det java script der køre i browseren. Men hvis ProtonMail bliver overtaget af en bad actor, så skal der kun ændres få linier client kode for at de får adgang til alle mails ved næste login.
https://tonyarcieri.com/whats-wrong-with-webcrypto

  • 0
  • 0
Jan Nielsen

Det beskytter ikke imod at modtageren bruger et system der er usikkert.. (Folk vil gerne havde det nemt og billigt)
En mail udbyder (feks. google) kan implementere et system hvor udbyderen hjælper med at 'sikre' at den private nøgle ikke tabes.

At uploade sin private nøgle til en mail-udbyder (findes der sådan nogle "services"?) er vel lidt det samme som at lægge sin hoveddørsnøgle under måtten.
Man kunne også finde på andre eksempler på usikkerheder, f.eks. at overdrage sin egen nøgle og adgangskode til sekretæren eller sin samlever.
Det er vel det samme som at give en anden fuldmagt til at optræde på egne vegne.
- Men det kan afsenderen jo ikke være ansvarlig for.
Det er straks værre med den praksis mange organisationer har med at have en fælles offentlig emailadresse til sikkerpost. Her aner man jo ikke, hvem der læser mailen. Det kan f.eks. være studentermedhjælperen, eller praktikanten, der har fået overdraget funktionen som internt "postbud".
Men eksemplet rejser en parallel problematik, nemlig at den almindelige borger er meget lidt sikkerhedsbevidst.
Jeg synes dog at GDPR har hjulpet en del på bevidstheden i organisationerne
- men der skal nok rulle nogle hoveder før det rigtigt rykker ;-)

  • 0
  • 0
Christian Hansen

At Datatilsynet pludseligt har fået en holdning til spørgsmålet.

Jeg har for et par år siden prøvet at få et svar på hvad “sikker mail” praksis bestod af og om fx, TLS ville være “sikkert nok”. Det var på det tidspunkt ikke muligt at få et skriftligt svar på med et argument i at teknologier jo ændre sig og de ikke ville give et bindende svar..

At der så stadigvæk er masser af issues med at bruge tvungen kryptering på SMTP forbindelser er en hel anden snak.

  • 1
  • 0
Nicolai Rasmussen

Er der nogen som har et bud på hvordan det skal foregå i praksis?

1) Eksproprier post.dk fra post-nord.
2) Opret en offentligt ejet gmail-lignende service til alle danskere.
3) auto-opret alle borgere i dk med personnummer@post.dk
4) lad alle brugerne oprette (flere) alias'er efter eget ønske, dog med begrænsninger efter noget almindelig (smags)dommer-halløj (f.eks. nej til <minoritet>-er-dumme@post.dk).
5) bloker alle ikke-godkendte private og offentlige aktører fra at sende til personnummer@post.dk.
6) lav en stenhård data-smiley ordning på gdpr området for private og offentlige aktører og myndigheder. Ordningen skal være designet, anerkendt og respekteret af dygtige sikkerhedseksperter og gdpr specialister. For bærende konstruktioner i byggebranchen har man en statsanerkendt "statiker ordning". Der bliver man statsanerkendt statiker efter at have bestået en prøve (som skal gentages løbende). På samme måde kunne man lave en statsanerkendt GDPR og sikkerhedsordning. Disse anerkendte personer kunne så løbende inspicere og godkende data-installationer til smiley ordningen.
7) hvis man har elite-data-smiley i 2 år (8 perfekte inspektioner i træk), så får man privilegier, som f.eks. mulighed for at sende direkte til personnummer@post.dk (så må man håbe at politi, domstole og skat kan opretholde denne elite smiley).
8) Man sørger for at installere en tilstrækkelig "tls" + hvad-ellers-der-kræves på post.dk og Hr og Fru Frikadelle skal ikke forholde sig til noget som helst. Når de skriver til deres tante i usa, så er det almindelig åben og usikker mail (som alle andre almindelige emails), og når man skriver med det offentlige + andre der lever op til kravene til sikker infrastruktur, så er det sikkert.
9) man tvinger alle offentlige institutioner og aktører over på post.dk - for de har demonstreret at de ikke kan finde ud af at drifte deres eget.
10) lad løsningen være åben og baseret på opensource, så andre kan forbedre og drifte konkurrerende og interfacende løsninger.
11) over tid vil der komme alle mulige løsninger, som "egen" nøgle kryptering, og alle mulige former for valgfri interfacing med paranoia plugins.

E-boks burde have været den rette løsning, men den er for dårlig for brugeren - og alt for lukket. F.eks. har jeg post fra Roskilde Bank, der ikke længere kan tilgås, fordi de er krypteret med en Roskilde Bank BEC løsning, der stoppede dengang Roskilde bank blev splittet op efter konkursen (WTF???) - så hvis man ikke var aktiv og få printet eller "pdf'et" sin post, så mistede man adgangen permanent. Er det min post? Tilsyneladende ikke!

Ovenstående forslag ville formentlig ende med det samme resultat - for ringe løsning, for dårligt driftet, ikke opensource fordi blablabla. osv osv...

  • 1
  • 1
Mads Jensen

Hahahaha, det sjoveste indlæg!

3) auto-opret alle borgere i dk med personnummer@post.dk

Hver gang du sender en e-mail, offentligør du dit personnummer til modtageren.

Desuden er e-mail adressen ALDRIG krypteret.

Du offentligør dermed dit personnummer hver eneste gang du sender eller modtager en e-mail. Ikke blot til modtageren, men alle "mellemled".

Hver gang en offentlig eller privat virksomhed sender e-mail personnummer@post.dk overtræder de GDPR. Bare selvangivelsen fra SKAT er 5.5 mio. brud :-)

  • 2
  • 0
Claus Eriksen

SPF og DMARC er lige til højrebenet - desværre er der mange, selv folk der udbyder DNS som ikke fatter de restriktioner der er i antal DNS opslag i SPF, og giver deres kunder dårlige råd.

10 opslag - og ikke et eneste mere - hvor svært kan det være? benyt evt. dmarcian.com og mxtoolbox.com som hjælp til at verificere at denne limit ikke brydes.

  • 0
  • 0
Henrik Schack

SPF og DMARC er lige til højrebenet - desværre er der mange, selv folk der udbyder DNS som ikke fatter de restriktioner der er i antal DNS opslag i SPF, og giver deres kunder dårlige råd.


Det er det ja, men utroligt mange får blandet SPF og SenderId sammen.
Selv hos et firma som MailChimp skriver man konsekvent SPF hver gang man skulle have skrevet SenderId

  • 0
  • 0
Lasse Mølgaard

Det ændrer sådan set ikke det generelle i Wietse's kommentar, al den stund alternativerne nok heller ikke lige er skrevet med 5 linjers kode.

Men en af de ting folk brokker sig over med OpenSSL er at koden er noget hø!

Så vidt jeg husker blev LibreSSL forken til fordi de ville rydde op i kodebasen. OpenSSL er nemlig blevet til et patchwork af slamkode og grimme hacks.

Resultatet af dette er at LibreSSL folkene har slettet tusindvis af linjer kode.

Der var en af udviklerne der ligefrem lavede en blog hvor han kom med diverse udbrud, når han stødte på særdeles dårlig kode. Detsværre kan jeg ikke finde linket til den blog. :-/

  • 0
  • 0
Allan Bang Tanggaard

Datatilsynet har omkring regler og anbefalinger denne hjemmeside som forklare det ganske enkelt.

De fleste virksomheder behøver ikke End-to-end kryptering, hvis indhold kun omfatter Almindelige Personoplysninger.

Almindelige Personoplysninger indeholder følgende;

Væsentlige sociale problemer, andre rent private
forhold, økonomi, skat, gæld, sygedage, tjenstlige forhold,
familieforhold, bolig, bil, eksamen, ansøgning, CV,
ansættelsesdato, stilling, arbejdsområde,
arbejdstelefon, navn, adresse, fødselsdato,

Link til datatilsynet omkring E-mail kryptering

https://www.datatilsynet.dk/emner/persondatasikkerhed/transmission-af-pe...

Link til datatilsynet omkring hvilken kategori man befinder sig i (PDF - Side7)

https://www.datatilsynet.dk/media/6559/generel-informationspjece-om-data...

  • 0
  • 0
Log ind eller Opret konto for at kommentere