Dom:

E-maildomænet er DNSSEC-signeret.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om dit domæne er DNSSEC-signeret. Med en DNSSEC-signatur kan afsendere, der validerer domænesignaturer, verificere ægtheden af det DNS-svar, der indeholder dine mailserverdomæner (MX). Dette forhindrer en hacker i at manipulere DNS-svaret for at omdirigere mails sendt til dig til angriberens mailserver-domæne.

Hvis et domæne omdirigerer til et andet domæne via CNAME, kontrollerer vi også, om domænet som CNAME peger på er underskrevet (hvilket er i overensstemmelse med DNSSEC-standarden). Hvis domænet som CNAME peger på ikke er underskrevet, vil resultatet af denne subtest være negativt.

Bemærk: signaturens gyldighed er ikke en del af denne subtest, men en del af den næste.

Du skal kontakte den navneserveransvarlige (forhandler/hostingudbyder) for ændringer vedr. DNSSEC

Bemærk: der kan være to forskellige domænenavne og dermed forskellige ansvarlige

Dom:

Domænenavnet for din e-mailadresse er sikkert, fordi DNSSEC-signaturen er gyldig.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om dit domæne er signeret med en gyldig signatur, hvilket gør det 'sikkert'.

Hvis et domæne omdirigerer til et andet signeret domæne via 'CNAME', kontrollerer vi også, om signaturen til domænet som CNAME peger på er gyldig (hvilket er i overensstemmelse med DNSSEC-standarden). Hvis signaturen til domænet som CNAME peger på ikke er gyldig, vil resultatet af denne delundersøgelse være negativt.

Du skal kontakte den navneserveransvarlige (forhandler/hostingudbyder) vedrørende ændringer DNSSEC

Dom:

Alle e-mailserver-domæner er DNSSEC-signeret.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om domænerne knyttet til dine postservere (MX) er DNSSEC-signeret. Med en DNSSEC-signatur kan afsendere, der validerer domænesignaturer, verificere ægtheden af DNS-svaret, der indeholder IP-adresserne og DANE-records for din mailserver(e). Dette forhindrer en angriber i at manipulere DNS-svaret for at omdirigere mails, der er sendt til dig, til en IP-adresse, der kontrolleres af angriberen, eller for at aflytte den sikre postserverforbindelse.

Hvis et domæne omdirigerer til et andet domæne via CNAME, kontrollerer vi også, om domænet som CNAME peger på er signeret (hvilket er i overensstemmelse med DNSSEC-standarden). Hvis domænet som CNAME peger på ikke er signeret, vil resultatet af denne delundersøgelse være negativt.

Bemærk: signaturens gyldighed er ikke en del af denne delundersøgelse, men en del af den næste.

Du skal kontakte den navneserveransvarlige (forhandler/hostingudbyder) vedrørende ændringer DNSSEC

Dom:

Alle dine signerede e-mailserverdomæner er sikre, fordi deres DNSSEC-signaturer er valide.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om domænerne til dine modtagende mailservere (MX) er signeret med en gyldig signatur, hvilket gør dem 'sikre'.

Hvis et domæne omdirigerer til et andet signeret domæne via 'CNAME', kontrollerer vi også, om signaturen til domænet som CNAME peger på er gyldig (hvilket er i overensstemmelse med DNSSEC-standarden). Hvis signaturen til domænet som CNAME peger på ikke er gyldig, vil resultatet af denne delundersøgelse være negativt.

Du skal kontakte den navneserveransvarlige (forhandler/hostingudbyder) vedrørende ændringer DNSSEC

Dom:

Dit domæne har en DMARC-record.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om DMARC er tilgængeligt for dit domæne. En modtagende mailserver kan muligvis bruge din DMARC-politik til at evaluere, hvordan man håndterer en mail med dit domæne som afsender, der ikke kunne godkendes med både DKIM og SPF, og den kan bruge din e-mailadresse fra DMARC-record til at give feedbackrapporter godkendelsen til dig. At have mere end en DMARC-post i det samme domæne er ikke gyldigt og vil føre til en testfejl. Bemærk: DMARC kræver at SPF- domænet (afsender på konvolutten, dvs. Return Path, der vises i MAIL FROM) og DKIM-domænet (d =) til at passe afsenderdomænet (Fra:).

Læs guiderne Reducer risikoen for falske mails og Falske mails fra passive domæner fra Center for Cybersikkerhed.

Du skal starte med at kontakte din e-mailudbyder (forhandler/hostingudbyder) vedr. ægthedsmærker mod phishing

Dom:

Dit domæne understøtter DKIM-records.

Testforklaring:

Vi kontrollerer, om dit domæne understøtter DKIM records. En modtagende mailserver kan bruge den offentlige nøgle i din DKIM-record til at validere signaturen i en e-mail fra en bruger med dit domæne som afsender og bestemmer dens ægthed.

• I øjeblikket kan vi ikke evaluere den offentlige nøgle i din DKIM-record, fordi vi har brug for DKIM-selector’en (det skal være i de e-mails, du sender) for at gøre det.
• For at bestå denne test forventer vi, at din navneserver svarer 'NOERROR' på vores forespørgsel på_domainkey.eksempel.nl '. Hvis _domainkey.eksempel.dk er en 'Empty Non- terminal', svarer visse navneservere, ikke i overensstemmelse med standarden RFC2308, forkert med 'NXDOMAIN' i stedet for 'NOERROR'. Dette gør det umuligt for os at detektere support til DKIM-records.
• Til denne test antager vi 'strict alignment', som er i overensstemmelse med DMARC-standarden. Det givne domæne anses for at være afsenderdomænet i e-mail-adressen fra selve mailen (Fra:), og dette skal være identisk med DKIM-domænet (d=) og SPF-domænet (afsenderadresse på konvolutten, dvs. ’Return Path’, som vises i ’MAIL FROM’).

Læs guiderne Reducer risikoen for falske mails og Falske mails fra passive domæner fra Center for Cybersikkerhed.

Du skal starte med at kontakte din e-mailudbyder (forhandler/hostingudbyder) vedr. ægthedsmærker mod phishing

Dom:

Dit domæne har SPF-record.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om dit domæne har en SPF-record. En modtagende mailserver kan bruge dine whitelistede afsendelses-mailservere og den medfølgende policy fra din SPF-record til at bestemme ægtheden af en modtaget e-mail med dit domæne som afsender. At have mere end én SPF-record i det samme domæne er ikke gyldigt og vil føre til en testfejl.

Læs guiderne Reducer risikoen for falske mails og Falske mails fra passive domæner fra Center for Cybersikkerhed.

Du skal starte med at kontakte din e-mailudbyder (forhandler/hostingudbyder) vedr. ægthedsmærker mod phishing

Dom:

Din SPF-politik er tilstrækkelig sikker.

Testforklaring:

Vi kontrollerer, om syntaks af din SPF-record er korrekt, og om den indeholder en tilstrækkelig streng policy, dvs. ~all (softfail) eller-all (hardfail) for at forhindre misbrug fra phishere og spammere. For at være effektiv mod misbrug af dit domæne er en liberal policy, dvs. +all (pass) eller ’?all(neutral) utilstrækkelig. Hvis ’all’ mangler, og der ikke er en ’rederect’ -modifikation ikke er til stede i din SPF-record, er standardindstillingen?all`.

Vi medtager også 'include' og 'redirect'-henvisning for udarbejdelse af engyldige SPF-record. Højst 10 DNS-opslag er tilladt, i denne sammenhæng. Hvis include eller redirect domænet består af makroer, vil vi ikke inkludere dem, da vi ikke har de nødvendige oplysninger fra en faktisk mail- eller postserverforbindelse til at udvide disse makroer. Bemærk, at vi anbefaler, at du indstiller den mest stringente policy ('-all') for (sub-) domæner, som du ikke bruger til at sende e-mails for at forhindre misbrug.

Læs guiderne Reducer risikoen for falske mails og Falske mails fra passive domæner fra Center for Cybersikkerhed.

Du skal starte med at kontakte din e-mailudbyder (forhandler/hostingudbyder) vedr. ægthedsmærker mod phishing

Dom:

Alle dine e-mailservere tilbyder STARTTLS.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om dine modtagende e-mailservere (MX) understøtter STARTTLS.

I så fald kontrollerer vi også i nedenstående undertests, om STARTTLS er konfigureret tilstrækkeligt sikkert. Hvis der ikke er defineret nogen e-mailserver, giver vi en notifikation, og vi udfører andre undertests af e-mailtesten, der stadig har relevans.

Bemærk: Af hensyn til kapaciteten er maksimalt ti mailservere over enten IPv6 eller IPv4 kontrolleret i STARTTLS-testkategorien.

Du skal kontakte din e-mailudbyder (forhandler/hostingudbyder) vedrørende TLS

Dom:

Alle dine e-mailservere understøtter sikre TLS-versioner

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om dine e-mailservere (MX) udelukkende understøtter sikre TLS-versioner.

En e-mailserver understøtter muligvis mere end én TLS-version.

Bemærk: Nogle e-mailservere understøtter kun ældre TLS-versioner. Hvis både den afsendende og modtagende e-mailserver ikke understøtter den samme TLS-version, falder de normalt tilbage til ikke-krypterede forbindelser. På grund af det kan det anbefales at fortsætte med at understøtte TLS-versioner med en 'udfasning' status i et stykke tid. Lav en informeret beslutning baseret på logdata om, hvornår disse 'udfasning' TLS-versioner skal deaktiveres.

Læs "Sikker brug af Transport Layer Security (TLS)" fra Center for Cybersikkerhed, se oversigten i bilaget.

---

• Good: TLS 1.3 and 1.2
• Udfasning: TLS 1.1 and 1.0
• Utilstrækkelig: SSL 3.0, 2.0 and 1.0

Du skal kontakte din e-mailudbyder (forhandler/hostingudbyder) vedrørende TLS

Dom:

Alle dine e-mailservere understøtter sikre ciphers.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om dine modtagende e-mailservere (MX) udelukkende understøtter sikre ciphers (algoritmevalg). For at forhindre os i at løbe ind i kapaciteten for modtagende e-mailservere indeholder testresultatet kun de først fundne berørte algoritmevalg.

Et algoritmevalg består af ciphers til fire kryptografiske funktioner: 1) nøgleudveksling, 2) certifikatverifikation, 3) bulk kryptering og 4) hashing. En webserver kan understøtte mere end et algoritmevalg.

• Siden lanceringen af TLS 1.3, omfatter udtrykket 'cipher suite' kun ciphers, der bruges til bulk kryptering og hashing. Når du bruger TLS 1.3, kan ciphers til nøgleudveksling og certifikatverifikation forhandles og er ikke en del af navngivningen af cipher-pakken. Fordi dette gør udtrykket 'cipher suite' tvetydigt, bruger NCSC-NL udtrykket 'algoritmevalg' til at omfatte alle fire cipher-funktioner.

• NCSC-NL benytter IANA naming convention til algoritmevalg. Sikkerpånettet.dk benytter OpenSSL naming convention, der er i overensstemmelse med IANA naming convention. En oversættelse mellem begge kan findes i OpenSSL-dokumentationen.

Læs "Sikker brug af Transport Layer Security (TLS)" fra Center for Cybersikkerhed, se oversigten i bilaget.

---

” Nedenfor finder du 'God', 'Tilstrækkelig' og 'Udfasning' algoritmevalg i den af Center for Cybersikkerhed foreskrevne rækkefølge, baseret på bilaget til Sikker brug af Transport Layer Security (TLS)

God:

• ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
• ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
• ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
• ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
• ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
• ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Tilstrækkelig:

• ECDHE-ECDSA-AES256-SHA384 [1.2]
• ECDHE-ECDSA-AES256-SHA [1.0]
• ECDHE-ECDSA-AES128-SHA256 [1.2]
• ECDHE-ECDSA-AES128-SHA [1.0]
• ECDHE-RSA-AES256-SHA384 [1.2]
• ECDHE-RSA-AES256-SHA [1.0]
• ECDHE-RSA-AES128-SHA256 [1.2]
• ECDHE-RSA-AES128-SHA [1.0]
• DHE-RSA-AES256-GCM-SHA384 [1.2]
• DHE-RSA-CHACHA20-POLY1305 [1.2]
• DHE-RSA-AES128-GCM-SHA256 [1.2]
• DHE-RSA-AES256-SHA256 [1.2]
• DHE-RSA-AES256-SHA [1.0]
• DHE-RSA-AES128-SHA256 [1.2]
• DHE-RSA-AES128-SHA [1.0]

Udfasning:

• ECDHE-ECDSA-DES-CBC3-SHA [1.0]
• ECDHE-RSA-DES-CBC3-SHA [1.0]
• DHE-RSA-DES-CBC3-SHA [1.0]
• AES256-GCM-SHA384 [1.2]
• AES128-GCM-SHA256 [1.2]
• AES256-SHA256 [1.2]
• AES256-SHA [1.0]
• AES128-SHA256 [1.2]
• AES128-SHA [1.0]
• DES-CBC3-SHA [1.0]

Du skal kontakte din e-mailudbyder (forhandler/hostingudbyder) vedrørende TLS

Dom:

Alle dine e-mailservere håndhæver egene cipher-præference ('I'), og tilbyde ciphers i overensstemmelse med den foreskrevne rækkefølge ('II').

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om dine modtagende e-mailservere (MX) håndhæver egen krypteringsalgoritme ('I'), og tilbyder kryptering i overensstemmelse med den foreskrevne rækkefølge ('II').

Hvis dine e-mailservere udelukkende understøtter "Gode" krypteringsalgoritmer, er denne test overflødig, da rækkefølgen ikke påvirker sikkerheden betydeligt.

I. Server fastsatte cipher-indstillinger: De modtagende mailservere håndhæver deres egen cipher-indstilling, mens de forhandler med afsendende mailservere, og accepterer ikke nogen præference for de afsendende mailservere. (Påkrævet);

II. Foreslået rækkefølge: Ciphers udbydes af den modtagende mailserver i overensstemmelse med nedenstående rækkefølge, hvor sikre og hurtige krypteringer foretrækkes.

A. Foretrækker 'God' fremfor 'Tilstrækkelig' fremfor 'Udfasning' ciphers (Påkrævet);

B. Fortsæt som følgende inden for et givent sikkerhedsniveau:

1. Ciphers der udfører nøgleudveksling baseret på elliptiske kurver, foretrækkes frem for dem, der bruger begrænsede felter. Begge foretrækkes frem for ciphers, der bruger en statisk nøgleudveksling (Anbefalet);
2. Ciphers der foretager bulk-kryptering baseret på AEAD-algoritmer, foretrækkes frem for alternativer (Anbefalet);
3. Ciphers der udfører certifikatverifikation baseret på ECDSA, foretrækkes frem for RSA (Anbefalet);
4. Ciphers foretrækkes i faldende rækkefølge efter deres nøgle- og derefter hash-størrelse (Anbefalet);
5. AES-256 fortrækkes frem for ChaCha20 (Valgfri).

I ovenstående tabel med tekniske detaljer er kun den først fejl der vises med den overtrådte rækkefølge vist ved siden af.

Læs "Sikker brug af Transport Layer Security (TLS)" fra Center for Cybersikkerhed, se oversigten i bilaget.

Du skal kontakte din e-mailudbyder (forhandler/hostingudbyder)

Dom:

Alle dine mailservere understøtter sikre parametre til Diffie-Hellman nøgleudveksling.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om de offentlige parametre, der bruges i Diffie-Hellman-nøgleudveksling af dine modtagende e-mailservere (MX), er sikre.

Sikkerheden ved elliptisk kurve Diffie-Hellman (ECDHE) kortvarige nøgleudveksling afhænger af den anvendte elliptiske kurve. Vi kontrollerer, om bitlængden af ​​de anvendte elliptiske kurver er mindst 224 bit. I øjeblikket er vi ikke i stand til at kontrollere navnet på den elliptiske kurve.

Sikkerheden ved Diffie-Hellman Ephemeral (DHE) nøgleudveksling afhænger af længderne på de offentlige og private nøgler, der bruges inden for den valgte begrænsede feltgruppe. Vi tester, om dit DHE-offentlige nøglemateriale bruger en af ​​de foruddefinerede begrænsede feltgrupper, der er specificeret i RFC 7919. Selvgenererede grupper er 'Insufficient'.

De større nøglestørrelser, der kræves til brug af DHE, kommer med en omkostning. Evaluer omhyggeligt og brug ECDHE frem for DHE, hvis du kan.

Udover ECDHE og DHE kan RSA bruges til nøgleudveksling. Det risikerer dog at blive utilstrækkeligt sikkert (nuværende status 'udfasning'). De offentlige RSA-parametre testes i undertesten 'Offentlig nøgle til certifikat'. Bemærk, at RSA betragtes som 'god' til certifikatverifikation.

Læs "Sikker brug af Transport Layer Security (TLS)" fra Center for Cybersikkerhed, se oversigten i bilaget.

---

Elliptisk kurve for ECDHE

• God: secp384r1, secp256r1, x448, and x25519
• Udfasning: secp224r1
• Utilstrækkelig: alle andre

Begrænsede feltgruppe til DHE

Tilstrækkelig:

• ffdhe4096 (RFC 7919)
  sha256 checksum: 64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3

• ffdhe3072 (RFC 7919)
  sha256 checksum: c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab

Udfasning:

• ffdhe2048 (RFC 7919)
  sha256 checksum: 9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b

Utilstrækkelig: alle andre grupper

Du skal kontakte din e-mailudbyder (forhandler/hostingudbyder)

Dom:

Alle dine e-mailservere understøtter sikre hash-funktioner til nøgleudveksling.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om dine modtagende e-mailservere (MX) understøtter sikre hash-funktioner for at oprette den digitale signatur under nøgleudveksling.

En modtagende e-mailserver bruger en digital signatur under nøgleudvekslingen for at bevise ejerskab af den hemmelige nøgle svarende til certifikatet. E-mailserveren opretter denne digitale signatur ved at underskrive output fra en hash-funktion.

Læs "Sikker brug af Transport Layer Security (TLS)" fra Center for Cybersikkerhed, se oversigten i bilaget.

Anbefalet

---

SHA2-understøttelse til underskrifter

• God: Ja (SHA-256, SHA-384 eller SHA-512 er understøttet)
• Udfasning: Nej (SHA-256, SHA-384 of SHA-512 ikke understøttet)

Du skal kontakte din e-mailudbyder (forhandler/hostingudbyder)

Dom:

Ingen af dine e-mailservere understøtter TLS-komprimering.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om dine modtagende e-mailservere (MX) understøtter TLS-komprimering.

Brug af komprimering kan give en hacker information om de hemmelige dele af krypteret kommunikation. En hacker, der kan bestemme eller kontrollere dele af de sendte data, kan rekonstruere de originale data ved at udføre et stort antal anmodninger. TLS-komprimering bruges så sjældent, at deaktivering af det generelt ikke er et problem.

Læs "Sikker brug af Transport Layer Security (TLS)" fra Center for Cybersikkerhed, se oversigten i bilaget.

Du skal kontakte din e-mailudbyder (forhandler/hostingudbyder)

Dom:

Alle dine e-mailservere understøtter sikker genforhandling.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om dine e-mailservere (MX) understøtter sikker genforhandling.

Ældre versioner af TLS (før TLS 1.3) giver mulighed for at tvinge et nyt håndtryk. Denne såkaldte genforhandling var usikker i sit oprindelige design. Standarden blev opgraderet, og der blev tilføjet en sikrere genforhandlingsmekanisme. Den ældre version tillader usikker genforhandling og bør deaktiveres.

Hvis genforhandling er slået helt fra, vil testen fejle. Dette er ikke et udtryk for at parameteren er usikkert konfigureret.

Læs "Sikker brug af Transport Layer Security (TLS)" fra Center for Cybersikkerhed, se oversigten i bilaget.

Du skal kontakte din e-mailudbyder (forhandler/hostingudbyder)

Dom:

Ingen af dine e-mailservere tillader klientinitieret genforhandling.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om en afsendende e-mailserver kan indlede en genforhandling med dine modtagende e-mailservere (MX).

Tilladelse til at afsendende e-mailservere kan starte genforhandling er generelt ikke nødvendigt og åbner en modtagende e-mailserver for DoS-angreb via en TLS-forbindelse. En hacker kan udføre lignende DoS-angreb uden klient-initieret genforhandling ved at åbne mange parallelle TLS-forbindelser, men disse er lettere at opdage og forsvare sig mod ved hjælp af kendte mitigeringsteknikker. Bemærk, at klientinitieret genforhandling påvirker tilgængelighed og ikke fortrolighed

Læs "Sikker brug af Transport Layer Security (TLS)" fra Center for Cybersikkerhed, se oversigten i bilaget.

Anbefalet

Du skal kontakte din e-mailudbyder (forhandler/hostingudbyder)

Dom:

Denne undertest gælder ikke, da dine e-mailservere ikke understøtter TLS 1.3.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om dine e-mailservere (MX) understøtter Zero Round Trip Time Resumption (0-RTT).

0-RTT er en mulighed i TLS 1.3, der transporterer applikationsdata applikationsdata i løbet af den første meddelelse med håndtrykket. 0-RTT yder ikke beskyttelse mod mod gentagelsesangreb på TLS-laget og bør derfor deaktiveres. Selvom risikoen kan mindskes ved ikke at tillade 0-RTT for ikke-idempotente anmodninger, er en sådan konfiguration ikke triviel, afhængig af applikationslogik og er derfor tilbøjelig til at fejle.

Hvis dine e-mailservere ikke understøtter TLS 1.3, er testen ikke relevant. For e-mailservere, der understøtter TLS 1.3, udstedes STARTTLS-kommandoen og en TLS session påbegyndes. Mængden af early data understøttelse angivet ved e-mailserver er markeret. Hvis det er mere end nul, oprettes en ny forbindelse med de modtagne TLS-detaljer fra den første forbindelse, men med EHLO-kommando _ før_ TLS-håndtrykket, men efter STARTTLS-kommandoen (dvs. ingen round trip (0-RTT) Når TLS-håndtrykket er afsluttet og e-mailserveren svarer, anses webserveren for at understøtte 0-RTT. Læs "Sikker brug af Transport Layer Security (TLS)" fra Center for Cybersikkerhed, se oversigten i bilaget.

Du skal kontakte din e-mailudbyder (forhandler/hostingudbyder)

Dom:

Tillidskæden for alle dine e-mailservercertifikater er komplette og signeret af en betroet myndighed for rodcertifikater.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om vi er i stand til at opbygge en gyldig tillidskæde til dine e-mailservercertifikater.

En tillidskæde er kun gyldig når dit certifikat offentliggøres af en [publicly trusted certifikatautoritet] (https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/), og din modtagende e-mailserver skal kunne fremvise alle nødvendige mellemliggende certifikater.

E-mailservere der er afsendere ignorerer normalt, om et e-mailservercertifikat udstedes af en publicly trusted certifikatautoritet. Uden DNSSEC er opslaget for e-mailserverdomænet sårbart over for manipulation. Således kan et certifikat udstedt af en publicly trusted certifikatautoritet ikke øge autenticitetsværdien. Mange modtagende e-mailservere bruger derfor selvsignerede certifikater, ofte udstedt af en intern (privat) certifikatautoritet. For optimal autenticitet bør en e-mailserver benytte DNSSEC og DANE.

Valgfri

Du skal kontakte din e-mailudbyder (forhandler/hostingudbyder)

Dom:

De digitale signaturer til dine e-mailservercertifikater benytter sikre parametre.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om de digitale signaturer (ECDSA eller RSA) på dine e-mailservercertifikater benytter sikre parametre.

Verificeringen af certifikater benytter digitale signaturer. For at garantere ægtheden af en forbindelse skal en pålidelig algoritme til certifikatverifikation benyttes. Algoritmen, der bruges til at signere et certifikat, vælges af leverandøren. Certifikatet specificerer algoritmen til digitale signaturer, der benyttes under nøgleudvekslingen. Det er muligt at konfigurere flere certifikater for at understøtte mere end en algoritme.

Sikkerheden ved ECDSA digitale signaturer afhænger af den valgte kurve. RSA's sikkerhed for kryptering og digitale signaturer er knyttet til den offentlige nøgles længde.

Læs "Sikker brug af Transport Layer Security (TLS)" fra Center for Cybersikkerhed, se oversigten i bilaget.

---

Elliptiske kurver til ECDSA

• God: secp384r1, secp256r1, x448, and x25519
• Udfasning: secp224r1
• Utilstrækkelig: Other curves

Længde på RSA-nøgler

• God: At least 3072 bit
• Tilstrækkelig: 2048 – 3071 bit
• Utilstrækkelig: Less than 2048 bit

Du skal kontakte din e-mailudbyder (forhandler/hostingudbyder)

Dom:

Alle dine e-mailservercertifikater er signeret med en sikker hash-algoritme.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om det signerede fingerprint til alle dine e-mailservercertifikater blev oprettet med en sikker hashing-algoritme.

Læs "Sikker brug af Transport Layer Security (TLS)" fra Center for Cybersikkerhed, se oversigten i bilaget.

---

Hash-funktioner til bekræftelse af certifikat

• God: SHA-512, SHA-384, SHA-256
• Utilstrækkelig: SHA-1, MD5

Du skal kontakte din e-mailudbyder (forhandler/hostingudbyder)

Dom:

Domænenavne til alle dine e-mailservere svarer til domænenavnene på dine certifikater.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om domænenavnet tilknyttet dine modtagende e-mailservere (MX) svarer til domænenavnet på de eksisterende certifikater.

Afsendende e-mailservere ignorerer normalt domænet i certifikatet. Uden DNSSEC er opslaget af e-mailserverdomænet sårbart over for manipulation. Matching af domænet på certifikatet til e-mailserverdomænet forøger derfor ikke autenticitetsværdien. Mange modtagende e-mailservere bruger derfor selvsignerede certifikater, ofte udstedt af en intern (privat) certifikatautoritet.

E-mailservere bør bruge DNSSEC og DANE til autencitet. Et certifikat med et domæne, der svarer til e-mailserverens domæne, er kun påkrævet, når DANE 'trust anchor assertion' (DANE-TA, 2) bruges.

Læs "Sikker brug af Transport Layer Security (TLS)" fra Center for Cybersikkerhed, se oversigten i bilaget.

Valgfri / Påkrævet (kun hvis DANE-TA benyttes)

Du skal kontakte din e-mailudbyder (forhandler/hostingudbyder)

Dom:

Alle dine e-mailserverdomæner giver en TLSA-record for DANE.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om navneserverne på hver af dine modtagende e-mailservere (MX) har en TLSA-record for DANE.

Da DNSSEC er en forudsætning for DANE, vil denne test mislykkes, hvis DNSSEC mangler på e-mailserverdomænet(erne)

Desuden vil testen føre til en fejl, hvis der ikke er nogen DNSSEC-bevis for 'Denial of Existence' for TLSA records. Hvis der findes en signeret TLSA-record, men på samme tid er der en usikker NXDOMAIN for det samme domæne (på grund af defekt signerings-software), viser testen også en fejl. De to sidstnævnte fejlscenarier kan føre til manglende levering af e-mails adresseret til dig fra DANE-validerede afsendere.

Læs "Sikker brug af Transport Layer Security (TLS)" fra Center for Cybersikkerhed, se oversigten i bilaget.

Du skal starte med at kontakte din e-mailudbyder (forhandler/hostingudbyder)

Dom:

DANE-fingerprints på dine e-mailserverdomæner er gyldige for alle dine e-mailservercertifikater.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om de DANE-fingerprints, der præsenteres af dine e-mailserverdomæner, er gyldige for dine e-mailservercertifikater.

DANE giver dig mulighed for at offentliggøre oplysninger om dine e-mailservercertifikater i en særlig DNS-record, kaldet TLSA-record. Afsendende e-mailservere kan kontrollere ægtheden af dine certifikater, ikke kun gennem certifikatautoriteten, men også gennem TLSA-records. En afsendende e-mailserver kan også bruge TLSA-records som et signal til udelukkende at oprette forbindelse via STARTTLS (og ikke ukrypteret). Når DANE-fingerprint’et fra en modtagende e-mailserver kontrolleres af den afsendende e-mailserver, kan en aktiv angriber, der er i stand til at manipulere e-mails, ikke fjerne STARTTLS-kryptering.

Du skal starte med at kontakte din e-mailudbyder (forhandler/hostingudbyder)

Dom:

Alle dine e-mailserverdomæner har en aktivt DANE-ordning til en pålidelig overførsel af certifikatnøgler.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer om DANE er forberedt til at kunne skifte certifikater på din e-mailserver (MX) på en sikker måde.

En sådan ordning vil være nyttig, når der er behov for at opdatere dine e-mailservercertifikater. Det kan forbygge, at DANE bliver ugyldig i overgangsperioden, hvilket kan blokere for muligheden for at sende e-mails fra dit domæne. En sådan rollover-ordning forventes ikke at være 'aktiv' hele tiden.

Nedenfor finder du to mulige DANE-rollover-procedurer (kilde: slides af Viktor Dukhovni). I hver procedure skal der være to DANE TLSA-records, som kontrolleres af denne delprøve.

Valgfri

---

DANE rollover-procedurer

1. Nuværende + Næste

• Generer næste nøgle, når du tager nuværende nøgle og certifikat i brug.

• Implementere ny kæde, og udgiv nye TLSA-records:

• _25._tcp.mx.example.com. IN TLSA 3 1 1 curr-pubkey-sha256

• _25._tcp.mx.example.com. IN TLSA 3 1 1 next-pubkey-sha256

• Flere uger senere genererer du certifikatet med den nye nøgle, og udskifter certifikatet på din mailserver.

• Sørg dog først for at, TLSA-recorden er på plads

• Gentag ved næste rollover!

2. Nuværende + Udsteder CA

• Offentliggør TLSA-records for dine server-nøgler og for udsteder af CA-nøgle:

• _25._tcp.mx.example.com. IN TLSA 3 1 1 ee-pubkey-sha256

• _25._tcp.mx.example.com. IN TLSA 2 1 1 ta-pubkey-sha256

• Hvis du implementerer certifikater fra samme CA og kun ændrer nøglen til servercertifikaten, også kaldt end entity (EE)-nøglen:

• Du kan blot opdatere 3 1 1 hash’en med den nye EE-nøgle.

• Hvis du udskifter din CA nøgle, også kaldt Trust Authority (TA)-nøgle, kan du beholde din EE nøgle.

• Indhent certifikat fra den nye CA

• Opdater 2 1 1 hash for at matche den nye CA-nøgle

Du skal starte med at kontakte din e-mailudbyder (forhandler/hostingudbyder)