Skip to content

SSL Verkehr überwachen

Im letzten Artikel (zur Poodle Lücke) habe ich die klare Empfehlung ausgesprochen SSL 3.0 (und 2.0 sowieso) abzuschalten, wenn es nicht mehr benötigt wird. Hier stellt sich natürlich sofort die Frage: "gibt es noch kritische Verwender von SSL3 in meinem Netz".

Für die Unternehmens-IT kann das eine relativ komplizierte Angelegenheit werden die Owner aller Anwendungen zu befragen. Die Anwendungen zu ermitteln (einfach die Liste der freigeschaltenen Ports in der Firewall durchgehen) ist noch relativ einfach, ob aber die Befragten die Antwort kennen (oder die Frage verstehen) ist eine ganz andere Sache.

SSL Log im Apache aktivieren

Dazu kommt noch das Problem dass in jeder Anwendung die Art und Weise wie man die verwendeten SSL Protokolle sehen kann unterschiedlich ist. Teilweise ist die Funktion nicht aktiviert oder lässt sich nur mit vielen zusätzlichen Debug Meldungen einschalten.

Bei einem Apache httpd ist es eigentlich zwingend das erweiterte SSL Log Format "combinedssl" immer zu verwenden:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %{SSL_PROTOCOL}x %{SSL_CIPHER}x" combinedssl
CustomLog /var/log/httpd/access.log combinedssl

Es ist praktisch, wenn die SSL/TLS Terminierung an möglichst wenigen Stellen erfolgt. Zum Beispiel einen Cluster aus Reverse Proxies oder Load Balancern. Und natürlich sollte für diese Dienste ein entsprechendes Log bereitstehen.

tls-hello-dump

Aber nicht immer gibt es diese Möglichkeit (für alle Anwendungen). Insbesondere nicht bei Client Verbindungen. Es kann von daher notwendig sein auf Netzwerkebene den Datenstrom zu überwachen und eine Statistik zu erstellen (oder die IP Addressen der notorischen SSL3 Verwender manuell nach zu püfen. Es könnte ja auch der unternehmenskritische Bestellfluss des größten Auftraggebers sein). Ich vermute mal ein gutes Network Intrusion Detection System (NIDS) kann diese Statistiken liefern. Ist eine solche Klassifizierung des Traffics aber nicht gegeben, so beginnt die Suche nach einfachen Tools.

Mit tcpdump oder vergleichbaren Sniffern muss man recht viel selbst bauen. Auch ssldump ist hier recht sperrig (und auch nicht sehr aktuell). Das einfachste Tool was ich bisher gefunden habe ist tls-hello-dump von Georg Lukas. Es schreibt pro Handshake 2 Zeilen, eine für die vorgeschlagenen Ciphers des Clients (ClientHello) und eine für die vom Server angenommenen Parameter (ServerHello). Es setzt auf libpcap auf, kann somit auf Linux/FreeBSD einfach eingesetzt werden. Es kann sowohl Verbindungen an das lokale System überwachen als auch Netzwerktraffic (solange der Host auf dem tls-hello-dump läuft am Netzwerkport der in PROMISC geschaltet ist alle Daten sieht).

Hier als Beispiel ein Chrome38/Apache2.2 Handshake sowie ein (unbeantworteter) openssl s_client -ssl3 -connect versuch:

109.192.117.164 195.49.138.57   TLSv1 ClientHello TLSv1.2 :CC14:CC13:
  C02B:C02F:009E:C00A:C009:C013:C014:C007:C011:0033:0032:0039:009C:
  002F:0035:000A:0005:0004:

195.49.138.57   109.192.117.164 TLSv1.2 ServerHello TLSv1.2 cipher C02F

109.192.117.164 195.49.138.57   SSLv3 ClientHello SSLv3 :C014:C00A:C022:
  C021:0039:0038:0088:0087:C00F:C005:0035:0084:C012:C008:C01C:C01B:
  0016:0013:C00D:C003:000A:C013:C009:C01F:C01E:0033:0032:009A:0099:
  0045:0044:C00E:C004:002F:0096:0041:0007:C011:C007:C00C:C002:0005:
  0004:0015:0012:0009:0014:0011:0008:0006:0003:00FF:

Und das ganze noch einmal aufbereitet mit dem ebenfalls beigelegten sed script, welches aus den Hex-codes der Ciphers lesbare Namen macht.

109.192.117.164 195.49.138.57   TLSv1 ClientHello TLSv1.2 :TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256:
  TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:
  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:TLS_DHE_RSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA:
  TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:
  TLS_ECDHE_ECDSA_WITH_RC4_128_SHA:TLS_ECDHE_RSA_WITH_RC4_128_SHA:TLS_DHE_RSA_WITH_AES_128_CBC_SHA:
  TLS_DHE_DSS_WITH_AES_128_CBC_SHA:TLS_DHE_RSA_WITH_AES_256_CBC_SHA:TLS_RSA_WITH_AES_128_GCM_SHA256:
  TLS_RSA_WITH_AES_128_CBC_SHA:TLS_RSA_WITH_AES_256_CBC_SHA:TLS_RSA_WITH_3DES_EDE_CBC_SHA:
  TLS_RSA_WITH_RC4_128_SHA:TLS_RSA_WITH_RC4_128_MD5:

195.49.138.57   109.192.117.164 TLSv1.2 ServerHello TLSv1.2 cipher TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

109.192.117.164 195.49.138.57   SSLv3 ClientHello SSLv3 :TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:
  TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA:TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA:TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA:
  TLS_DHE_RSA_WITH_AES_256_CBC_SHA:TLS_DHE_DSS_WITH_AES_256_CBC_SHA:TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA:
  TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA:TLS_ECDH_RSA_WITH_AES_256_CBC_SHA:TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA:
  TLS_RSA_WITH_AES_256_CBC_SHA:TLS_RSA_WITH_CAMELLIA_256_CBC_SHA:TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA:
  TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA:TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA:
  TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA:TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA:TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA:
  TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA:TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA:TLS_RSA_WITH_3DES_EDE_CBC_SHA:
  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA:TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA:
  TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA:TLS_DHE_RSA_WITH_AES_128_CBC_SHA:TLS_DHE_DSS_WITH_AES_128_CBC_SHA:
  TLS_DHE_RSA_WITH_SEED_CBC_SHA:TLS_DHE_DSS_WITH_SEED_CBC_SHA:TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA:
  TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA:TLS_ECDH_RSA_WITH_AES_128_CBC_SHA:TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA:
  TLS_RSA_WITH_AES_128_CBC_SHA:TLS_RSA_WITH_SEED_CBC_SHA:TLS_RSA_WITH_CAMELLIA_128_CBC_SHA:TLS_RSA_WITH_IDEA_CBC_SHA:
  TLS_ECDHE_RSA_WITH_RC4_128_SHA:TLS_ECDHE_ECDSA_WITH_RC4_128_SHA:TLS_ECDH_RSA_WITH_RC4_128_SHA:
  TLS_ECDH_ECDSA_WITH_RC4_128_SHA:TLS_RSA_WITH_RC4_128_SHA:TLS_RSA_WITH_RC4_128_MD5:TLS_DHE_RSA_WITH_DES_CBC_SHA:
  TLS_DHE_DSS_WITH_DES_CBC_SHA:TLS_RSA_WITH_DES_CBC_SHA:TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA:
  TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA:TLS_RSA_EXPORT_WITH_DES40_CBC_SHA:TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5:
  TLS_RSA_EXPORT_WITH_RC4_40_MD5:TLS_EMPTY_RENEGOTIATION_INFO_SCSV:

Ich hab ein paar Patches beigesteuert die es etwas robuster machen, man muss sich aber vor Augen halten dass das Tool nur sehr einfache Handshakes versteht (diese müssen im Anfang der gefilterten IPv4 Pakete stehen). Schon ein TLS Alert (Warnung: unrecognized_name) verhindert, dass das ServerHello erkannt wird. Außerdem ist aktuell der Parser sehr ungenau was die Überprüfung der Paketformate angeht, es bietet sich also an das Tool nicht als Root auf einem kritischen System laufen zu lassen sondern vielmehr den Traffic mittels tcpdump -w file zu speichern und dann Offline auszuwerten (mit einem User ohne weitere Rechte).

Es sollte auch darauf hingewiesen werden dass es sich hier nur um die Handshakes handelt, Clients die viele erfolglose Verbindungen aufbauen sind in den Zahlen entsprechend überräpresentiert. Wenn eine persistente HTTPS connection tausende Anfragen verarbeitet steht diese nur einmal in der Liste. Ebenso sieht man nicht, ob ein Client, wenn er SSL3 offeriert bekam dieses auch akzeptiert (oder ablehnt).

tls-hello-dump kann nicht mit STARTLS (wie es z.B. in SMTP und IMAP Verwendung findet) umgehen. Das liegt hauptsächlich daran dass es sich nicht damit befasst die gefilterten Pakete zu TCP Strömen zusammenzusetzen. Das macht das Tool leichtgewichtig aber eben auch beschränkt. ssldump wäre für diesen Fall die bessere Wahl.

Compilieren und starten

tls-hello-dump steht auf GitHub als source code zur Verfügung (habe noch kein Binärpaket gesehen) und sollte auf jedem Linux Rechner mit entsprechenden Entwicklungspaketen übersetzbar sein:

git clone https://github.com/ge0rg/tls-hello-dump.git
cd tls-hello-dump/
make clean all
FILTER="tcp port 443 and tcp[tcp[12]/16*4]=22 and (tcp[tcp[12]/16*4+5]=1 or tcp[tcp[12]/16*4+5]=2)"
sudo tcpdump -p -s 1518 -i eth0 -w handshakes.pcap "$FILTER"
./tls-hello-dump handshakes.pcap | sed -f readable.sed 

Oder für die Mutigen: "sudo ./tls-hello-dump eth0 https | sed -f readable.sed"

Der Poodle bellt (SSL Sicherheitsschwäche)

Wieder einmal macht eine Sicherheitslücke mit einem klangvollen Namen die Runde. Poodle ist eine Schwachstelle in SSL 3.0, die sich aber auch auf neuere Clients auswirkt. Ausgelöst wurde das ganze durch ein Paper der Google Sicherheitsforscher Bodo Möller, Thai Duong und Krzysztof Kotowicz. Warum Sites wie Twitter mit der Abschaltung von SSL 3.0 reagieren möchte ich hier kurz darstellen.

Zuerst einmal eine Feststellung: SSL 3.0 (das Secure Socket Layer Protokoll in der Version 3.0 von 1996, nachträglich in RFC6101 dokumentiert) ist (trotz der Versionsnummer) der Vorgänger von TLSv1, TLS 1.1 oder dem aktuellen TLS 1.2 (RFC5246). Es hat eine Reihe von Sicherheitsproblemen und Unschönheiten und sollte schon länger nicht mehr verwendet werden.

Die Poodle Lücke hat das nur bestätigt: Durch eine ungeschickte Verwendung von Füll-Bytes bei dem CBC Modus (verwendet für DES, 3DES und RC2) kann ein Angreifer der mehrere SSL Anfragen beeinflussen und abhören kann, auf den Inhalt schließen. Diese Schwachstelle ist ähnlich zu der bereits vor einiger Zeit bekannt gewordenen BEAST Lücke.

Es sind verschiedene Situationen denkbar, bei denen diese Lücke ausgenutzt werden kann, aber im Web Browser Umfeld ist es dank JavaScript und Userinteraktion am Einfachsten.

Für SSL 3.0 kann dies nicht behoben werden (und selbst wenn wäre es einfacher direkt TLS 1.2 zu verwenden das die Lücke nicht hat). Bei Clients und Server die SSL 3.0 noch einsetzen könnte man die betroffenen CBC Ciphers abschalten, das ist aber leider keine sehr attraktive Lösung da sonst nur noch die eher unsichere RC4 Stromchiffre verwendet werden könnte.

SSL 3.0 muss sterben

Ohne jetzt nun näher zu bewerten wie einfach oder wie schwer die Lücke in welcher Situation ausgenutzt werden kann sind sich eigentlich alle einig: SSL 3.0 sollte nicht mehr verwendet werden und kann in Clients und Servern endlich abgeschaltet werden. Dies nimmt somit auch schon die Empfehlung vorweg und den Weg gehen alle mehr oder weniger schnell.

Ob man die Unterstützung für SSL 3.0 abschalten kann hängt vor allem damit zusammen ob alle potentiellen Gegenstellen ein gemeinsames neueres Protokoll sprechen. Als Web Server Betreiber stellt sich die Situation recht einfach dar: alle Clients außer Internet Explorer 6 auf einem Windows XP (und älter) können mindestens TLSv1, die meisten auch schon 1.1 oder 1.2 (wobei es nicht alle angeschaltet haben).

Internet Explorer 6 muss brennen

Aus einer ganzen Reihe von Gründen ist es eigentlich nicht mehr wünschenswert IE 6 zu benutzen, und schon gar nicht zu fördern. Da es selbst für Anwender die auf XP festsitzen Alternativen gibt (darunter Firefox und IE 7-8) sollte man inzwischen keinen Gedanken verschwenden und SSL 3.0 in öffentlichen Web Servern sofort abschalten.

CloudFlare, ein CDN und Cloud Security Dienstleister der weltweit viele Websites schützt und ausliefert hat Statistiken veröffentlicht, sie werden SSL 3.0 abschalten:

Across our network, 0.09% of all traffic is SSLv3. For HTTPS traffic, 0.65% across our network uses SSLv3. The good news is most of that traffic is actually attack traffic and some minor crawlers. For real visitor traffic, today 3.12% of CloudFlare's total SSL traffic comes from Windows XP users. Of that, 1.12% Windows XP users connected using SSLv3. In other words, even on an out-of-date operating system, 98.88% Windows XP users connected using TLSv1.0+ — which is not vulnerable to this vulnerability.

Wenn man weg geht von dem reinen Webbrowser/Server Umfeld, so ist die Unterstützung von neueren Protokollen nicht ganz so klar. Allerdings ist TLSv1 bereits in Java SE 1.4 enthalten, und so dürfte die Anzahl der Endpunkte die kein TLS können sich auf spezielle Embedded Hardware (und falsch konfigurierte Software) beschränken. Im System-to-System oder MFT Umfeld ist das Risiko der POODLE Lücke deutlich geringer (weil der interaktive Einfluss fehlt), aber auch hier wäre es ratsam und Risikofrei SSL 3.0 einfach abzuschalten.

SSL Fallback

Wenn sowohl Client als auch Server das TLS Protokoll sprechen so können Sie dies beim Verbindungsaufbau erkennen, und die gemeinsam gesprochene beste Version aushandeln. Dank Überprüfung dieses Handshakes ist es einem Angreifer auch nicht möglich der jeweils anderen Seite eine niedrigere Version vorzugaukeln.

Allerdings gibt es bei der Sache einen Haken: da manche Clients wenn ein Verbindungsaufbau mit einem TLS Handshake nicht klappt das ganze erneut mit einer älteren Version versuchen (out-of-band protocol fallback). Ein Angreifer muss damit nicht den ersten Handshake ändern (was TLS erkennt), sondern nur aufhalten (in der Praxis passiert dies sogar bei Überlastung ganz ohne Angreifer, was ebenso nicht erwünscht ist). Wenn der Client einen erneuten Versuch unternimmt und dabei nur SSL 3.0 ankündigt, so gelingt der Handschlag zwischen Client und Server mit einer unnötig alten (und unsicheren) Protokoll Version.

Dieser Downgrade Angriff ist Bestandteil der POODLE Lücke (wenn neuere Client und Server verwendet werden). Zur Verhinderung davon gibt es mehrere Möglichkeiten:

  • Clients verzichten auf den Fallback handshake und verlassen sich auf die TLS Versionslogik (dazu gehört zum Beispiel Java, wenn der Entwickler die Logik nicht selbst implementiert hat)
  • Auf Clients und Servern unsichere Protokollversionen gar nicht anbieten (SSL 3.0 abschalten)
  • Ein neuer Mechanismus bei dem ein Client der einen kompatiblen Handschlag versucht eine Markierung (die nicht entfernt werden kann) mitschickt, dass es ein Kompatibilitätsversuch ist. Server die von dieser Markierung wissen würden den Handschlag dann ablehnen (wenn sie eine neuere Version sprechen).

Letzteres wird TLS_FALLBACK_SCSV genannt, es handelt sich um eine sogenannte Signalling Cipher, die aktuell in Diskussion ist (und Google Chrome sendet dies schon einige Zeit, Firefox ab Version 35). Damit diese funktionieren kann, müssen aber die Server diese auch kennen. Die Erweiterung ist umstritten, denn für den Fall SSL 3.0 ist ein abschalten einfacher, und für zukünftige TLS Protokoll sollten die Clients einen Fallback einfach gar nicht durchführen.

TLSv1

So positiv wie es zu sehen ist, dass sehr viele Lösungen mindestens TLSv1 sprechen, so ist dies auch ein deutliches Warnzeichen: TLSv1 ist auch schon stark angekratzt. Die meisten wirklich wünschenswerten Verbesserungen sind erst in TLSv1.1 oder 1.2 zu finden. Schon heute können Sicherheitsbewusste Anbieter TLSv1 abschalten (Der Mozilla Server Side TLS Security Guide nennt dies „Modern Compatibility“). Es ist entsprechend anzuraten gleich jetzt zu evaluieren ob man auch gleich TLSv1 verbannen möchte und sicherzustellen dass TLSv1.2 angeboten wird (und so konfiguriert ist, dass es Perfect Forward Secrecy unterstützt und auf Zertifikaten basiert die mit SHA2 statt SHA1 oder gar MD5 signiert sind).

Zum weiterlesen