Beiträge von bubu_24

Zitat von Master X

Sendet der Server beim Anmelden mit dem falschen Schlüssel ein "HTTP Error 401 Unauthorized" oder wie reagiert der Server?

Nein, ich muss wohl etwas präzisieren. Der Server liefert ja eine Auswahl an CA-Zertifikaten mit, die Aussteller des Client-Zertifikats sein können. FF stellt die möglichen (lokal bekannten) EE-Zertifikate (mit einem der gegebenen CA) zur Auswahl.

Wenn diese Auswahl abgebrochen wird, kann kein Zertifikat ausgetauscht werden, die Aushandlung schlägt fehl.
Es bleibt der bereits bestehende SSL-Kanal, der aber für die URL mit sicherer Authentifizierung ungeeignet ist.

Letztendlich erhält der Client ein Encryption Alert Paket. Die Dekomprimierung des Cryptogramms vom Server schlägt fehl.

Der Client zeigt an:

Zitat

Fehler: Gesicherte Verbindung fehlgeschlagen
Ein Fehler ist während einer Verbindung mit <servername> aufgetreten.
Die SSL-Gegenstelle konnte keinen akzeptablen Satz an Sicherheitsparametern aushandeln.
(Fehlercode: ssl_error_handshake_failure_alert)

* Die Website kann nicht angezeigt werden, da die Authentizität der erhaltenen Daten nicht verifiziert werden konnte.

* Kontaktieren Sie bitte den Inhaber der Website, um ihn über dieses Problem zu informieren. Alternativ können Sie auch die Funktion im Hilfe-Menü verwenden, um diese Website als fehlerhaft zu melden.

Im Server-Log finde ich:

ssl_error.log:
<Timestamp> [error] Re-negotiation handshake failed: Not accepted by client!?


ssl_access_log:
<IP-Addr> - - [<TIMESTAMP>] "GET /sc HTTP/1.1" 403 -

Die Nachricht müsste also "Error 403 Forbidden" lauten, kann aber wohl nicht mehr dekomprimiert werden.
Reload der Seite bringt keine Änderung, bis zur Löschung der aktiven Verbindungen aus der Chronik

Die Pakete wurden mit Wireshark verfolgt.

Besten Dank für die Antworten.

Zitat von XtC4UaLL

Mangels der Möglichkeit zur Reproduktion lediglich die Frage: ist das eine Regression gegenüber einer vorherigen Firefox Version?
Falls ja, welche ist die letzte Version wo es funktionierte, welche die erste wo es das nicht tat?

Das beobachtete Verhalten ist bereits in früheren Versionen von FF so implementiert, keine Regression.

Zitat von Oliver222

Wird der digitale Schlüssel im EPROM der SmartCard gehalten, ist zur unwiderruflichen Schlüsselvernichtung wiederum die physikalische Zerstörung des Mikrochips selber erforderlich. Der Einsatz solcher SC´s (besonders unter RSA 2048 Bit Verschlüsselung) ist somit gegenüber volatiler Hintergrundspeicher (z.B. Festplatten, Flash-Speicher, etc.) zu favorisieren.

Auf der Smartcard befindet sich im Asymmetrischen Verfahren nur der private Schlüssel, der cryptografisch die Umkehroperation zum im Zertifikat enthaltenen öffentlichen Schlüssel ermöglicht. Er kann zu Authentisierung oder zur Signatur eingesetzt werden.

Unter Verwendung des privaten Schlüssels wird zwischen Browser (FF) und Server (Apache?) ein symmetrischer Sitzungsschlüssel ausgehandelt (dazu ist die Verwendung des privaten Schlüssels und somit eine PIN-Eingabe erforderlich). Eine Zerstörung dieses (an die URL gebundene) Sitzungsschlüssels müsste hinreichen, bei erneutem Besuch derselben URL eine erneute Schlüsselaushandlung zu initiieren.

Angenommen, man verfügt über mehrere Zertifikate auf Smartcards und legt bei der Authentifizierung beim Server ein nicht-akzeptiertes Zertifikat vor, so kann die Aushandlung des Sitzungsschlüssels nicht abgeschlossen werden, die Sitzung ist ungültig. Ein Refresh der URL sollte dann doch eigentlich zu neuer Schlüsselaushandlung und damit zur Zertifikatswahl und PIN-Eingabe führen. Das ist aber leider nicht der Fall.

Zitat von Oliver222

Ein gültiger Sitzungsstatus könnte somit in einem weiteren vereinfachten „SSL-Handshake-Verfahren“ (Server-Client) erneut wieder aufgenommen werden, sofern im Zuge der zugrundeliegenden SSL-Spezifikation serverseitig das Flag auf: „is resumable“ (SSLv.3) gesetzt wurde.

Ggf. verhindert das Vorliegen eines Schlüssels aus einer vorangegangenen erfolgreichen Aushandlung (etwa einer parent-URL desselben Servers) die erneute Aushandlung anhand asymmetrischer Schlüssel?

Kann die erneute Schlüsselaushandlung ggf. serverseitig provoziert werden?

Zitat von Oliver222

Vielleicht gibt es eine Erweiterung, die so etwas besorgen kann.

Eine solche Erweiterung würde vorzugsweise autonom auf dem Client agieren (ohne manuellen Eingriff), da die beobachtete Handhabung von Sitzungszuständen wohl eher als generische Eigenschaft implementiert sind, oder? Ein Hinweis auf eine solche Erweiterung wäre allemal willkommen.

Firefox unterstützt die gegenseitige Authentifizierung bei SSL (HTTPS)-Verbindungen.
Er verfügt über einen Cache, in dem unter anderem der Sitzungsschlüssel und scheinbar auch die URL hinterlegt sind.

Bei Einsatz einer Smartcard als Zertifikats- und Schlüsselträger wird jede Aushandlung eines Sitzungsschlüssels
manifest (PIN-Eingabe). Soweit OK. Zuvor erhält man (optional) einen Auswahldialog, der die 'passenden' Zertifikate
d.h. die von einem dem Server bekannten Aussteller stammt. Auch OK.

Wenn man den Auswahldialog abbricht, schlägt die Authentisierung fehl, was als Warnmeldung dargestellt wird.
Dennoch bleibt die Paarung URL zu Sitzungsschlüssel scheinbar erhalten - das ist nicht so gut.
Erst durch "Extras/Neueste Chronik löschen" kann der Schlüssel manuell entfernt werden, wenn die Option
"aktive Verbindungen" angehakt ist.

Dieses Verhalten ist sehr störend, wenn die Serversite zunächst nur einen anonymen SSL-Kanal, in einem Unterbereich
etwa "/authentisiert" ein Zertifikat verlangt. Gibt es eine Möglichkeit, auf dem Client den Cache (vorzugsweise nur für
die gewählte URL) zu entfernen, wenn die Verbindung nicht zustandekommt, sodass ein Reload auf der URL wieder
zur Zertifikatsauswahl führt?

Ideen?