TLS-handshake: Hvorfor din sikkerhedsgrundsten er vigtigere, end du tror

Når du skriver en URL i browseren, sker der masser bagved. Før data overhovedet bevæger sig, danser browser og server en hemmelig krypto-dans. Det tager få millisekunder. Men det afgør, om din forbindelse er sikker. Det er TLS-handshake.

Hos NameOcean mener vi, at udviklere og infra-teams skal kende det her grundigt. Ikke kun for at blive bedre ingeniører. Fejl i TLS-opsætningen kan udsætte brugere for fare – og give compliance-problemer, der koster penge og tid.

Hvad sker der egentlig i handshake?

Client starter HTTPS-forbindelsen. Den siger til serveren: "Jeg vil have sikker snak. Her er mine protokoller, cipher suites og evner." Serveren svarer: "Okay, vi tager TLS 1.3 med den her suite. Her er mit certifikat som bevis."

TLS 1.3 gør det hele i én tur frem og tilbage. TLS 1.2 kræver to. Begge er hurtige, men TLS 1.3 sparer tid – perfekt til god UX.

Handshaken laver midlertidige session-nøgler. De krypterer samtalen og smides væk bagefter. Det hedder forward secrecy. Selv hvis nogen knækker din private nøgle i morgen, kan de ikke læse i dagens chats.

Versionsproblemet: TLS 1.2 er minimum – men 1.3 er fremtiden

Mange servere kører stadig TLS 1.0 eller 1.1. De er gamle og kneppede af angreb som BEAST og POODLE. Alle browsere har droppet dem. PCI DSS, HIPAA og SOC 2 forbyder dem også.

Legacy-systemer hænger med. Accepterer du gamle versioner? Så risikerer du hacks og manglende audits.

Anbefaling: TLS 1.2 med stærke cipher suites som minimum. TLS 1.3 er det bedste. Den har fjernet alt det gamle skrammel, der laver fejl. Med 1.3 går det næsten ikke galt.

Cipher suites: Vælg den rigtige kryptering

Når version er valgt, kommer cipher suite – hvordan I krypterer. Her går det ofte galt i opsætningen.

TLS 1.3 har faste, stærke suites. Du vælger ikke – de er gode som standard.

TLS 1.2 kræver valg. Gå efter det her:

• Key exchange: ECDHE for forward secrecy. Undgå RSA.
• Encryption: AES-GCM eller ChaCha20. Drop CBC (padding-angreb) og gamle som RC4, DES, 3DES.
• Hashing: SHA-256 eller SHA-384. Intet svagere.

Et godt Nginx eksempel:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;

Apache? Juster SSLProtocol og SSLCipherSuite. Pointen er: Vær præcis, konservativ og moderne.

Certifikatkæder: Den skjulte faldgrube

Ofte ser vi sider, der virker i Chrome, men krasher i gamle apps eller API-clients. Årsag? Manglende certifikatkæde.

Dit SSL-cert er ikke kun leaf-certet. Det er en kæde tilbage til root CA. Sender serveren kun leaf? Browsere finder ofte resten selv. Gamle clients? De fejler.

Løsningen er simpel: Hent intermediate certs fra CA'en. Konfigurer serveren til at sende hele kæden. Et par linjer i config – men must i produktion.

Compliance og tillid med solid TLS

Compliance er ikke fjenden. Det er bare gulvet. Men TLS 1.0-accept? Så ryger du på PCI DSS eller HIPAA-audits, bøder og tabt tillid.

Forward secrecy, stærke suites, ny TLS – det er basic.

Hvor ofte skal du tjekke TLS-opsætningen?

Efter hver ændring – og månedligt. Opdateringer, cert-renewals eller tweaks kan rote med indstillingerne. Månedligt check (automatiser det) fanger fejl tidligt.

Mange tjekker kun ved opsætning. Vær ikke dem.

Mere end TLS: Det store billede

God TLS er fundamentet. Men tilføj HSTS, CSP og X-Frame-Options for ekstra lag. Rigtig sikkerhed dækker auth, data, API'er og hardening.

Ved websites eller API'er? Kør fuld security-audit regelmæssigt – TLS og hele stakken.

Konklusion

TLS-handshake er smart og usynlig – som god infra skal være. Forstå det, hold det opdateret og audit ofte. Så har brugere tillid, og compliance-folk sover godt.

Hos NameOcean har vi værktøjer til at inspicere, fejl finde og overvåge din TLS. Sikkerhed skal ikke være mystik.