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:

Mindst en af ​​dine webservere har en IPv6-adresse.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om der er mindst en AAAA-record med IPv6-adresse til din webserver.

Du skal kontakte den webserveransvarlige (ofte din forhandler der hoster) for ændringer i IPv6

Dom:

Alle dine webservere med en IPv6-adresse kan nås via IPv6.

Testforklaring:

Vi kontrollerer, om vi kan oprette forbindelse til din webserver(r) via IPv6 på alle tilgængelige porte (80 og/eller 443). Vi tester alle IPv6-adresser, som vi modtager fra din navneservere. En delvis score gives, hvis ikke alle IPv6-adresser er tilgængelige. Hvis en IPv6-adresse er (syntaktisk) ugyldig, betragter vi den som ikke tilgængelig.

Du skal kontakte den webserveransvarlige (forhandler/hostingudbyder)

Dom:

Dit websted på IPv6 ser ud til at være det samme som dit websted på IPv4.

Testforklaring:

Vi sammenligner det webindhold, som vi modtager fra din webserver over såvel IPv6 som IPv4 på alle tilgængelige porte (80 og/eller 443). I tilfælde af at der er flere IPv6- og IPv4-adresser, vælger vi én IPv6- og én IPv4-adresse Hvis indholdsforskellen ikke er overskrider 10%, forventer vi, at det vigtigste webindhold skal være det samme. Derfor vil hjemmesider med små forskelle (for eksempel på grund af skiftende annoncer) også bestå denne undertest.

Du skal kontakte den webserveransvarlige (forhandler/hostingudbyder)

Dom:

Dit domæne er DNSSEC-signeret.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om dit domæne er DNSSEC-signeret.

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 deltest være negativt.

Bemærk: Gyldigheden af signatur er ikke en del af denne delprøve, men en del af den efterfølgende.

Du skal kontakte den navneserveransvarlige (forhandler/hostingudbyder)

Dom:

Dit domæne er sikkert, fordi dets DNSSEC-signatur er gyldig.

Tekniske detaljer:

Testforklaring:

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

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

Du skal kontakte den navneserveransvarlige (forhandler/hostingudbyder)

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 ikke HTTP-komprimering, komprimering, hvilket er godt, da det øger sikkerheden.

Tekniske detaljer:

Testforklaring:

Vi tester, om din webserver understøtter HTTP-komprimering.

HTTP-komprimering gør den sikre forbindelse til din webserver sårbar over for BREACH-angrebet. HTTP-komprimering bruges dog ofte til at gøre mere effektiv brug af tilgængelig båndbredde. Hvis du vælger at bruge HTTP-komprimering, skal du kontrollere, om det er muligt at afbøde relaterede angreb på applikationsniveau. Et eksempel på en sådan foranstaltning er at begrænse, i hvilket omfang en hacker kan påvirke svaret fra en server.

Denne deltest kontrollerer, om webserveren understøtter HTTP-komprimering på rodmappeniveau. Der kontrollerer dog ikke yderligere webstedskilder som billeder og scripts.

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

Valgfri

Du skal kontakte den webserveransvarlige (forhandler/hostingudbyder)

Dom:

Din webserver tilbyder en HSTS-politik.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om din webserver understøtter HSTS.

Browsere husker HSTS pr. (under) domæne. Hvis du ikke tilføjer et HSTS-overskrift til hvert (under) domæne (i en omdirigeringskæde), kan brugerne blive sårbare over for man-in-the-middle -angreb. Derfor kontrollerer vi for HSTS ved den første kontakt, dvs. før enhver omdirigering.

HSTS tvinger en webbrowser til at oprette forbindelse direkte via HTTPS, når du besøger et websitet igen. Dette hjælper med at forhindre man-in-the-middle -angreb. Vi anser en gyldighedsperiode for HSTS-cache ('max-age') på mindst seks måneder for at være tilstrækkelig sikker. En lang periode er gavnlig, fordi den også beskytter brugere der sjældent er på websitet. Hvis du vil stoppe med at understøtte HTTPS, bliver du nødt til at vente længere, indtil gyldigheden af HSTS-politikken i alle browsere, der har besøgt dit websted, er udløbet.

Du skal kontakte den webserveransvarlige (forhandler/hostingudbyder)

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:

Denne undertest er ikke anvendelig, da din webserver kun understøtter 'gode' ciphers.

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 sikre parametre til Diffie-Hellman-nøgleudveksling.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om de offentlige parametre, der bruges i Diffie-Hellman-nøgleudveksling af din webserver, er sikre.

Sikkerheden ved Diffie-Hellman (ECDHE)’s elliptisk kurve til kortvarig nøgleudveksling afhænger af den anvendte elliptiske kurve. Vi kontrollerer, om bitlængden af de anvendte elliptiske kurver som minimum er 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 'utilstrækkelige'.

De større nøglestørrelser, der kræves til brug af DHE, påvirker ydelsen. 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 åbne RSA-parametre testes i undertesten 'Åbne nøgle til certifikat'. Bemærk, at RSA betragtes som 'good' til certifikatverifikation.

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

---

Elliptisk kurve til ECDHE

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

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

Tilstrækkelig: Alle andre grupper

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:

Din webserver understøtter stapling af OCSP, og dataene i svaret er gyldige.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om din webserver understøtter TLS Certificate Status extension også kendt som OCSP stapling.

Webbrowseren kan verificere gyldigheden af ​​det certifikat, der præsenteres af webserveren, ved at kontakte certifikatautoriteten ved hjælp af OCSP-protokollen. OCSP giver en certifikatautoritet oplysninger om browsere, der kommunikerer til webserveren: dette kan være en privacy-risiko. En webserver kan også levere OCSP-svar til webbrowsere selv gennem OCSP-stapling. Dette løser denne privacy-risiko, kræver ikke forbindelse mellem webbrowser og certifikatautoritet og er hurtigere.

Når vi opretter forbindelse til din webserver, bruger vi TLS Certificate Status extension til at anmode om, at OCSP-data inkluderes i serversvaret. Hvis din webserver inkluderer OCSP-data i svaret, verificerer vi derefter, at OCSP-dataene er gyldige, dvs. korrekt underskrevet af en kendt certifikatautoritet. Bemærk: Vi bruger ikke OCSP-data til at evaluere certifikatets gyldighed.

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

---

OCSP stapling

• God: Til
• Tilstrækkelig: Fra

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 sikkert konfigurerede X-Frame-indstillinger.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om din webserver leverer en HTTP-header til 'X-Frame-Options', der har en tilstrækkelig sikker konfiguration. Med denne HTTP-overskrift lader du browsere vide, om du vil tillade, at dit websted bliver framet eller ej. Forebyggelse af framing forsvarer besøgende mod angreb som clickjacking. Vi anser følgende værdier for at være tilstrækkeligt sikre:

• DENY (framing ikke tilladt);
• SAMEORIGIN (kun framing fra eget website tilladt); or
• ALLOW-FROM https://sikkerpånettet.dk/ (tillad kun, at bestemte websteder kan frame dit websted).

Content-Security-Policy (CSP) tilbyder lignende beskyttelse for besøgende med moderne webbrowsere. Imidlertid kan 'X-Frame-Options' stadig beskytte besøgende på ældre webbrowsere, der ikke understøtter CSP. Desuden kan 'X-Frame-Options' tilbyde værdifuld beskyttelse for alle besøgende, når CSP ikke er (korrekt) konfigureret til det pågældende websted.

Anbefalet

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)

Dom:

Din webserver tilbyder CSP (Content-Security-Policy).

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om din webserver leverer en HTTP-header til 'Content-Security-Policy' (CSP). CSP beskytter et websted mod cross-site scripting (XSS) angreb. Ved at white liste kilder til godkendt indhold med CSP forhindrer du browsere i at indlæse ondsindet indhold fra angribere. I øjeblikket vurderer vi ikke effekten af ​​CSP-konfigurationen. Vi foreslår dog at:

• bruge HTTP-overskriften til 'Content-Security-Policy-Only-Report' til at eksperimentere med CSP-politikker ved at overvåge deres effekter uden at håndhæve disse effekter;

• benyt frame-ancestors for at forhindre, at websiden indlæses i en frame;

• indstil en politik med 'default-src' for at have en reserve for andre ressource-typer, når de ikke har deres egen sikkerhedspolitik;

• vær forsigtig med unsafe-inline og data:, fordi de aktiverer XSS-angreb;

• benyt https:// når en URL bruges til at henvise til en kilde.

Valgfri

Du skal kontakte den webserveransvarlige (forhandler/hostingudbyder)

Dom:

Din webserver tilbyder Referrer-Policy.

Tekniske detaljer:

Testforklaring:

Vi kontrollerer, om din webserver leverer en HTTP-header til 'Referrer-Policy'. Med denne HTTP-overskrift lader du browsere vide, hvilke henvisnings oplysninger, der sendes i Referer-overskriften, skal være en del af webstedsanmodningen. Overskriften Referer indeholder adressen på den forrige webside, hvorfra den besøgende fulgte et link til den ønskede side

Oplysningerne i Referer-overskriften bruges mest til analyse og logning. Der kan dog være privatlivs- og sikkerhedsrisici. Oplysningerne kunne bruges f.eks. til brugersporing, og oplysningerne kan lækkes til tredjepart, der aflytter forbindelsen. Med HTTP-overskriften til 'Referrer-Policy' kan du afbøde disse risici.

I øjeblikket vurderer vi ikke effekten af ​​den konfigurerede 'Referrer-Policy' -værdi. Vi foreslår dog at tage en informeret beslutning med tanke på privatlivs- og sikkerhedsrisici om at bruge en af ​​politikværdierne fra de to første kategorier nedenfor.

Anbefalede policy values:

1. Ingen følsomme data til tredjepart

   • no-referrer
   • same-origin

2. Følsomme data til tredjepart kun via sikre forbindelser (HTTPS)

   • strict-origin
   • strict-origin-when-cross-origin

Ikke-anbefalede policy values:

1. Følsomme data til tredjepart muligvis via usikre forbindelser (HTTP)
   • no-referrer-when-downgrade (browsers' default policy)
   • origin-when-cross-origin
   • origin
   • unsafe-url

Anbefalet

Du skal kontakte den webserveransvarlige (forhandler/hostingudbyder)