RIP RC4

Der RFC 7465 verbietet die Verwndung von RC4 in TLS, was eine längst überfällige Entscheidung ist. Ich bin aber wirklich gespannt, wie schnell dieser RFC umgesetzt wird und RC4 aus dem Internet verschwindet. Vor allem wenn man bedenkt, dass selbst Firmen wie Google immer noch RC4 verwenden (und sogar auch SSLv3).

Für ASA-Admins ist (spätestens) jetzt der Zeitpunkt, die SSL-Einstellungen anzupassen. Die könnten so aussehen:

ssl server-version tlsv1-only
ssl encryption dhe-aes128-sha1 dhe-aes256-sha1 aes128-sha1 aes256-sha1

Und für alle anderen Crypto-Einstellungen sind natürlich immernoch die Empfehlungen von bettercrypto.org zu empfehlen.

Als nächstes könnte jetzt bitte PPTP sterben!

RIP RC4

pfSense, OPNsense

pfSense ist neben der Cisco ASA meine zweite bevorzugte Firewall. Sie funktioniert einfach problemlos, ist open Source und unterstützt in der neuesten Version (endlich) auch IKEv2.
Eine manchmal zu hörende Kritik an pfSense ist, dass die Software auch von einer amerikanischen Firma kommt.
Als zahlender Nutzer hat man noch ein paar „Premium“-Feature bekommen. Z.B. ein Cloud-Konfiguratiuons-Backup. Das hat mir dann hauptsächlich nicht gefallen. (Und bevor sich jemand wundert; Ja, Meraki gegenüber bin ich auch noch etwas voreingenommen, wenngleich ich die Geräte selbst klasse finde).

Seit kurzem gibt es OPNsense, ein Fork von pfSense. Dieses System wird unter der Leitung einer niederländischen Firma entwickelt und wirkt auf den ersten Blick wie pfSense mit einer moderneren GUI. OPNsense soll einen festen Release-Cycle mit zwei neuen Versionen pro Jahr bekommen. Auch wenn mir die Weiterentwicklung von pfSense teilweise doch zu langsam war, bin ich mir trotzdem nicht sicher ob feste Release-Zyklen wirklich sinnvoll für ein Security-Device sind. 

Aber insgesamt ist OPNsense sehr interessant und ich werde mir das System mal genauer anschauen, vielleicht ist es ja (jetzt schon oder später) eine pfSense-Alternative.

pfSense, OPNsense

Safer Internet Day (SID)

Heute ist Safer Internet Day. Dabei geht es hauptsächlich darum, Kinder und Jugendliche den verantwortungsbewussten und sicheren Umgang mit Online-Technologien näherzubringen. Dazu passt auch gut der Heise-Beitrag „Datenschutzbeauftragter: Schülern fehlt Medienkompetenz“ von vorgestern.

Aber Safer Internet kann so viel mehr sein. Ein paar Anregungen:

  • Überzeuge jemanden endlich sein Windows XP auf eine supportete Windows-Version upzudaten.
  • Aktiviere auf einer Webseite HTTPS.
  • Nutze Threema als Messenger. (Ja, auch mit closed-source kann man die Sicherheit erhöhen).
  • Verschlüssele E-Mail. Wie das geht kann man gerade in einem Online-Kurs des HPI lernen.
  • Deinstalliere Adobe Flash wenigstens im Haupt-Browser.

Und dann gäbe es da bestimmt nch vieles, vieles mehr …
Ein Vorschlag noch für die IT-Admins in den Firmen:

  • Sorge dafür, dass auch die Firewalls ab und an mal upgedated werden und die Configs überprüft werden. Denn was ich da typischerweise sehe ist immer wieder abenteuerlich.

Safer Internet Day (SID)

TLS kränkelt

Dass TLS (Transport-Layer-Security) diverse Schwächen hat, ist lange bekannt. Die meisten davon sind in dem Standard TLSv1.2 ausgeräumt, leider wird diese Version noch nicht überall unterstützt.
Der RFC 7457 fasst die wichtigsten bekanten Angriffe auf TLS zusammen:
Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)
Interessant zu lesen sind in dem Zusammenhang auch der Draft 
Recommendations for Secure Use of TLS and DTLS – draft-ietf-uta-tls-bcp-08
und natürlich das Applied Crypto Hardening PDF von bettercrypto.org.

TLS kränkelt

Wickr hat “Military Grade Encryption”

Heise berichtet heute von dem neuen Messenger Wickr. Und auf dem Screenshot springt einem gleich ein “Military Grade Encryption” in die Augen. Da muss ich immer an einen Satz von Andrew Fernandes denken (ähnliche Aussagen kommen auch von anderen Security-Leuten):

It’s sort of like saying the phrase “military grade encryption.” Whenever you´re dealing with a security product and somebody says it´s military grade encryption your bullshit detector should really go off.

Wickr hat “Military Grade Encryption”

SSH-Client-Konfiguration unter MacOS

Beim letzten Beitrag zur SSH-Konfiguration unter Cisco IOS und Cisco ASA fiel mir noch ein, dass man über sinnvolle Anpassungen der Client-Konfiguration auch mal schreiben sollte. Zumindest unter MacOS (und mindestens auch unter Debian und älterem Ubuntu Linux) wird standardmäßig nicht immer die optimale Kryptographie verwendet.
Die SSH-Parameter können an zwei Stellen konfiguriert werden:

  • systemweit unter /etc/ssh_config
  • per User unter ~/.ssh/config

In der systemweiten SSH-Config befinden sich z.B. die folgenden drei Zeilen, die weite Teile der verwendeten Kryptographie bestimmen (genauer gesagt zeigen sie die Defaults):

#Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour
#KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
#MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-sha1-96,hmac-md5-96,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96

Was kann/sollte man ändern:

Ciphers

Wer keine legacy Systeme zu pflegen hat, der könnte alle nicht-AES ciphers entfernen. Aber Geräte wie 2950 Switche sind halt auch noch ab und an anzutreffen. Daher muss man in so einem Fall 3des-cbc auch konfiguriert haben. Die Cipher-Zeile könnte dann folgendermaßen aussehen:

Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc,3des-cbc

Laut Manpage (und basierend auf der sowohl unter Mavericks und Yosemite verwendeten OpenSSH-Version 6.2p2) sollten auch die moderneren GCM-Typen unterstützt sein. Wenn die konfiguriert sind, meldet der SSH-Client aber „Bad SSH2 cipher spec“.
Beim Zugriff auf Cisco Router und Switche kommen typischerweise die CBC-Versionen zum Einsatz, da CTR erst ab IOS 15.4 unterstützt ist.

KexAlgorithms
Hier wird der Key-Exchange gesteuert. Meine Konfig-Zeile auf dem Mac ist die folgende:

KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

Die ElipticCurve Algorithmen habe ich entfernt, da diese im Verdacht stehen Backdoors zu beinhalten. Die vermutlich vertrauenswürdige curve25519 von D.J. Bernstein ist erst in OpenSSH 6.6p1 enthalten. Diese werde ich bei Verfügbarkeit mit aufnehmen. Als letztes in der Zeile ist weiterhin ein Group1-Exchange (768 Bit), der für Legacy-Geräte benötigt wird.

MACs
Am meisten stört mich, dass eine MD5-Methode die höchste Priorität hat, gefolgt von einer SHA1-Methode. Da sollte die Reihenfolge angepasst werden:

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,hmac-sha1

Interessant sind die etm-MACs. Dazu ein kleiner Ausflug in Message Authentication Codes. Die Protokolle SSL, IPsec und SSH verwenden standardmäßig verschiedene Methoden um die Daten zu verschlüsseln und die Integrität zu sichern:

  • SSL: mac-then encrypt. Dabei wird erst der MAC gebildet, dann werden Daten und MAC verschlüsselt.
  • IPsec: encrypt-then-mac. Dabei werden die Daten erst verschlüsselt und dann darüber der MAC gebildet.
  • SSH: encyrpt-and-mac. Die Daten werden verschlüsselt, die MAC wird aber über die Klartextdaten gebildet.

Es hat sich herausgestellt, dass von diesen drei Optionen die von IPsec verwendete Methode die sicherste ist. Diese encrypt-then-mac (etm) Verfahren können auch bei SSH verwendet werden.

Update: In RFC 7366 wird eine TLS-Erweiterung definiert, die auch die Verwendung von “encrypt then mac” benutzt.

Was hat sich jetzt beim Zugriff auf ein IOS-Gerät geändert? Ohne diese Anpassungen sieht die SSH-Session so aus (auf einem Cisco 3560 mit IOS 15.0(2)SE5):

c3560#sh ssh
Connection Version Mode Encryption  Hmac	 State	            Username
1          2.0     IN   aes128-cbc  hmac-md5     Session started   ki
1          2.0     OUT  aes128-cbc  hmac-md5     Session started   ki

Es wird aes-128-cbc mit einem MD5-HMAC verwendet. Nach den Änderungen ist die Krypto etwas besser (im Rahmen der Möglichkeiten des IOS):

c3560#sh ssh
Connection Version Mode Encryption  Hmac	 State	           Username
0          2.0     IN   aes256-cbc  hmac-sha1    Session started   ki
0          2.0     OUT  aes256-cbc  hmac-sha1    Session started   ki

Hier noch einmal die resultierende ~/.ssh/config:

Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc,3des-cbc
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,hmac-sha1

Update:
Nach einigem Nachdenken kam ich zu dem Ergebnis, dass mir die Aufnahme der Legacy-Verfahren in die Config-Datei irgendwie nicht gefällt. Daher habe ich diese wieder rausgeschmissen und gebe bei der Verbindung zu älteren Geräten die benötigte Crypto direkt an. Hier ein Beispiel für den Zugriff auf einen 2950:

ssh -l ki 10.10.10.200 -o Ciphers="3des-cbc" -o KexAlgorithms="diffie-hellman-group1-sha1"

Und hier die angepasste ~/.ssh/config:

Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,hmac-sha1

Weitergehende Verbesserungsvorschläge werden gerne angenommen.

SSH-Client-Konfiguration unter MacOS

Geld für GnuPG

logo-draft-1Zur Zeit bin ich dabei einen weiteren Teil meiner “alles verschlüsseln”-Strategie umzusetzen. Das wird demnächst auch noch ein eigener Beitrag werden.
Dazu passend berichtet heute heise.de, dass GnuPG per Crowdfunding Geld einsammeln möchte. Als jemand, der unter anderem auch OpenPGP einsetzt, ist das natürlich eine Sache die ich auch unterstützte. Das Ziel ist zwar schon fast erreicht, aber noch kann man natürlich mitmachen!

Geld für GnuPG