Posts Tagged ‘SSL’

Dienstag, 8. August 2017

Google Chrome wieder nützliche Informationen über TLS-Verschlüsselung anzeigen lassen

Als Security Officer befasst man sich gelegentlich auch mit TLS-Zertifikaten von Web-Sites. Wenn man die Zertifikate und die Verschlüsselung einer im öffentlichen Internet ansprechbaren Web-Site bewerten lassen möchte, verwendet man dazu am Besten Qualys SSL Server Test.

Manchmal aber sind Web-Applikationen nur im Intranet erreichbar, oder manchmal möchte man einfach nur ganz rasch in Erfahrung bringen, welche Verschlüsselung eine Web-Site einsetzt.

Bis vor kurzem ging das in Chrome ganz flott: In der URL-Bar klickte man auf das Schloss-Symbol und erhielt mit ein, zwei Klicks alle nötigen Informationen präsentiert. Spätestens seit Version 59 klappt das nicht mehr.

In Version 60 haben die Chrome-Entwickler das Problem resp. den Kundenwunsch erkannt und ermöglichen es neu, die Funktionalität mittels einer Konfigurationseinstellung wieder zu reaktivieren:

  1. Chrome starten
  2. Die URL chrome://flags/#show-cert-link ansurfen
  3. Enable anklicken
  4. Chrome neu starten

Via: Configure Google Chrome to display certificates directly

Und ab sofort gibt es mit Klick auf das Schlosssymbol einer Web-Site wieder den Eintrag „Certificate“:

Mit Klick auf Valid öffnet sich danach ein os-spezifisches Fenster mit Informationen zum Zertifikat:

Tags: , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 15. Juni 2016

Ein Avocent DSR1031 meldet „Network Connect Error“

Heute fand per Post ein gebrauchter Avocent DSR1031 IPKVM-Switch den Weg zu mir nach Hause. Ich werde den IP-fähigen KVM-Switch im Elternhaus installieren, um im Notfall einen Linux-Server fernsteuern zu können.

Erste Ernüchterung bereits umgehend bei der Verbindung auf die IP-Adresse des Switches: Leider ist das von Acovent auf dem KVM-Switch verbaute Zertifikat im letzten Jahr abgelaufen:

Avocent DSR1031 Certificate Expired

Als erstes aktualisierte ich das Firmware des Geräts auf Version 03.07.01.20, welche ich von der Web-Site des Herstellers heruntergeladen hatte (ich musste den FTP-Link manuell in CyberDuck einfügen; der Download mittels Web-Link klappte partout nicht).

Leider löste dies die Problematik des abgelaufenen Zertifikats nicht — so viel zu Hersteller-Support im SSL/TLS-Umfeld.

Anschliessend musste ich auf Firefox ausweichen, um ein Verbindungsfile hinter einem Link namens „KVM Session“ unter einem vom Vorbesitzer erfassten Device herunterzuladen — Safari zeigte einen Download an, die Datei fand sich aber nicht im Download-Ordner.

Der Klartext der heruntergeladenen Datei zeigte, dass es sich um ein sogenanntes Java Network Launch Protocol JNLP-File handelt:

<?xml version="1.0" encoding="utf-8"?>

<!-- JNLP File for Java Video Viewer Application -->

<jnlp spec="1.0+" codebase="http://10.0.1.227/webstart2">
   <information>
      <title>Video Session Viewer</title>
      <vendor>Avocent</vendor>
      <description>Video Session Viewer</description>
      <description kind="short">Video Viewer</description>
   </information>

   <security>
      <all-permissions/>
   </security>

   <resources>
      <j2se version="1.5+"/>
      
      <jar href="avctVideo.jar"/>
      <jar href="avctVM.jar"/>
      <nativelib href="avctWin32Lib.jar"/>
      <nativelib href="avmWin32Lib.jar"/>
      <nativelib href="avctLinuxLib.jar"/>
      <nativelib href="avmLinuxLib.jar"/>
      <nativelib href="avctSolarisLib.jar"/>
      <nativelib href="avmSolarisLib.jar"/>
      <nativelib href="avctMacOSXLib.jar"/>
      <nativelib href="avmMacOSXLib.jar"/>
      <nativelib href="jpcscdll.jar"/>
      <nativelib href="jpcscso.jar"/>
   </resources>
...

Diese Datei startet man folgendermassen:

$ javaws -verbose kvm.cgi

Leider erhielt ich mit J2SE Version 8 Update 91 folgende Fehlermeldung zu Gesicht:

Avocent Network Connect Error

Nach einigen Recherchen im Internet fand ich im Support-Forum des Herstellers im Beitrag „AutoView 3016 Java network connect error“ die Lösung.

In der Datei /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/java.security müssen zwei Parameter für den Umgang mit verschlüsselten Verbindungen angepasst werden:

...
#jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
jdk.certpath.disabledAlgorithms=
...
#jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768
jdk.tls.disabledAlgorithms=
...

Danach klappte die Verbindungsaufnahme:

Avocent Video Viewer Channel not found

Leider habe ich so meine Java-Installation extrem unsicher gemacht. Die Browser-Plugins habe ich seit längerem allesamt deaktiviert, was das Risiko etwas senkt.

Nachtrag

Mittlerweile habe ich — selbstverständlich mittels Internet-Resourcen — herausgefunden, wie man die Java-Einstellungen ausschliesslich nur für einen bestimmten Prozess abändert. Hierzu habe ich mir ein Script geschrieben, mit welchem ich den Avocent Viewer starten kann:

#!/bin/bash
...
SCRIPTDIR="/path/to/script/dir"
...
JAVAWS=$(which javaws)
JNLP="$SCRIPTDIR/kvm.jnlp"
JAVASECURITY="$SCRIPTDIR/java.security"

# http://stackoverflow.com/questions/1047154/java-webstart-options
CMD="$JAVAWS -J\"-Djava.security.properties=$JAVASECURITY\" $JNLP &"
echo $CMD
eval $CMD
echo ""

exit 0

Im Verzeichnis, in welchem das Bash-Script liegt, habe ich eine Kopie der oben genannten Datei java.security abgelegt und die Anpassungen an der lokalen Kopie vorgenommen (die globale Datei java.security führt nur die sicheren Ciphers auf). Den Pfad zur lokalen Datei übergebe ich Java Web Start mittels einer Kommandozeile -J, in welcher eine Java-Argument verschachtelt ist -D.

Tags: , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 4. Januar 2015

Remember The Milk lädt nicht mehr

Frisch zurück aus den Ferien kämpfte ich mit dem Zugriff auf meine Taskliste, welche ich mit der SaaS-Anwendung Remember The Milk verwalte. Wenn ich diese Seite in Safari aufrief, erschien einzig der blaue Hintergrund des Teasers, ohne dass aber die Lade-Animation erschien. In Firefox konnte ich mich problemlos in die Anwendung einloggen.

Ein Blick auf die Web Developer-Konsole in Safari gab mir einen ersten Hinweis, wo das Problem lag:

Safari Web Developer Console

Safari akzeptierte das SSL-Zertifikat für die Server s1.rtmcdn.net und s4.rtmcdn.net nicht (mehr). Offenbar hatte Firefox gleichzeitig kein Problem damit, die Server anzusprechen und Ressourcen von dort zu laden. Rückblickend vermute ich, dass Firefox eine eigene Liste vertrauenswürdiger CA Root-Zertifikate mitbringt und nicht auf die OS X-Zertifikate abstellt.

Nach etwas herumpröbeln entschied ich mich, Remember The Milk in Chrome zu öffnen. Der Google-Browser, welcher auch auf WebKit aufsetzt, lud die Applikation ebenfalls nicht, gab aber wenigstens eine deutlich klarere Fehlermeldung von sich:

Google Chrome SSL Error

… server presented a certificate that is not yet valid.

Hä? Irgendetwas war also definitiv mit dem Zertifikat nicht in Ordnung, welches von RTM eingesetzt wird. Ein Klick auf den durchgestrichenen https: zeigte mir Details zur Zertifikatskette an. Ich folgte der Kette bis zum Ursprung des Fehlers und sah folgende Fehlermeldung:

DigiCert High Assurance EV Root CA: This certificate has expired

Das Zertifikat ist seit dem 26. Juli 2014 nicht mehr gültig? Wieso ich in all dieser Zeit keine Probleme mit dem Zugriff auf RTM hatte, ist mir schleierhaft — evtl. haben die Entwickler erst kürzlich auf dieses Zertifikat gewechselt.

Das war die gesuchte Information. Mittels einer Google-Suche stiess ich äusserst rasch auf einen Blog-Artikel von DigiCert, der genau dieses Problem beschrieb und eine einfache Lösung anbot:

Fix for an Expired Intermediate SSL Certificate Chain

In meiner OS X Keychain war wie in den Screenshots von DigiCert beschrieben ein (abgelaufenes) DigiCert High Assurance EV Root CA abgelegt, welches problemlos gelöscht werden konnte. Keychain schliessen, Safari schliessen und neu öffnen — und ich konnte mich wieder in Remember The Milk einloggen.

Tags: , , , , , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 18. Dezember 2013

Den Netatmo PHP API-Client mit weniger strikten SSL-Anforderungen patchen

Vor einigen Tagen hörte mein Raspberry Pi-Dashboard auf, die Werte meiner Netatmo NWS01 Wetterstation für Apple iPhone und Android anzuzeigen.

Auf meinem lokalen Mac funktionierte das Dashboard hingegen problemlos; d.h. ich konnte mittels dem Netatmo PHP API-Client die JSON-Datei mit den aktuellen Messwerten wie Temperatur, Luftdruck und -feuchtigkeit abrufen.

Die genaue Ursache hinter dem Problem kenne ich bis heute nicht, doch ich vermute mit dem jetzigen Wissensstand, dass die Cyon-Ingenieure an der Konfiguration ihrer Server herumgewerkelt haben und dabei unter anderem das Root-Zertifikat entfernt haben, welches der Netatmo API-Client zur HTTPS-verschlüsselten Kommunikation mit den Netatmo-Servern verwendet.

Nachdem ich nämlich die Exception mittels vardump() genauer betrachtete, welche NACurlErrorType zurücklieferte, war der Fall schnell sonnenklar:

...
[message:protected] => SSL peer certificate or SSH remote key was not OK
...

Nun … gut! Was macht man da? Ich habe die Datei NAApiClient.php gepatcht, indem ich cURL mit der auf false gesetzten Option CURLOPT_SSL_VERIFYHOST sage, unverifizierte SSL-Zertifikate kommentarlos zu akzeptieren:

...
        else 
        {
            $opts[CURLOPT_HTTPHEADER] = array('Expect:');
        }
        
        $opts[CURLOPT_SSL_VERIFYHOST] = false;
        
        curl_setopt_array($ch, $opts);
...

Bei einer API wie Netatmo ist diese manuell herbeigeführte Schwachstelle zu verantworten. Ginge es um Mailverkehr oder Online-Banking, würde ich eine solche Option definitiv nicht aktivieren.

Tags: , , , , , , , ,
Labels: Programmierung

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 15. Juni 2008

Wie zwei auskommentierte Zeilen Code SSL-Zertifikate unbrauchbar machten

/* MD_Update(&m,buf,j); */

Quelle: Diff for /openssl/trunk/rand/md_rand.c between version 140 and 141

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen