Gegenseitige Authentifizierung, wenn client gibt Sie Ihr öffentliches Zertifikat

In der Regel 2-Wege-ssl aka mutual auth umfasst erzeugen eines server-ca-Schlüssel & certs, etc.Dann generiert der client einen csr, gibt es für Sie und Unterschreiben Sie Ihre csr und versorgen Sie mit einem client-cert.

Jedoch

Den ich je erlebt habe ein Fall, wo der client erfordert, dass ich die Umsetzung der "mutual auth" durch den Austausch der jeweils anderen x509-öffentliche certs. Ist diese gehört? Vielleicht bezeichnet etwas anderes als "2-Wege-SSL" oder "Gegenseitige Authentifizierung".

Ich bin kämpfen, um zu finden, keine Dokumentation oder Informationen auf dieser mit openssl.

In diesem Fall (wenn alles so funktioniert, wie gedacht), der client immer ein x509-Zertifikat, wenn gegenseitige Authentifizierung verwendet. Der server kündigt seine Unterstützung für die zertifikatbasierte Authentifizierung, die von der Werbung der ZERTIFIZIERUNGSSTELLE akzeptiert werden als Emittenten. Hinweis: es gibt andere gegenseitige auth schemes, wie TLS-PSK-und TLS-SRP.

InformationsquelleAutor cosbor11 | 2016-05-04

3

Den ich je erlebt habe ein Fall, wo der client erfordert, dass ich die Umsetzung der "mutual auth" durch den Austausch der jeweils anderen x509-öffentliche certs. Ist diese gehört?

Ich glaube die nennt man auch heute noch die gegenseitige Authentifizierung.

Allgemein -, Zertifikat-basierte gegenseitige Authentifizierung fällt in eine von zwei Modellen. Das erste ist das enterprise-Modell mit einer CA-Hierarchie, und die Organisation der ZERTIFIZIERUNGSSTELLE signiert der client-und server-Zertifikat.

Das zweite Modell ist Kunden, die selbstsignierte Zertifikate verwenden, was als Origin-Bound Certificates. Die genannte Herkunft Gebunden, weil jede Website (origin) benötigt ein Zertifikat wird dem client zur Verfügung zu stellen. Origin gebunden Zertifikate sind die basis des IETF -Token Binding protocol.

Seine mir nicht klar, ob token-Bindung hat den gleichen Sicherheit Eigenschaften wie Herkunft gebunden Zertifikate. Sie sehen, wir können die Herkunft gebunden Zertifikate zu vereiteln man-in-the-middle-Angriffe durch die Authentifizierung Teil des Kanal-setup. Token-Bindung entkoppelt die Bindung und bewegt ihn nach oben in den Stapel. Ich glaube, es ermöglicht das MitM handeln als Vermittler.

Unternehmen Zertifikate

In der enterprise-Modell, hier ist was Sie tun, mit OpenSSL.

Auf dem server führen Sie die folgenden. Der server verarbeitet die client-Zertifikat-überprüfung:
- Nennen SSL_CTX_set_verify mit SSL_VERIFY_PEER und SSL_VERIFY_FAIL_IF_NO_PEER_CERT.
- Nennen CTX_set_client_CA_list um die Liste der Aussteller CA die der server akzeptiert. Dies bewirkt, dass die entsprechenden SSL/TLS-Nachricht an den client und fragt nach der Bescheinigung. Dieser sendet nur eine Liste von Namen an den client; Sie noch vertrauenswürdig sein müssen auf dem server
- Nennen SSL_CTX_load_verify_locations mit Emittenten, die der server akzeptiert. Dies steigert das Vertrauen auf der server-Seite.
Auf dem client führen Sie die folgenden:
- Nennen SSL_CTX_use_certificate_file laden Sie das client-Zertifikat
- Nennen SSL_CTX_use_certificate_chain_file Bedarf
- Nennen SSL_CTX_use_PrivateKey laden Sie den privaten Schlüssel
Origin-Bound Certificates

Herkunft gebunden und selbst signierte Zertifikate sind ein wenig anders, weil es keine CA-Hierarchie.

Auf dem server führen Sie die folgenden. Der server nicht nennen SSL_CTX_load_verify_locations oder CTX_set_client_CA_list weil es ein selbst signiertes Zertifikat.
- Nennen SSL_CTX_set_verify mit SSL_VERIFY_PEER und SSL_VERIFY_FAIL_IF_NO_PEER_CERT.
- Nennen SSL_get_peer_certificate nach key exchange. Überprüfen Sie das client-Zertifikat an den server.
Auf dem client führen Sie die folgenden. Es ist die gleiche wie die enterprise-Modell.
- Nennen SSL_CTX_use_certificate_file laden Sie das client-Zertifikat
- Nennen SSL_CTX_use_certificate_chain_file Bedarf
- Nennen SSL_CTX_use_PrivateKey laden Sie den privaten Schlüssel
Dem fehlen einer enterprise-CA bedeutet, dass der client das selbst signierte Zertifikat muss mitgeteilt werden out-of-band an den server. Dann wird der server braucht, um irgendeine Art von Verzeichnis, um die client-Zertifikate basieren auf definierten Namen und Seriennummern. Was Sie wirklich kümmern-hier ist mit dem öffentlichen Schlüssel des Kunden. In diesem Fall wird das X509-Zertifikat ist eine Darstellung detail. Nur seine Verpackung, weil es in der Regel bindet die Identität an einen öffentlichen Schlüssel, wenn eine Behörde Unterschrift (aber nicht in diesem Modell).

Den Angriff in diesem Modell, die 500-Pfund-gorilla im Raum - ist der "bad guy" die Identität eines Benutzers durch Verwendung der gleichen Distinguished Name und die Seriennummer, weil es keine Registration Authority (RA). Müssen Sie einige Maßnahmen, um sicherzustellen, dass Sie nicht hinters Licht geführt, wie das versenden einer E-Mail an einen Benutzer zu bestätigen, deren public-key-änderungen zu erwarten sind.

Den Angriff bedeutet, dass bei der Anmeldung eines Benutzers müssen Sie drei oder vier Dinge:
- Einzigartige {Distinguished Name, Seriennummer} paar
- Öffentlichen Schlüssel (Teil der X509-Zertifikat)
- Eine Bestätigungs - /Wiederherstellungs-E-Mail-Adresse
Das Wasser zu trüben weiter, kann der Benutzer 3 oder 4 Geräten, so dass Sie erstellen Sie einen neuen origin-gebunden-Zertifikat für jedes Gerät. Sie müssen behandeln der Registrierungs-anmutig, zu.

Gemeinsam nehmen Sie den Kreis, was wirklich zählt, ist die E-Mail-Adresse und die unterschiedliche öffentliche Schlüssel/Identitäten im Zusammenhang mit der E-Mail-Adresse. Die Identitäten befinden sich in einem X509-Zertifikat mit einem eindeutigen {Distinguished Name, Seriennummer} - pair-Mädchen. Sie wahrscheinlich wollen, dass Sie einzigartig für auditing-Zwecke, aber es wird wahrscheinlich einige kopieren/einfügen geht unter Geräte.

Ich bin kämpfen, um zu finden, keine Dokumentation oder Informationen auf dieser mit openssl.

Sind Sie wahrscheinlich Schwierigkeiten haben, Informationen zu finden, denn dies ist ein höheres Niveau, security-Architektur-und design-problem. Zu helfen, mit einigen Referenzen, starten Sie durch das Lesen Dietz, Czeskis, Balfanz und Wallach ist Origin-Bound Certificates: Ein neuer Ansatz für die Starke Client-Authentisierung für das Web. Besuchen Sie auch Peter Gutmann Engineering Security und Ross Anderson Security Engineering.

Herkunft Gebunden Zertifikate können verwendet werden, zu ersetzen, fast jedes Passwort-basierte Authentifizierung-system. Es gilt für fast alle Systeme, die aus Benutzername/Kennwort-basierte Authentifizierung für API-keys verwendet in web-services. Das Passwort ist immer noch zum Schutz der lokalen privaten Schlüssel, aber das Passwort wird nicht auf dem Draht.

Wenn Daten Empfindlichkeitsstufen garantieren mehr Sicherheit controls, client-Zertifikate ist eines der ersten Dinge, die wir drehen, um zu stoppen Missbrauch des Passwortes und misslungene Authentifizierung und Autorisierung. Nicht kaufen, Apple, Microsoft, Google (et al) Einsatz und Umgang mit Passwörtern. Seine schon defekt für Jahre. Einfach Unternehmen, die es leicht auf, so dass der Benutzer kann capture business.

InformationsquelleAutor jww

Den traditionellen client-Zertifikat-Methode nutzt eine CA und digitale Signaturen, um die Authentizität des Zertifikats.

In Ihrem Fall scheint es wie, was Sie wollen, ist der Austausch von Zertifikaten in einer vertrauenswürdigen Kanal vorher. Was Sie tun müssen, in diesem Fall ist das speichern der fingerprint dieses Zertifikats, und auf eingehende Anfragen bestätigen, dass die Signatur korrekt ist.

Hier ist ein Beispiel in Node.JS:

const https = require('https');
const fs = require('fs');

const options = {
    key: fs.readFileSync('/tmp/server.key'),
    cert: fs.readFileSync('/tmp/server.crt'),
    requestCert: true,
    rejectUnauthorized: false
};

https.createServer(options, (req, res) => {
    //We use snake oil certificates and no CA, so we will have an unauthorized cert.
    console.log(req.socket.authorized);
    var cert = req.connection.getPeerCertificate();
    //Here's the cert fingerprint, validate that it's the one you expected
    console.log(cert.fingerprint);

    res.writeHead(200);
    res.end('hello world\n');
}).listen(8000);

Einem ruby-Skript zum generieren der certs und keys:

require "openssl"

keypair = OpenSSL::PKey::RSA.new(2048)
cert = OpenSSL::X509::Certificate.new
cert.not_before = Time.now
cert.subject = OpenSSL::X509::Name.new([
    ["C", "NO"],
    ["ST", "Oslo"],
    ["L", "Oslo"],
    ["CN", "Root CA"]
                                               ])
cert.issuer = cert.subject
cert.not_after = Time.now + 1000000000 # 40 or so years
cert.public_key = keypair.public_key
cert.sign(keypair, OpenSSL::Digest::SHA256.new)

File.open("/tmp/client.key", "w+") do |f|
  f << keypair.to_pem
end

File.open("/tmp/client.crt", "w+") do |f|
  f << cert.to_pem
end


snakeoil_keypair = OpenSSL::PKey::RSA.new(2048)
snakeoil_cert = OpenSSL::X509::Certificate.new
snakeoil_cert.not_before = Time.now
snakeoil_cert.subject = OpenSSL::X509::Name.new([
    ["C", "NO"],
    ["ST", "Oslo"],
    ["L", "Oslo"],
    ["CN", "Root CA"]
                                               ])
snakeoil_cert.issuer = snakeoil_cert.subject
snakeoil_cert.not_after = Time.now + 1000000000 # 40 or so years
snakeoil_cert.public_key = snakeoil_keypair.public_key
snakeoil_cert.sign(snakeoil_keypair, OpenSSL::Digest::SHA256.new)

File.open("/tmp/server.key", "w+") do |f|
  f << snakeoil_keypair.to_pem
end

File.open("/tmp/server.crt", "w+") do |f|
  f << snakeoil_cert.to_pem
end

Test mit curl:

curl --insecure --cert /tmp/client.crt --key /tmp/client.key https://localhost:8000

Beachten Sie, dass eine wichtige Ebene der Sicherheit ist ausgelassen - jeder mit Fingerabdruck wird ein Gültiger Benutzer, die Sie nicht bekommen, die schöne crypto Prüfungen eines CA-setup.

Lilleass, vielen Dank für die Zeit nehmen, zu Antworten. Gibt es eine Bezeichnung für diese Strategie unterscheidet Sie von den traditionellen 2-Wege-SSL?
Ich bin mir nicht sicher. Wenn ich hatte zu kommen mit einem Namen würd ich vielleicht wählen Sie "Zertifikat-Fingerabdruck-Validierung" oder so ähnlich.
Ich denke, das ist etwas ganz anderes. Der SSL-handshake in meinem Fall ist dabei die gleiche genaue überprüfung als typischen SSL. Es gibt keine Fingerabdruck-beteiligt. Eher meine Frage ist mehr über das setup-Prozess anstatt der Authentifizierungsprozess
sind Sie etwa mit der Bezeichnung Origin-Bound Certificates, wenn Sie sind selbst-signiert. Der Browser verachte Sie, weil Ihre Sicherheit Modell umarmt Man-in-the-Middle. Sein der Grund das <keygen> tag ist Weg (und ein Grund, Sie nicht diskutieren, andere als zu vage sagen "es bricht legitime use cases). Sie können Origin-Bound Certificates in non-browser-web-services.

InformationsquelleAutor August Lilleaas

0

Gegenseitige Authentifizierung in TLS (oder SSL) - handshake erfordert Austausch des Zertifikats der beiden peers.

Authentifiziert der client den server anschließen, indem Sie die überprüfung des server-Zertifikats (eine Zertifikats-Kette, es wurde herausgegeben von).

Dies geschieht zum Beispiel, wenn Sie surfen https website. Ihr browser prüft das Zertifikat erhalten, ist vertraut (durch Suche der Zertifikat-Speicher) und werden auch prüfen, unter anderen Eigenschaften, die dns-Namen der website entspricht dem common name des Zertifikats.

In eine gegenseitige TLS-Authentifizierung, der server wird auch prüfen, ob der client vertrauenswürdig ist, indem überprüft der client-Zertifikat. Diese weniger häufige Art von Authentifizierung erfordert die folgenden Bedingungen:
1. Der client vorschlagen, in den TLS-handshake eine geeignete cipher, die die zertifikatsauthentifizierung erfordert
2. Der server wählt einen der client-Chiffre basiert auf seiner cipher-Konfiguration
3. Der server hat im Zertifikatspeicher mindestens die client-root-CA (möglich auch intermediate client CA)
4. Der client muss auch der server-root-CA - (und möglicherweise intermediate CA)
Erfüllen die erste Bedingung, die die openssl cipher Liste des Kunden gehören zum Beispiel Authentifizierung mittels RSA-basierten Verschlüsselungen wie RSA-AES128-SHA256. Sehen Sie die client-cipher-Liste mit wireshark, indem man die client hello Nachricht. Zu definieren (oder zu beschränken) die Anzahl von Chiffren, die Sie verwenden können openssl ciphers Befehl und spielen Sie mit den Ziffer-string.

Auf der server-Seite die Chiffre muss auch konfiguriert werden, und ausgewählten. Diese Auswahl ist abhängig von der Implementierung. Oft wird der server wählen Sie die erste geeignete cipher gesehen in der client hello (auch wenn der RFC sagt der server kann wählen Sie eine beliebige Ziffer von der Liste). In einigen Fällen setzen die wollte cipher oben auf der client-cipher-Liste hilft.

Bezüglich Zertifikat, server-und client-root-CA müssen bereitgestellt werden bzw. in den client-und server-Zertifikat zu speichern. Nun, wenn jede Seite verfügt über eine Zertifikat-Kette, es ist manchmal erforderlich, um auch die Zwischenzertifizierungsstelle im Zertifikatspeicher.

InformationsquelleAutor oliv

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.