Kategorie-Archiv: Webdesign

Problem

Firefox ab Version 39 zeigt viele SSL-gesicherte Seiten nicht mehr an und gängelt den erfahrenen Admin stattdessen mit dieser Meldung:

Fehler: Gesicherte Verbindung fehlgeschlagen

Ein Fehler ist während einer Verbindung mit foo.bar aufgetreten. SSL hat einen schwachen
kurzlebigen Diffie-Hellman-Schlüssel in der Handshake-Nachricht "Server-Schlüsselaustausch"
empfangen. (Fehlercode: ssl_error_weak_server_ephemeral_dh_key)

Das bedeutet, das die anzuzeigende Seite gegen die Logjam-Attacke auf SSL verwundbar ist. Im Prinzip soll der DH-Schlüsseltausch PFS liefern, in einigen Implementierungen ist das Protokoll allerdings angreifbar. Die notwendige Sicherheit auf dem initialen Schlüsselaustausch liefern nur Schlüssellängen von 512bits und mehr, die anzuzeigende Seite möchte aber weniger. Das betriff viele Fritz! Boxen („fritz.box“), Speedport-Router der Telekom („speedport.ip“) und ähnliche Geräte.

Blöderweise liefert viel Hardware und viele Infrastrukturkomponenten die jeweiligen Web-GUIs mit so einer SSL-Konfiguration aus. Dazu zählen EMC, Nimble, HP, IBM, NetAPP, Cisco und fast jeder andere. Da Firmware-Updates an solchen kritischen Punkten oft etwas länger brauchen, benötigen Admins hier eine Lösung (abgesehen von der Wwahl, Chrome oder Edge zu nutzen).

Lösung

Firefox hat SSLv3 zum Glück noch nicht verlernt, sondern nur dekativiert:

1. „about:config“ in der Adresszeile öffnen (und Warnung wegklicken)
2. Suche nach „security.ssl3.„
3. Die beiden Einträge „security.ssl3.dhe_rsa_aes“ zu 128 und 265bit mittels Doppelklick auf „false“ stellen.

Wenn man mit aspx (zum Beispiel C#) eine Datei zum Download ausliefern will, kann es vorkommen, dass im Firefox folgende Meldung erscheint:

XML-Verarbeitungsfehler: Kein Element gefunden

Adresse: http://xyz/download.aspx

Zeile Nr. 1, Spalte 1:

^

Während im Internet Explorer die Seite einfach komplett leer/weiß bleibt.

Folgende zwei Ansätze sind meist der Grund für diesen Fehler.

#1 – Fehlender ASP-Dokumentenheader in der aspx-Datei

<%@ Page Language=“C#“ AutoEventWireup=“true“ CodeFile=“download.aspx.cs“ Inherits=“download“ %>

Wenn die obige Zeile nicht in der aspx-Datei enthalten ist (Dateiname der Codedatei und Name des dortigen Namespaces entsprechend anpassen), weil man ja keinen Inhalt der aspx-Datei im binären Downloadstream haben will, dann führt ASP die vielleicht vorhandene Codedatei gar nicht erst aus. Um dies zu lösen, muss man also einfach nur die obige Zeile einfügen und anpassen.

#2 – Dateipfad falsch oder keine Berechtigungen für den aktuellen User des IIS

Kommt die Meldung im Firefox auch dann noch, deutet dies darauf hin, dass die herunter zu ladende Datei vom System nicht gefunden werden konnte.

Dies kommt jedoch ausschließlich dann vor, wenn man mittels folgender Befehle die Response-Header löscht und den Browser anweist einen bestimmten Dateityp zu erwarten (im folgenden Beispiel PDF).

protected void Page_Load(object sender, EventArgs e)

{

FileInfo file = new FileInfo(@“C:DatenmeinePDFdownload.pdf“);

Response.ClearContent();

Response.ClearHeaders();

Response.ContentType = „Application/pdf“;

Response.AddHeader(„Content-Disposition“, „inline;filename=test.pdf“);

try {

Response.AppendHeader(„Content-Length“, file.Length.ToString());

Response.WriteFile(file.FullName);

Response.Flush();

Response.Close();

} catch (Exception ex) {

Response.ClearContent();

}

}

Man sollte also nochmals manuell prüfen, ob die Datei überhaupt vorhanden und zugänglich ist.