Firefox 3.6.4 und Smartcards

Du benötigst Hilfe bezüglich Firefox? Bitte stelle deine Frage im öffentlichen Bereich des Forums und nicht per Konversation an wahllos ausgesuchte Benutzer. Wähle dazu einen passenden Forenbereich, zum Beispiel „Probleme auf Websites“ oder „Erweiterungen und Themes“ und klicke dann rechts oben auf die Schaltfläche „Neues Thema“.
  • 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?

    Chris (bubu_24)

  • 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?

  • bubu_24 stellte u.A. Folgendes dar:

    Zitat

    Bei Einsatz einer Smartcard als Zertifikats- und Schlüsselträger wird jede Aushandlung eines Sitzungsschlüssels manifest (PIN-Eingabe). Soweit OK.[...]


    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.




    bubu_24 erklärte u.A. Folgendes:

    Zitat

    [...]Dennoch bleibt die Paarung URL zu Sitzungsschlüssel scheinbar erhalten - das ist nicht so gut.[...]


    Das ist richtig. 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.




    bubu_24 fragte obendrein:

    Zitat

    [...]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?


    Soweit ich hier richtig informiert bin, offeriert Firefox nur die Möglichkeit des Löschens einzelner URL´s aus der Chronik heraus - jedoch werden somit die Daten (zur Schlüsselvernichtung) nicht aus dem Cache selber entfernt. Vielleicht gibt es eine Erweiterung, die so etwas besorgen kann.



    Oliver

  • 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. 8)

    Chris (bubu_24)

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

  • 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:

    Code
    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.

    Chris (bubu_24)