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.

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.

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

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

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

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

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

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.

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.

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

Der Mailverkehr zur Gegenstelle X wird mit Transport Layer Security (“Applikations-VPN”) verschlüsselt.

Ich bin hin- und hergerissen, ob ich diese vollkommen ungenaue Analogie einfach nur haarsträubend, oder einfach nur genial finden soll, aber tendiere zu letzterem.