Dom:

To eller flere navneservere på dit domæne har en IPv6-adresse.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om dit domænenavn har mindst to navneservere med en IPv6- adresse.

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

Dom:

Alle navneservere, der har en IPv6-adresse, kan nås via IPv6.

Testforklaring:

Vi kontrollerer, om alle navneservere, der har en AAAA-record med IPv6-adresse kan nås via IPv6.

Du skal kontakte den navneserveransvarlige (forhandler/hostingudbyder) for ændringer vedrørende IPv6.

Dom:

Dit domæne tilbyder HTTPS.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om dit websted kan nås via HTTPS.

I så fald kontrollerer vi også i nedenstående deltests, om HTTPS er konfigureret tilstrækkeligt sikkert i overensstemmelse med 'IT Security Guidelines for Transport Layer Security (TLS)' fra NCSC-NL.

HTTPS garanterer fortroligheden og integriteten af ​​de udvekslede oplysninger. Fordi det afhænger af situationen, hvor (fortrolighed) følsomme og værdifulde oplysninger er, er en sikker HTTPS-konfiguration vigtig for hvert websted. Selv trivielle, offentlige oplysninger kan være ekstremt følsomme og værdifulde for en bruger. Bemærk: Af hensyn til ydeevnen kører HTTPS-testafsnittet kun for den første tilgængelige IPv6- og IPv4-adresse.

Du skal kontakte den webserveransvarlige (forhandler/hostingudbyder)

Dom:

Din webserver omdirigerer automatisk besøgende fra ukrypteret HTTP til en krypteret HTTPS-forbindelse på det samme domæne.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om din webserver automatisk omdirigerer besøgende fra HTTP til HTTPS på det samme domæne (gennem en 301/302-omdirigering), eller om den kun understøtter HTTPS og ikke til HTTP.

I tilfælde af omdirigering skal et domæne først opgradere sig selv ved at omdirigere til sin HTTPS-version, før det kan omdirigere til et andet domæne. Dette sikrer også, at HSTS-politikken accepteres af webbrowseren. Eksempler på korrekt omdirigeringsrækkefølge:

• http://eksempel.dk ⇒ https://eksempel.dk ⇒ https://www.eksempel.dk
• http://www.eksempel.dk ⇒ https://www.eksempel.dk

Du skal kontakte den webserveransvarlige for domænet for ændringer i HTTPS-omdirigering.

Dom:

Din webserver understøtter kun sikre TLS-versioner.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om din webserver udelukkende understøtter sikre TLS-versioner.

En webserver understøtter muligvis mere end en TLS-version.

Bemærk: Browserudviklere har annonceret, at de vil stoppe med at understøtte TLS 1.1 og 1.0 inden Q1 2021. Dette vil medføre, at websteder, der ikke understøtter TLS 1.2 og / eller 1.3, ikke kan nås.

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

---

• God: TLS 1.3 og 1.2
• Udfasning: TLS 1.1 og 1.0
• Utilstrækkelig: SSL 3.0, 2.0 samt 1.0

Du skal kontakte den webserveransvarlige (forhandler/hostingudbyder)

Dom:

Din webserver understøtter kun sikre ciphers.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om din webserver kun understøtter sikre cipher (algoritmevalg).

Et algoritmevalg består af ciphers til fire kryptografiske funktioner: 1) nøgleudveksling, 2) certifikatbekræftelse, 3) massekryptering og 4) hashing. En webserver understøtter muligvis mere end et algoritmevalg.

• Siden TLS 1.3 omfatter udtrykket 'cipher suite' kun ciphers, der bruges til bulk kryptering og hashing. Når du bruger TLS 1.3, er ciphers til nøgleudveksling og certifikatverifikation 'negotiable' og er ikke en del af navngivningen af ​​krypteringssuiten. Da 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 valg af algoritmer. Sikkerpånettet.dk benytter OpenSSL naming convention. Da Siden TLS 1.3 følger OpenSSL IANAs navnekonventionen. 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 ​​NCSC-NL foreskrevne rækkefølge, baseret på bilag C til 'IT Security Guidelines for Transport Layer Security (TLS)'. Bag hvert algoritmevalg er den minimale TLS-version (f.eks. [1.2]), der understøtter dette algoritmevalg, og det er som minimum 'Udfasning'.

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 den webserveransvarlige (forhandler/hostingudbyder)

Dom:

Din webserver håndhæver sin egen cipher-indstilling ('I') og tilbyder ciphers i overensstemmelse med den foreskrevne rækkefølge ('II').

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om din webserver håndhæver sin egen cipher-indstilling ('I') og tilbyder ciphers i overensstemmelse med den foreskrevne rækkefølge ('II').

Hvis din webserver kun understøtter 'gode' ciphers, er denne test ikke anvendelig, da rækkefølgen ikke har nogen væsentlig sikkerhedsfordel.

I. Servertvunget cipher-indstilling: Webserveren håndhæver sin egen cipher-indstilling, mens den forhandler med en webbrowser og accepterer ikke nogen indstilling fra webbrowseren. (Påkrævet);

II. Foreskrevet rækkefølge: Ciphers tilbydes af webserveren i overensstemmelse med nedenstående rækkefølge, hvor sikre og hurtige krypteringer foretrækkes.

A. 'God' foretrækkes fremfor 'Tilstrækkelig' som foretrækkes over 'udfasning' ciphers (Påkrævet);

B. Fortsæt som følger inden for et givet 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 cifre, 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øglelængde og derefter hashstørrelse (Anbefalet);
5. AES-256 foretrækkes fremfor 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 den webserveransvarlige (forhandler/hostingudbyder)

Dom:

Din webserver understøtter en sikker hash-funktion til nøgleudveksling.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om din webserver understøtter sikre hash-funktioner for at oprette den digitale signatur under nøgleudveksling.

Webserveren bruger en digital signatur under nøgleudvekslingen for at bevise ejerskab af den hemmelige nøgle, der svarer til certifikatet. Webserveren 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 af signature

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

Du skal kontakte den webserveransvarlige (forhandler/hostingudbyder)

Dom:

Din webserver understøtter ikke TLS-komprimering, hvilket er godt, da det øger sikkerheden.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om din webserver understøtter TLS-komprimering.

Brug af komprimering kan give en hacker information om de hemmelige dele af krypteret kommunikation. En hacker, der kan 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 ikke er et problem.

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

Du skal kontakte den webserveransvarlige (forhandler/hostingudbyder)

Dom:

Din webserver understøtter sikker genforhandling.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om din webserver 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 opdateret, og der blev tilføjet en sikrere genforhandlingsmekanisme. Denne ældre version tillader usikker genforhandling og bør deaktiveres.

Læs "Sikker brug af Transport Layer Security (TLS)" fra Center for Cybersikkerhed, se oversigten i bilaget. Hvis genforhandling er slået helt fra, vil testen fejle. Dette er ikke et udtryk for at parameteren er usikkert konfigureret

Du skal kontakte den webserveransvarlige (forhandler/hostingudbyder)

Dom:

Din webserver tillader ikke klientinitieret genforhandling, hvilket er godt, da det øger sikkerheden.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om en klient (normalt en webbrowser) kan indlede en genforhandling med din webserver.

Det er generelt ikke nødvendigt at tillade klienter at starte genforhandling og åbner en webserver for DoS-angreb inde i en TLS-forbindelse. En hacker kan udføre lignende DoS-angreb uden klientinitieret genforhandling ved at åbne mange parallelle TLS-forbindelser, men disse er lettere at opdage og forsvare sig mod ved hjælp af standardafbrydelser. 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.

Du skal kontakte den webserveransvarlige (forhandler/hostingudbyder)

Dom:

Din webserver understøtter ikke 0-RTT, hvilket er godt, da det øger sikkerheden.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om din webserver understøtter Zero Round Trip Time Resumption (0-RTT).

0-RTT er en mulighed i TLS 1.3, der transporterer applikationsdata i løbet af den første meddelelse med håndtrykket. 0-RTT yder ikke beskyttelse 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 ofte ikke triviel, afhængig af applikationslogik og er derfor tilbøjelig for fejl.

Hvis din webserver ikke understøtter TLS 1.3, er testen ikke relevant. For webservere, der understøtter TLS 1.3, er indeks / siden på webstedet hentet ved hjælp af TLS 1.3 og mængden af tidlige data support angivet af serveren er kontrolleret. Hvis det er mere end nul, oprettes en ny forbindelse med de modtagne TLS-detaljer fra den første forbindelse, men HTTP forespørgslen sendes inden TLS håndtrykket (dvs. uden frem-og-tilbage (0-RTT). Når TLS-håndtrykket er afsluttet og webserveren svarer med alt andet end et HTTP 425 for tidligt svar, 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 den webserveransvarlige (forhandler/hostingudbyder)

Dom:

Tillidskæden på dit webstedscertifikat er komplet og signeret af en betroet rodcertifikatmyndighed.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om vi er i stand til at opbygge en gyldig tillidskæde til dit webstedscertifikat.

For en gyldig tillidskæde skal dit certifikat offentliggøres af en offentligt betroet certifikatautoritet, og din webserver skal præsentere alle nødvendige mellemliggende certifikater.

Du skal kontakte den webserveransvarlige (forhandler/hostingudbyder)

Dom:

Den digitale signatur på dit webstedscertifikat bruger sikre parametre.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om den (ECDSA eller RSA) digitale signatur på dit webstedscertifikat benytter sikre parametre.

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

Sikkerheden ved ECDSA digitale signaturer afhænger af den valgte kurve. Sikkerheden ved RSA til kryptering og digitale signaturer er bundet til nøglelængden på den offentlige nøgle.

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 den webserveransvarlige (forhandler/hostingudbyder)

Dom:

Dit webstedscertifikat er signeret ved hjælp af en sikker hash-algoritme.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om det signerede fingeraftryk fra webstedscertifikatet 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 den webserveransvarlige (forhandler/hostingudbyder)

Dom:

Dit websteds domænenavn matcher domænenavnet på dit websted-certifikat.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om dit websteds domænenavn matcher domænenavnet på certifikatet.

Det kan være nyttigt at medtage mere end et domæne (f.eks. domænet med og uden www) som alternativt navn på certifikatet.

Du skal kontakte den webserveransvarlige (forhandler/hostingudbyder)

Dom:

Din webserver tilbyder indstillinger for X-Content-Type-muligheder.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om din webserver leverer en HTTP-header til 'X-Content-Type'. Med denne HTTP-header giver du webbrowsere besked om, at de ikke må udføre "MIME-type sniffing" og altid følge "Content-Type" som erklæret af din webserver. Den eneste gyldige værdi for denne HTTP-overskrift er 'nosniff'. Når det er aktiveret, blokerer en browser anmodninger om 'style' og 'script', når de ikke har en tilsvarende 'Content-Type' (dvs. 'tekst / css' eller en 'JavaScript MIME-type' som 'applikation / javascript').

'MIME-type sniffing' er en teknik, hvor browseren scanner indholdet af en fil for at detektere formatet på en fil uanset den erklærede' Content-Type 'af webserveren. Denne teknik er sårbar over for det såkaldte 'MIME confusion attack', hvor angriberen manipulerer indholdet af en fil på en måde, så den behandles af browseren som en anden 'Content-Type', som en eksekverbar.

Anbefalet

Du skal kontakte den webserveransvarlige (forhandler/hostingudbyder)