Gjensidig TLS (mTLS) autentisering skaper et sikkert rammeverk for autentisering av både brukere og IoT-enheter. Denne guiden vil lede deg gjennom implementeringen av mTLS for å sikre sikker toveis autentisering mellom klienter og servere.
Quick Start Guide
Setter opp gjensidig TLS følger en enkel prosess. Generer først de nødvendige server- og klientsertifikatene. Deretter konfigurerer du serveren til å kreve klientsertifikater. Sett deretter opp klientene med sertifikatene deres og implementer riktig sertifikatvalidering. Til slutt, test tilkoblingen for å sikre at alt fungerer som forventet.
Enveis og gjensidig SSL /TLS Autentisering
En av de definerende funksjonene i SSL /TLS protokollen er dens rolle i å autentisere ellers anonyme partier på datanettverk (for eksempel internett). Når du besøker et nettsted med en offentlig klarert SSL /TLS sertifikatkan nettleseren din verifisere at eieren av nettstedet har vist kontroll over dette domenenavnet til en pålitelig tredjeparts sertifikatmyndighet (CA), for eksempel SSL.com. Hvis denne bekreftelsen mislykkes, vil nettleseren advare deg om ikke å stole på nettstedet. For de fleste applikasjoner, SSL /TLS bruker denne typen enveis autentisering av en server til en klient; en anonym klient (nettleseren) forhandler om en kryptert økt med en webserver, som presenterer en offentlig klarert SSL /TLS sertifikat for å identifisere seg selv under SSL /TLS håndtrykk:
Gjensidig autentisering, hvor begge serverne og klient i SSL /TLS økt er autentisert, er også mulig og kan være veldig nyttig i noen tilfeller. Når serveren er autentisert under håndtrykk, i gjensidig godkjenning, vil den sende en CertificateRequest melding til klienten. Klienten vil svare ved å sende et sertifikat til serveren for godkjenning:
Klientautentisering via gjensidig TLS krever at et sertifikat inkludert Client Authentication (1.3.6.1.5.5.7.3.2) Extended Key Usage (EKU) er installert på klientenheten. Alle SSL.com-er E-post-, klient- og dokumentsigneringssertifikater inkluderer klientautentisering.
Detaljert implementeringsveiledning
Forstå gjensidig TLS
Tradisjonell TLS gir serverautentisering og kryptering, men gjensidig TLS går videre ved å kreve at begge parter presenterer digitale sertifikater. Denne toveisverifiseringen sikrer serverautentisitet, muliggjør klientautentisering, etablerer en kryptert kommunikasjonskanal og forhindrer mann-i-midten-angrep. Resultatet er en svært sikker tilkobling egnet for sensitive applikasjoner og IoT-enhetskommunikasjon.
Forutsetninger
Før du starter implementeringen, sørg for at du har tilgang til OpenSSL eller et lignende sertifikatadministrasjonsverktøy. Webserveren din må støtte TLS, og du trenger enten tilgang til en Sertifikatmyndighet (CA) eller muligheten til å opprette en privat CA. Klientene dine må også støtte sertifikatbasert autentisering.
Trinn 1: Sertifikatgenerering og -administrasjon
Start med å generere de nødvendige sertifikatene for både server- og klientautentisering. Serversertifikatoppsettet krever at du oppretter en privat nøkkel, generere en sertifikatsigneringsforespørsel, og signere sertifikatet med CA.
# Generer server privat nøkkel
openssl genrsa -ute server.nøkkel 2048
?
# Opprett signeringsforespørsel for serversertifikat (CSR)
openssl krav -ny -nøkkel server.nøkkel -ute server.csr
?
# Signer serversertifikatet med CA
openssl x509 -rekv -i server.csr -CA ca.crt -CAkey ca.nøkkel -CAkreaterserie -ute server.crt
For klientsertifikater, følg en lignende prosess for å lage deres unike legitimasjon:
# Generer klientens private nøkkel
openssl genrsa -ute klient.nøkkel 2048
?
# Opprett klient CSR
openssl krav -ny -nøkkel klient.nøkkel -ute client.csr
?
# Signer klientsertifikatet
openssl x509 -rekv -i client.csr -CA ca.crt -CAkey ca.nøkkel -CAkreaterserie -ute client.crt
Trinn 2: Serverkonfigurasjon
Serveren må konfigureres til å kreve og validere klientsertifikater. Her er et eksempel på konfigurasjon for Nginx:
server {
lytte 443 ssl;
Server navn eksempel.com;
?
ssl_certificate /bane/til/server.crt;
ssl_certificate_key /bane/til/server.nøkkel;
ssl_client_certificate /bane/til/ca.crt;
ssl_verify_client på;
ssl_protokoller TLSv1.2 TLSv1.3,
ssl_ciphers HØY:!aNULL:!MD5;
ssl_prefer_server_ciphers på;
}
For Apache-servere, bruk denne konfigurasjonen:
<VirtualHost *:443>
Server navn example.com
SSLengine on
SSLCertificateFile /path/to/server.crt
SSLCertificateKeyFile /bane/til/server.nøkkel
SSLCACertificateFile /path/to/ca.crt
SSLVerifyClient krever
SSLVerifyDepth 1
Trinn 3: Klientimplementering
Nettleserbasert autentisering krever import av klientsertifikatet til nettleserens sertifikatlager. Hver nettleser håndterer denne prosessen forskjellig, men generelt finner du alternativet i sikkerhets- eller personverninnstillingene.
For IoT-enheter må du implementere sertifikatbasert autentisering i koden din. Her er et eksempel som bruker Pythons forespørselsbibliotek:
importere forespørsler
?
client_cert = ('client.crt', 'client.key')
ca_cert = 'ca.crt'
?
svar = forespørsler.få('https://example.com',
cert=client_cert,
verifisere=ca_cert)
Trinn 4: Sertifikatvalidering
Riktig sertifikatvalidering er avgjørende for sikkerheten. Implementeringen din bør verifisere sertifikatkjedens integritet, sjekke utløpsdatoer, validere tilbakekallingsstatus og sikre riktig nøkkelbruk. Her er et eksempel på implementering:
fra kryptografi importere x509
fra kryptografi.hazmat.backends importere default_backend
?
def validate_certificate(cert_path):
med åpen(cert_path, 'rb') as cert_file:
cert_data = cert_file.lese()
cert = x509.last_pem_x509_sertifikat(cert_data, default_backend())
if cert.ikke_gyldig_etter < dato tid.dato tid.nå():
heve ValueError("Sertifikatet har utløpt")
prøve:
key_usage = cert.utvidelser.get_extension_for_class(x509.Nøkkelbruk)
if ikke key_usage.verdi.digital_signatur:
heve ValueError("Sertifikatet er ikke gyldig for digital signatur")
unntatt x509.utvidelser.ExtensionNotFound:
heve ValueError("Nødvendig utvidelse av nøkkelbruk ble ikke funnet")
Brukstilfeller for gjensidig godkjenning
Gjensidig TLS autentisering kan brukes både for å autentisere sluttbrukere og for gjensidig autentisering av enheter i et datanettverk.Bruker autentisering
Bedrifter og andre organisasjoner kan distribuere digitale klientsertifikater til sluttbrukere som ansatte, entreprenører og kunder. Disse klientsertifikatene kan brukes som en autentiseringsfaktor for tilgang til bedriftsressurser som Wi-Fi, VPN og webapplikasjoner. Når det brukes i stedet for (eller i tillegg til) tradisjonelle brukernavn / passord legitimasjon, gjensidig TLS tilbyr flere sikkerhetsfordeler:- Gjensidig TLS autentisering er ikke sårbar for legitimasjonstyveri via taktikker som f.eks phishing. Verizon Analyserapport fra 2020 indikerer at nesten en fjerdedel (22%) av datainnbrudd skyldes phishing. Phishing-kampanjer er ute etter pålitelige legitimasjoner som nettstedsinnloggingspassord, ikke de private nøklene til brukernes klientsertifikater. Som et ytterligere forsvar mot phishing, alle SSL.com-er E-post, klient og dokumentsignering sertifikater inkluderer offentlig klarert S/MIME for signert og kryptert e-post.
- Gjensidig TLS autentisering kan ikke kompromitteres av dårlig passordhygiene eller brute force-angrep på passord. Du kan kreve at brukerne lager sterke passord, men hvordan vet du at de ikke bruker det samme "sikre" passordet på 50 forskjellige nettsteder, eller har det skrevet på en lapp? EN 2019 Google-undersøkelse indikerer at 52% av brukerne bruker passord for flere kontoer, og 13% av brukerne bruker samme passord for alle av kontoene deres.
- Kundesertifikater gir en klar kjede av tillit, og kan styres sentralt. Med gjensidig TLS, bekreftelse av hvilken sertifikatmyndighet (CA) som har utstedt en brukers legitimasjon, blir bakt direkte inn i autentiseringsprosessen. SSL.coms online administrasjonsverktøy, SWS API, og tilgang til standardprotokoller som SCEP gjør utgivelse, fornyelse og tilbakekalling av disse legitimasjonene et øyeblikk!
- Enkeltpersoner eller organisasjoner som bare krever ett eller få sertifikater kan bestille E-post-, klient- og dokumentsigneringssertifikater á la carte fra SSL.com.
- Protokoller som SCEP, EST og CMP kan brukes til å automatisere påmelding og fornyelse av klientsertifikater for bedriftseide og BYO-enheter.
- For kunder som trenger et stort antall sertifikater, er grossistrabatter tilgjengelig via vår Program for forhandler og voluminnkjøp.
Beste praksis for sikkerhet
Sterk sikkerhet krever mer enn bare å implementere mTLS:
- Implementer automatisert sertifikatrotasjon for å sikre at sertifikater oppdateres jevnlig
- Oppretthold en sertifikatopphevelsesliste for raskt å ugyldiggjøre kompromitterte sertifikater
- Bruk sterke nøkkelstørrelser på minst 2048 biter for RSA-nøkler
- Konfigurer serverne dine til å bare akseptere sikker TLS versjoner og sterke chiffersuiter
Din klientsikkerhetsstrategi bør inkludere beskyttelse av private nøkler med sterke tilgangskontroller. Regelmessige sikkerhetsrevisjoner vil bidra til å opprettholde systemets integritet over tid.
Feilsøking av vanlige problemer
Sertifikatkjedeproblemer
Ved implementering av mTLS, kan du støte på sertifikatkjedeproblemer. Disse stammer vanligvis fra:
- Ufullstendige sertifikatkjeder
- Feil installerte mellomsertifikater
Slik løser du disse problemene:
- Bekreft at konfigurasjonen av tillitsankeret er riktig
- Sørg for at alle nødvendige sertifikater er til stede
Tilkoblingsproblemer
Tilkoblingsproblemer er ofte relatert til:
- Brannmurinnstillinger blokkerer TLS trafikk
- Feil sertifikattillatelser
Slik feilsøker du:
- Sjekk at sertifikatene dine er riktig navngitt
- Sørg for at de er tilpasset den tiltenkte bruken
Ytelseshensyn
Ytelseshensyn blir viktige i stor skala. For å optimalisere ytelsen:
- Implementer øktbufring for å redusere kostnadene ved gjentatte håndtrykk
- Velg effektive chiffersuiter som balanserer sikkerhet og ytelse
- Overvåk sertifikatvalideringsprosessen for å sikre at den ikke skaper unødvendig overhead
konklusjonen
