#!/bin/blog

January 26, 2013

Kinderzimmer-Crypto by Telekom & Verisign

Filed under: Internet, Sicherheit — Tags: , , — martin @ 3:49 pm

Ich muss ja gestehen, obwohl ich mich sporadisch mit Sicherheitsgedöns auseinandersetze, war mir bisher nicht bewusst, dass der Zugriff auf das Konfigurations-Interface meines VDSL-Routers “Speedport W 722V” SSL-verschlüsselt erfolgt. Bis heute der Browser eine Fehlermeldung auswarf. Mal schauen:

20130126151658

Was ist hier passiert? Das SSL-Zertifikat ist vor 3 Wochen nach 4 Jahren Gültigkeit abgelaufen. Naja. Kommt vor. Aber Moment? Nochmal genau hinschauen:

Issuer: O=VeriSign Trust Network, OU=VeriSign, Inc., OU=VeriSign International Server CA – Class 3, OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
Validity
Not Before: Jan  7 00:00:00 2009 GMT
Not After : Jan  6 23:59:59 2013 GMT
Subject: C=DE, ST=Hessen, L=Darmstadt, O=Deutsche Telekom AG, OU=P&I PSO/DCS, CN=speedport.ip

Die Deutsche Telekom besorgt sich also beim SSL-Weltmarktführer Symantec/Verisign ein SSL-Zertifikat, ausgestellt auf einen Fantasie-Hostnamen, mit fetten 4 Jahren Laufzeit, obwohl eigene SSL-Root-Zertifikate der Telekom in jedem Browser hinterlegt sind. Da wollten die hausinternen Kollegen wohl nicht mitspielen, so dass man irgendeinen windigen Deal mit Verisign abwickeln musste. Abenteuerlich Nummer 1.

Zum anderen hat der Telekom-Support im hauseigenen Forum bereits verlautbart, dass für solche alten Geräte kein Firmware-Update kommen wird. Ist ja auch nur ein VDSL-Router, sowas benutzt heute bestimmt niemand mehr. Abenteuerlich Nummer 2:

20130126153228

Verlinkt ist ein Artikel, in dem beschrieben ist, wie man den Zertifikatshinweis im Browser dauerhaft unterdrücken kann. Abenteuerlich Nummer 3.

Die Deutsche Telekom wirft also auf ein Web-Interface im privaten LAN, oder gar im verschlüsselten WLAN, eine aufgrund des fehlenden Angriffsszenario sowieso schon unnötige Transportverschlüsselung drauf, versucht es mit dieser Verisign-Nummer halbwegs richtig zu machen, hat aber keinen Plan für den Fall, dass das Gerät länger als 3-4 Jahre beim Kunden im Einsatz ist. (Das ist nebenbei bemerkt der Grund, warum ich meinen Kunden von länger als 1 Jahr laufenden SSL-Zertifikaten abrate: Schon allein, damit man nicht in die Versuchung kommt, keinen Prozess für den Zertifikatsablauf zu etablieren.)

Als Workaround werden die Telekom-Kunden schließlich mit einer Klickanleitung trainiert dafür, wie man den Browser zwingt, auf Webseiten mit kaputten SSL-Zertifikaten zuzugreifen. Diese Zivilisationstechnik kann man ja immer mal gebrauchen. Dafür herzlichen Dank.

Endnutzer zu einem verantwortungsvollen und aufmerksamen Umgang mit solchen Sicherheitsverfahren zu erziehen, geht aber anders, liebe Telekom.

Advertisements

June 18, 2011

WhatsApp: Protokollanalyse

Filed under: Internet — Tags: , , — martin @ 12:32 pm

Die Geschichte über die “Datenkrake WhatsApp” hat mir keine Ruhe gelassen, so daß ich einen Laboraufbau für eine kooperative Man-in-the-Middle-Operation mit Squid 3.1 aufgesetzt habe. Dank dessen Features für Content-Filter, Virenscan usw. konnte ich die SSL-Kommunikation von WhatsApp entschlüsseln.

Damit bin ich zu einer Handvoll neuer Erkenntnisse gekommen.

WhatsApp setzt beim Aufbau der Favoritenliste einen POST-Request an https://sro.whatsapp.net/client/iphone/iq.php ab. Dieser enthält die folgenden Informationen.

Im HTTP-Header:

  • Die Version von WhatsApp.
  • Die Betriebssystemversion des iPhone.
  • Die Hardwareversion des iPhone.

Im HTTP-POST-Request:

  • Die eigene Telefonnummer.
  • Die eigene Ländervorwahl.
  • Alle im Telefonbuch gefundenen Telefonnummern in Ziffernform ohne Trenn- oder Sonderzeichen, mit oder ohne Ländervorwahl, wie im Adreßbuch eingetragen.

Bei WhatsApp antwortet ein lighttpd 1.4.28 mit PHP 5.3.5. Dieser beantwortet den POST-Request mit einem XML-Block, der pro gefundener Gegenstelle ein Dictionary mit den folgenden Werten enthält:

  • S – Die vom Benutzer eingegebene Status-Message.
  • T – Das Alter der Status-Message in Sekunden.
  • JID – Die Telefonnummer des Benutzers mit Länderkennnzeichen ohne führendes +.
  • P – Die Telefonnummer des Benutzers in “wählbarer” Form mit Länderkennzeichen und führendem +.
  • NP – Entweder nicht gesetzt oder mit dem Wert true. Funktion unbekannt.

Die Faktenlage ist damit wie folgt ausgebaut:

  • Um die Favoritenliste zu generieren, wird keine Übertragung des gesamten Adressbuchs vorgenommen.
  • Es werden jedoch alle im Adressbuch enthaltenen Telefonnummern übertragen, um zu prüfen, ob dahinter ein WhatsApp-Account steckt.
  • Außer den Telefonnummern wird keine Information übertragen.

Die Kommunikation während des Chat selbst habe ich nicht betrachtet.

Ihr könnt euch jetzt euren Teil denken. Die im vorigen Post aufgestellten Vermutungen über die Kommunikation sind damit bestätigt, bis auf das Hashing, das im Fall von Telefonnummern aber vermutlich eher eine Verschleierung wäre.

February 2, 2010

Dealing with lengthy SSL certificate chains

Filed under: Security — Tags: , , , , — martin @ 4:16 pm

Comodo delivers the cheapest widely-recognized certificates (available e.g. via psw.net), second only to the famed StartSSL Free CA, which I haven’t had the guts to try out so far. What I got from Comodo, is my server cert, along with no less than three intermediate certificates:

AddTrustExternalCARoot.crt
issuer= /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
subject= /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root

UTNAddTrustServerCA.crt
issuer= /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
subject= /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware

PositiveSSLCA.crt
issuer= /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
subject= /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=PositiveSSL CA

Server.crt
issuer= /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=PositiveSSL CA

You can obtain this information by running, e.g.:

for c in $(ls *crt); do echo -e "\n$c"; openssl x509 -issuer -subject -noout -in $c; done

Note how I have ordered them from the root certificate on top to the server certificate on the bottom, each being the issuer of the succeeding one. Did I say root certificate? Good news then: AddTrust is the root certificate, hence it does not need to be deployed, which leaves me with a chain of two.

I will need to deploy the certificates into Postfix and Dovecot, which use an all-in-one file that contains the complete chain, including the server certificate. Other servers, such as the Apache webserver, use a server certificate file and a separate file containing the intermediate certificates. Which is the method I prefer. But you just can’t always get what you want. 😉

I learned the hard way that certificate order does matter. RFC 5246 states:

The sender’s certificate must come first in the list. Each following
certificate must directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority may optionally be omitted from the chain,
under the assumption that the remote end must already possess it
in order to validate it in any case.

Thus, the all-in-one file needs to start with the server certificate, followed by the certificate that issued the server certificate, all the way down to the one that is farthest away from the server certificate: 1) Server, 2) PositiveSSLCA, 3) UTNAddTrustServerCA

For servers that use a separate intermediate file, the order is the same, with the difference that the server certificate resides in its own file.

I recommend to maintain the subject and issuer information of all components of the all-in-one file so it won’t have to be dissected at a later point in order to understand what it contains. My starting point is the server cert, to which I will append the intermediate certs:

1) Locate the issuing certificate of the server cert (-> output above) and append the respective certificate to the server cert.
2) Locate the issuing certificate of the previously appended certificate and append it to the server cert.
3) Repeat until the root CA certificate has been reached.

In my case:
openssl x509 -in server.crt -subject -issuer > server-allinone.crt
openssl x509 -in PositiveSSLCA.crt -subject -issuer >> server-allinone.crt
openssl x509 -in UTNAddTrustServerCA.crt -subject -issuer >> server-allinone.crt

Now I have a handy file ready for deployment:

subject= /OU=Domain Control Validated/OU=PositiveSSL/CN=server
issuer= /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=PositiveSSL CA
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject= /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=PositiveSSL CA
issuer= /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject= /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
issuer= /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

The main point is that you must understand how the certificates relate to each other. The issuer and subject fields are the key all the way through the procedure.

November 12, 2009

IMAP on the iPhone with SSL client certificates

Filed under: iphone — Tags: , , , — martin @ 11:02 pm

The IMAP server in my office is configured to not simply accept username/password authenticated connections from the internet. As an additional security measure, it requires the client to present a valid SSL client certificate, issued by the internal CA, resulting in mutual SSL authentication.

The Mail client on the iPhone, on the other hand, does not support SSL client certificates. While it is possible to deploy a client certificate using the iPhone configuration utility, this cert will only be presented to web servers, but not to mail servers.

My workaround is to use stunnel, the universal SSL wrapper, on the iPhone. This, of course, requires the iPhone to be jailbroken. I’ll leave the jailbreak and installation of stunnel as an excercise to you. 🙂

I’m running stunnel as the “mobile” user, thus all the required files reside in /var/mobile. The files are:

– The stunnel configuration: /var/mobile/stunnel.conf
– The SSL certificate: /var/mobile/cert.pem
– The key matching the SSL certificate: /var/mobile/key.pem

Stunnel is configured as an SSL client. The commented-out lines may be useful for troubleshooting. I have added 10000 to the regular IMAP and SMTP ports so they are beyond the privileged port range that may only be used by root.

cert=/var/mobile/cert.pem
key=/var/mobile/key.pem
pid = /var/mobile/stunnel.pid
sslVersion = TLSv1
# Resolve server hostname at every reconnect,
# not only on startup (for dyndns!):
delay = yes
#foreground = yes
#debug = 7

[imap]
accept=127.0.0.1:10143
connect=example.dyndns.org:993
client=yes

[smtp]
accept=127.0.0.1:10025
connect=example.dyndns.org:465
client=yes

My key is password protected, thus I start stunnel from Mobile Terminal after bootup:

stunnel stunnel.conf

Having a method for starting stunnel automatically with passphrase-less keys would be nice, but has no priority for me. Using a LaunchDaemons entry for this shouldn’t be a problem anyway.

The mail settings on the iPhone are configured to access IMAP and SMTP on localhost, port 10143 and 10025, respectively. SSL encryption is turned off for both.

This setup is surprisingly robust. The current running stunnel daemon has been started 4 days ago and has already survived a few changes of the dynamic IP address of the mail server. I have not had a single hiccup since I figured out that I need the “delay=yes” option in the configuration file to keep up with DynDNS changes. If your mail server isn’t on a dynamic IP address, all the better.

July 10, 2008

Verisign und OCSP

Filed under: Security — Tags: , , , , — martin @ 9:36 pm

Was mir heute nicht so gut in den Kram gepaßt hat:

$KUNDE warf mir nochmal 50 SSL-Zertifikate vor die Füße, zwecks Überprüfung, von denen 38 für das Debian-SSL-Problem empfänglich waren. Aber ich hab ja mittlerweile Routine.

Also wurden neue CSRs generiert, welche er bei Verisign (RSA/”Secure Server Certification Authority”) zum Re-Issue eingereicht hat. Minuten später kam der erste mit einer Firefox-Fehlermeldung um die Ecke:

Die verantwortliche Konfigurationsoption war dann auch schnell identifiziert:

Willkommen im Dilemma. So schwer es mir fällt, zu bestreiten, daß diese Voreinstellung in Firefox 3.0 auf den Tag genau zur rechten Zeit kommt, so unangebracht finde ich es, daß Verisign ein Zertifikat, dessen Austausch es gerade mal so mit Ach und Krach in die Mailbox der Administratoren geschafft hat, sofort per OCSP als gesperrt propagiert.

Gerade weil es jetzt so weit ist, daß OCSP, das Online Certificate Status Protokoll, tatsächlich genutzt wird, wäre eine gewisse Galgenfrist von mindestens 1 Tag bis vielleicht 1 Woche mehr als angemessen. Insbesondere bei einer Massenaktion mit einem Umfang von mehreren Dutzend Zertifikaten ist mir persönlich nämlich schleierhaft, wie man die Zertifikate im Rahmen von Change-Prozessen derart schnell auf die Produktivserver katapultieren soll.

Wenn man nochmal 30 Sekunden drüber nachdenkt, kommt man übrigens zur Erkenntnis, daß es auch mit einem einzigen Zertifikat kaum sauber hinzubekommen ist. Auf einer hochgradig produktiven SSL-Site muß man, wenn die CA einen OCSP Distribution Point bereitstellt, in Zukunft auf den Re-Issue verzichten und additiv ein neues Zertifikat dazukaufen, um es überhaupt ohne Ausfall tauschen zu können. Ob das wirklich im Sinne des Erfinders ist?

July 2, 2008

SGC(“Step-Up”)-Zertifikate

Filed under: Security — Tags: — martin @ 10:12 pm

Verlautbarung von heute an einen Kunden, der SGC-Zertifikate einsetzen will, um möglichst lückenlos alle Browser zu unterstützen:

“Vom Einsatz von Step-Up/SGC-Zertifikaten, die die Verwendung von Browsern ermöglichen, die der vor dem Jahr 2000 gültigen Exportbeschränkung der USA unterliegen, wird abgeraten. Es wird empfohlen, die Unterstützung veralteter Browser, für die keinerlei Updates mehr verfügbar sind, aus Sicherheitsgründen einzustellen.”

Mit den SGC-Zertifikaten (“Server Gated Cryptography“), je nach Marketingmasche auch “Step-Up” genannt, ist das so: Bis Anfang 2000 gab es seitens der USA diese beschränkte Exportbeschränkung, nach der “starke” Verschlüsselung als Kriegswaffe zu behandeln war und deshalb nur unter strengsten Auflagen aus den USA ausgeführt werden durfte. Nun kamen aber alle halbwegs relevanten Web-Browser aus USA (Netscape, Internet Explorer). Wegen der Ausfuhrbeschränkung war in diesen die Schlüssellänge für SSL auf 40 Bit begrenzt. Weil man aber auch schon in den 1990ern Knete mit E-Business machen wollte, gab es verschiedene CAs, die mit Segen der US-Regierung für Banken & Co. Zertifikate ausstellten, bei deren Anblick der Browser seine Exportbeschränkung vergaß und auf 128 Bit Schlüssellänge umschaltete. Das war dann die “Step-Up”-Security.

Die Exportbeschränkung ist 2000 gefallen, aber die CAs bieten die SGC-Zertifikate noch immer an und lassen sie sich fürstlich bezahlen. Thawte nimmt für ein Jahr Laufzeit z.B. lässige 699 US-Dollar und haut mächtig auf die Sahne:

Provide the best encryption available for each site visitor. Without an SGC-enabled certificate on your site, your visitors using certain older browsers and many Windows 2000 users will only receive 40- or 56-bit encryption.

Ich halte ja nicht extrem viel von diesem hysterischen Getue, nach dem jedes irgendwo greifbare Security-Update sofort installiert werden muß, auch wenn es für einen obskuren Teil des Betriebssystems gilt, den man im ganzen Leben noch nicht benutzt hat. Hier geht es nun aber um Web-Browser und somit um die Killerapplikation der letzten Dekade. Wer SGC einsetzt, unterstützt aktiv folgende Browserversionen:

  • Internet Explorer 5 (Aktuelle Version: 7)
  • Netscape 4 (Aktuelle Version: 9, Entwicklung ist eingestellt)
  • Opera 3 (Aktuelle Version: 9)

Als gut abgehangener Linux-User bin ich es ja gewohnt, jahrelang aktiv von irgendwelchen Webseiten ausgesperrt worden zu sein. Solche Unverschämtheiten vergißt man nicht. In diesem Fall ist es allerdings mehr als angebracht, die eigenen Kunden vorm Gebrauch dieser antiken Exploit-Schleudern zu schützen.

Ich mußte mich da auch erstmal reinlesen, da ich mich nicht erinnern kann, selbst Erfahrungen damit gesammelt zu haben, abgesehen von einem total inoffizellen Patch für den Netscape Navigator, mit dem man diese Exportgeschichte irgendwie global abschalten konnte.

Der Kunde von oben zeigt auf seiner Homepage übrigens ein Flash-Video an und weist ausdrücklich darauf hin, daß die Seite nur mit IE ab Version 6, Netscape ab Version 6 oder Mozilla ab Version 1.0 benutzbar ist. Das ist dann der Punkt, an dem die Sache ins Absurde übergeht. 😉

June 21, 2008

Surfin’ the post 5/13 world.

Filed under: Security — Tags: , , , — martin @ 11:27 pm

Das audit-ssl-Script (.tar.gz) ist funktional in der Lage, Seiten mit angreifbaren SSL-Zertifikaten zu erkennen. Komfortabler und plattformübergreifend tut es aber die SSL Blacklist Extension für den Firefox:

Auch zu empfehlen als kleiner Warnschuß an Anwender, die sich weigern, Zertifikate auszutauschen: “Firefox zeigt bereits eine Warnmeldung an. Was wirst Du Deinen Kunden erzählen, wenn der Internet Explorer das nach dem nächsten Microsoft-Patchday ebenfalls macht?”

June 4, 2008

OpenSSL: Key, CSR und Zertifikat auf Übereinstimmung prüfen

Filed under: Security — Tags: , — martin @ 6:17 pm

Der 13. Mai hat mein ohnehin schon verpfuschtes Leben in eine verdammte Hölle aus Zertifikaten, Keys und Certificate Signing Requests verwandelt. Und dann heute mal was neues: Beim Kunden wollte ein Webserver mit einem der von der CA neu ausgestellten Zertifikate nicht mehr starten. Key und Zertifikat paßten nicht zusammen.

Wie man ermitteln kann, ob ein Zertifikat zum CSR paßt, klingt z.B. hier oder in der Apache-FAQ an:

# openssl x509 -in example.com-cert.pem -noout -modulus | openssl sha1
5ba93c9db0cff93f52b521d7420e43f6eda2784f
# openssl req -in example.com-req.pem -noout -modulus | openssl sha1
5ba93c9db0cff93f52b521d7420e43f6eda2784f

So ließ sich dann recht einfach ermitteln, daß die CA tatsächlich nicht den neuen, sondern einen dort gespeicherten alten Certificate Signing Request für die Neuausstellung des Zertifikats benutzt hatte. Worauf dann unmittelbar die Frage folgte, ob davon vielleicht auch noch andere der 50 neu ausgestellten Zertifikate betroffen sein könnten.

Also mußte ein Script her, das weniger sperrig war als die o.g. OpenSSL-Aufrufe, und dem man vorzugsweise nicht sagen muß, um was es sich bei der jeweils präsentierten Datei handelt:

#!/bin/sh
# Script: ssl_matchchk
for i in "$@"
do
  openssl x509 -in $i -noout >/dev/null 2>&1 && 
    echo `openssl x509 -in $i -modulus -noout 2>/dev/null | openssl sha1` $i
  openssl req  -in $i -noout >/dev/null 2>&1 && 
    echo `openssl req  -in $i -modulus -noout 2>/dev/null | openssl sha1` $i
  openssl rsa  -in $i -noout >/dev/null 2>&1 && 
    echo `openssl rsa  -in $i -modulus -noout 2>/dev/null | openssl sha1` $i
done

Mit diesem Script, dem es zugegebenermaßen an einer sauberen Fehlerbehandlung fehlt, und mit einem kleinen weiteren Shell-Einzeiler ließ sich dann relativ flott sicherstellen, daß nur ein einziges Zertifikat von einer solchen Verwechslung betroffen war. Schwein gehabt. 😉

February 18, 2008

Perlen vor die Säue

Filed under: Security — Tags: , — martin @ 6:47 am

Neulich, im Rahmen der Dovecot-Bastelaktion, hatte ich übrigens mal in den Logs geschaut, wie groß der Anteil meiner User ist, die SMTP und POP3 mit SSL benutzen.

Er beträgt genau: Null.

In Sachen Sicherheit liegt die Arbeit wirklich auf der Straße. Dumm, daß es sich dabei nicht um so einfachen Pillepallekram wie z.B. das Erfinden unknackbarer Verschlüsselungsalgorithmen handelt, sondern um die wirklich harte Überzeugungsarbeit an der Basis, mit der man die Leute dazu bringen müßte, auch mal wirklich das Kreuzchen bei “SSL benutzen” zu setzen und nachzufragen, wenn es dabei zu Unstimmigkeiten kommt.

Wenn ich mir dann auch noch anschaue, wie viele selbstsignierte und seit Jahren abgelaufene Zertifikate selbst auf Mailexchangern im Unternehmensbereich unterwegs sind, wird mir Angst und Bange. Und mit den Gammelzertifikaten sind noch die “guten” Installationen. Bei denen ist nämlich die Infrastruktur schon da und sie müßten nur mal für eine Handvoll Euro ein ordentliches Zertifikat verpaßt bekommen.

E-Mail-Sicherheit ist meiner Auffassung nach das ganz große Stiefkind in den Firmen. Anders als beim Webbrowser, wo das kleine Vorhängeschloß angezeigt wird, sieht nämlich niemand, wenn die Sicherheit der E-Mails auf die leichte Schulter genommen wird. Und so werden dann die per teurem SSL-Zertifikat vom Webserver empfangenen persönlichen- und Kreditkartendaten munter im Klartext per Mail versendet und unverschlüsselt mit Plaintext-Kennwort per POP3 abgeholt. Ist bisher ja immer gutgegangen.

August 15, 2007

PEM nach P12 konvertieren

Filed under: Internet, Security — Tags: , , — martin @ 9:09 am

Um Zertifikate aus der OpenSSL-Welt mit Mozilla nutzbar zu machen:

openssl pkcs12 -export -in my.cert.pem -inkey my.key.pem -out my.p12

Zur Info auch noch der Rückweg von P12 nach PEM:

openssl pkcs12 -in my.p12 -out my.combo.pem

Older Posts »

Blog at WordPress.com.