Wederzijds TLS (mTLS) authenticatie creëert een veilig raamwerk voor het authenticeren van zowel gebruikers als IoT-apparaten. Deze gids begeleidt u bij het implementeren van mTLS om veilige bidirectionele authenticatie tussen clients en servers te garanderen.
Quick Start Guide
Het opzetten van een wederzijdse TLS volgt een eenvoudig proces. Genereer eerst de benodigde server- en clientcertificaten. Configureer vervolgens uw server om clientcertificaten te vereisen. Stel vervolgens uw clients in met hun certificaten en implementeer de juiste certificaatvalidatie. Test ten slotte de verbinding om ervoor te zorgen dat alles werkt zoals verwacht.
Eenrichtingsverkeer en wederzijdse SSL /TLS authenticatie
Een van de bepalende kenmerken van de SSL /TLS protocol is zijn rol bij het authenticeren van anderszins anonieme partijen op computernetwerken (zoals internet). Wanneer u een website bezoekt met een openbaar vertrouwd SSL /TLS certificaat, kan uw browser verifiëren dat de website-eigenaar met succes de controle over die domeinnaam heeft aangetoond aan een vertrouwde externe certificeringsinstantie (CA), zoals SSL.com. Als deze verificatie mislukt, zal de webbrowser u waarschuwen om die site niet te vertrouwen. Voor de meeste toepassingen is SSL /TLS gebruikt dit soort eenrichtingsverificatie van een server naar een klant; een anonieme client (de webbrowser) onderhandelt over een gecodeerde sessie met een webserver, die een openbaar vertrouwde SSL /TLS certificaat om zichzelf te identificeren tijdens de SSL /TLS handdruk:
Wederzijdse authenticatie, waarin beide server en client in de SSL /TLS sessie worden geauthenticeerd, is ook mogelijk en kan in sommige omstandigheden erg handig zijn. Bij wederzijdse authenticatie, zodra de server is geauthenticeerd tijdens de handshake, zal deze een CertificateRequest bericht aan de klant. De klant zal reageren door een certificaat naar de server te sturen voor authenticatie:
Clientauthenticatie via wederzijds TLS vereist dat een certificaat inclusief de Client Authentication (1.3.6.1.5.5.7.3.2) Extended Key Usage (EKU) is geïnstalleerd op het clientapparaat. Alle SSL.com's E-mail-, client- en documentondertekeningscertificaten inclusief client authenticatie.
Gedetailleerde implementatiegids
Begrijpen van wederzijdse TLS
traditioneel TLS biedt serverauthenticatie en -encryptie, maar wederzijds TLS gaat verder door te eisen dat beide partijen digitale certificaten presenteren. Deze tweerichtingsverificatie zorgt voor serverauthenticiteit, maakt clientauthenticatie mogelijk, stelt een gecodeerd communicatiekanaal in en voorkomt man-in-the-middle-aanvallen. Het resultaat is een uiterst veilige verbinding die geschikt is voor gevoelige toepassingen en IoT-apparaatcommunicatie.
Voorwaarden
Voordat u met de implementatie begint, moet u ervoor zorgen dat u toegang hebt tot OpenSSL of een vergelijkbare tool voor certificaatbeheer. Uw webserver moet TLS, en je hebt toegang nodig tot een Certificate Authority (CA) of de mogelijkheid om een privé-CA te creëren. Uw clients moeten ook certificaatgebaseerde authenticatie ondersteunen.
Stap 1: Certificaatgeneratie en -beheer
Begin met het genereren van de benodigde certificaten voor zowel server- als clientauthenticatie. De servercertificaatinstelling vereist het maken van een privésleutel, een certificaatondertekeningsverzoek genererenen het certificaat ondertekenen met uw CA.
# Genereer serverprivésleutel
openssl genrsa -uit server.sleutel 2048
?
# Maak een servercertificaatondertekeningsverzoek (CSR)
openssl req -nieuw -sleutel server.sleutel -uit server.csr
?
# Onderteken het servercertificaat met uw CA
openssl x509 -vereist -in server.csr -CA ca.crt -CAsleutel ca.sleutel -CAcreateserieel -uit server.crt
Voor clientcertificaten volgt u een vergelijkbaar proces om unieke referenties te maken:
# Genereer een privésleutel voor de client
openssl genrsa -uit klant.sleutel 2048
?
# Maak klant aan CSR
openssl req -nieuw -sleutel klant.sleutel -uit klant.mvo
?
# Onderteken het clientcertificaat
openssl x509 -vereist -in klant.mvo -CA ca.crt -CAsleutel ca.sleutel -CAcreateserieel -uit klant.crt
Stap 2: Serverconfiguratie
De server moet geconfigureerd zijn om clientcertificaten te vereisen en te valideren. Hier is een voorbeeldconfiguratie voor Nginx:
server {
luisteren 443 ssl;
server naam voorbeeld.com;
?
ssl_certificate /pad naar/server.crt;
ssl_certificate_key /pad naar/server.sleutel;
ssl_client_certificaat /pad/naar/ca.crt;
ssl_verificatie_client op;
ssl_protocollen TLSv1.2 TLSv1.3;
ssl_cijfers HOOG:!aNUL:!MD5;
ssl_prefer_server_ciphers op;
}
Gebruik deze configuratie voor Apache-servers:
<VirtualHost *:443>
ServerName example.com
SSLEngine on
SSLCertificaatBestand /pad/naar/server.crt
SSLCertificaatKeyFile /pad/naar/server.key
SSLCACertificaatbestand /pad/naar/ca.crt
SSLVerifyClient vereisen
SSLVerifyDepth 1
Stap 3: Clientimplementatie
Browser-based authenticatie vereist het importeren van het clientcertificaat in de certificaatopslag van uw browser. Elke browser verwerkt dit proces anders, maar over het algemeen vindt u de optie in de beveiligings- of privacyinstellingen.
Voor IoT-apparaten moet u certificaatgebaseerde authenticatie implementeren in uw code. Hier is een voorbeeld met behulp van de requests-bibliotheek van Python:
importeren verzoeken
?
client_certificaat = ('client.crt', 'client.sleutel')
ca_cert = 'ca.crt'
?
antwoord = verzoeken.krijgen('https://voorbeeld.com',
cert=client_certificaat,
controleren=ca_cert)
Stap 4: Certificaatvalidatie
Correcte certificaatvalidatie is cruciaal voor de beveiliging. Uw implementatie moet de integriteit van de certificaatketen verifiëren, vervaldatums controleren, de intrekkingsstatus valideren en correct sleutelgebruik garanderen. Hier is een voorbeeldimplementatie:
van geheimschrift importeren x509
van geheimschrift.hazmat.backends importeren standaard_backend
?
def certificaat_valideren(cert_pad):
met open(cert_pad, 'rb') as cert_bestand:
certificaat_gegevens = cert_bestand.dit artikel lezen()
cert = x509.laad_pem_x509_certificaat(certificaat_gegevens, standaard_backend())
if cert.niet_geldig_na < datetime.datetime.nu
verhogen ValueError("Certificaat is verlopen")
proberen:
sleutel_gebruik = cert.extensies.krijg_extensie_voor_klasse(x509.Sleutelgebruik)
if niet sleutel_gebruik.waarde.digitale_handtekening:
verhogen ValueError("Certificaat niet geldig voor digitale handtekening")
behalve x509.extensies.UitbreidingNietGevonden:
verhogen ValueError("Vereiste sleutelgebruik-extensie niet gevonden")
Gebruiksscenario's voor wederzijdse authenticatie
Wederzijds TLS authenticatie kan zowel worden gebruikt om eindgebruikers te authenticeren als voor wederzijdse authenticatie van apparaten op een computernetwerk.Gebruikersverificatie
Bedrijven en andere organisaties kunnen digitale clientcertificaten distribueren naar eindgebruikers zoals werknemers, contractanten en klanten. Deze clientcertificaten kunnen worden gebruikt als authenticatiefactor voor toegang tot bedrijfsbronnen zoals wifi, VPN's en webapplicaties. Bij gebruik in plaats van (of naast) traditionele gebruikersnaam / wachtwoordreferenties, wederzijds TLS biedt verschillende veiligheidsvoordelen:- Wederzijds TLS authenticatie is niet kwetsbaar voor diefstal van inloggegevens via tactieken zoals Phishing. Verizon Onderzoeksrapport gegevensinbreuk 2020 geeft aan dat bijna een kwart (22%) van de datalekken te wijten is aan phishing. Phishing-campagnes zijn erop uit om gemakkelijk te verzamelen inloggegevens zoals inlogwachtwoorden voor websites, niet de privésleutels van de clientcertificaten van gebruikers. Als verdere verdediging tegen phishing gebruiken alle SSL.com's E-mail, client en ondertekening van documenten certificaten bevatten openbaar vertrouwde S/MIME voor ondertekende en gecodeerde e-mail.
- Wederzijds TLS authenticatie kan niet worden aangetast door slechte wachtwoordhygiëne of brute force-aanvallen op wachtwoorden. U kunt van gebruikers eisen dat ze sterke wachtwoorden maken, maar hoe weet u dat ze datzelfde 'veilige' wachtwoord niet op 50 verschillende websites gebruiken of op een plakbriefje hebben geschreven? EEN Google-enquête van 2019 geeft aan dat 52% van de gebruikers wachtwoorden hergebruikt voor meerdere accounts, en 13% van de gebruikers hergebruikt hetzelfde wachtwoord voor allen van hun rekeningen.
- Clientcertificaten bieden een duidelijk keten van vertrouwen, en kan centraal worden beheerd. Met wederzijds TLS, wordt verificatie van welke certificeringsinstantie (CA) de inloggegevens van een gebruiker heeft uitgegeven, direct in het authenticatieproces ingebakken. SSL.com's online beheertools, SWS-APIen toegang tot standaardprotocollen zoals SCEP maken het uitgeven, vernieuwen en intrekken van deze inloggegevens in een handomdraai!
- Individuen of organisaties die slechts één of enkele certificaten nodig hebben, kunnen bestellen E-mail-, client- en documentondertekeningscertificaten á la carte van SSL.com.
- Protocollen zoals SCEP, EST en CMP kunnen worden gebruikt om de inschrijving en verlenging van clientcertificaten te automatiseren voor apparaten die eigendom zijn van het bedrijf en BYO-apparaten.
- Voor klanten die een grote hoeveelheid certificaten nodig hebben, zijn groothandelskortingen beschikbaar via ons Programma voor wederverkoper en volumeaankoop.
Best practices voor beveiliging
Een sterke beveiliging vereist meer dan alleen de implementatie van mTLS:
- Implementeer geautomatiseerde certificaatrotatie om ervoor te zorgen dat certificaten regelmatig worden bijgewerkt
- Houd een certificaatintrekkingslijst bij om gecompromitteerde certificaten snel ongeldig te maken
- Gebruik sterke sleutelgroottes van ten minste 2048 bits voor RSA-sleutels
- Configureer uw servers zo dat ze alleen beveiligde e-mails accepteren. TLS versies en sterke cipher suites
Uw clientbeveiligingsstrategie moet het beschermen van privésleutels met sterke toegangscontroles omvatten. Regelmatige beveiligingsaudits helpen de integriteit van het systeem in de loop van de tijd te behouden.
Problemen oplossen met veelvoorkomende problemen
Problemen met certificaatketen
Bij de implementatie van mTLS, kunt u problemen met de certificaatketen tegenkomen. Deze komen meestal voort uit:
- Onvolledige certificaatketens
- Onjuist geïnstalleerde tussenliggende certificaten
Om deze problemen op te lossen:
- Controleer of uw vertrouwensankerconfiguratie correct is
- Zorg ervoor dat alle benodigde certificaten aanwezig zijn
Verbindingsproblemen
Verbindingsproblemen hebben vaak te maken met:
- Firewall-instellingen blokkeren TLS verkeer
- Onjuiste certificaatmachtigingen
Om problemen op te lossen:
- Controleer of uw certificaten de juiste naam hebben
- Zorg ervoor dat ze passen bij het beoogde gebruik
Prestatieoverwegingen
Prestatieoverwegingen worden belangrijk op schaal. Om prestaties te optimaliseren:
- Implementeer sessiecaching om de overhead van herhaalde handshakes te verminderen
- Kies efficiënte cipher suites die veiligheid en prestaties in evenwicht brengen
- Houd uw certificaatvalidatieproces in de gaten om er zeker van te zijn dat het geen onnodige overhead veroorzaakt
Conclusie
