Schlagwort-Archive: verschlüsselung

SSL, Apache, Komfort und Sicherheit III

Der Weg zu einem A-Rating bei SSL-Labs ist steinig. Wie hier und da und dort schon geschrieben: Kompatibilität und Sicherheit lassen sich mit den folgenden Zeilen in der ssl.conf des Apache ganz ordentlich verwirklichen:

wenn man den Key richtig erstellt hat – z.B. damit:

Was SSL Labs dann noch zu mockieren hatte, war die Key Chain, die unsichere Elemente enthielt und zum folgenden Rating führte:

1_kvfgeu

Die Keychain lässt sich jedoch einfach umbauen: Ein

holt die intermediären Zertifikate im richtigen Format an Bord. Und die folgenden Zeilen in der Apache default-ssl.conf

zusammen mit einem

schalten diese scharf. Dann erreicht man das folgende Rating bei SSL Labs:

2_kvfgeu

Hinweise und Links hier im StartSSL Forum.

In den Weihnachtsferien kommen dann die anderen Domains mit dickeren Keys dran. Bis dahin ist schlicht Land unter und außerdem muss ich bei StartSSL warten, bis das Zertifikat fast abgelaufen ist, will ich keinen revocation Prozess beginnen, der teuer ist.

SSL, Apache, Komfort und Sicherheit II

scolis.de.2014.11

Kompatibilität und Sicherheit lassen sich mit den folgenden Zeilen in der ssl.conf des Apache ganz ordentlich verwirklichen:

Getötet werden damit die Browser IE6 und IE8 unter Windows XP sowie BingBot und YahooSlurp, die alle noch kein SNI können und deswegen auf Scolis sowieso auf die Schnauze fallen.

Ich denke, ich hab nun erst einmal einen ordentlichen Kompromiss gefunden.

Via | Beachte: Update des Beitrags!

Zu sicher

Beachte: Update des Beitrags!

Nach den Anpassungen der Apache Configuration in Folge des Poodle Bugs erhielt ich zu Beginn der Woche eine Rückmeldung einer Vista Nutzerin aus dem Kollegium, dass sie nicht mehr auf unsere Seiten zugreifen könne. Ich nahm das zuerst nicht weiter ernst, tippte auf lokale Probleme. Dann stellte ich unter Cubian X fest, dass Chromium nur noch einen 113er Fehler anzeigte, der für

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

steht und Iceweasel merkte an

ssl_error_no_cypher_overlap

Diverse Browser unter Android 4.0.3 (Lightning, Tint Browser, Zirco) wollten ebenfalls nicht mehr meine eigenen HTTPS verschlüsselten Seiten aufrufen. Während unter Android der Firefox noch einsetzbar war, so ging auf meinem Spielkistchen mit Cubian X gar nichts mehr. Die Software auf diesem System lässt sich nicht einfach aktualisieren – meine Apache-Konfiguration war für das Ding schlicht „zu sicher“.

Ich kam dann irgendwann auf Idee, die unterstützten Cipher Suiten miteinander zu vergleichen. Das geht direkt bei Qualys SSL Labs – oder für den Browser auch hier: https://cc.dcsec.uni-hannover.de/check . Die Schuppen fielen dann endlich von den Augen.

Sichere Konfiguration

Eintrag:

SSLProtocol all -SSLv2 -SSLv3

SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!SSLv3:!EXPORT

Ergebnis unter Debian:

kvfgnet_debianssl

Unterstützte Browsersuiten:

Handshake Simulation
Android 2.3.7   No SNI 2 Protocol or cipher suite mismatch Fail3
Android 4.0.4 Protocol or cipher suite mismatch Fail3
Android 4.1.1 Protocol or cipher suite mismatch Fail3
Android 4.2.2 Protocol or cipher suite mismatch Fail3
Android 4.3 Protocol or cipher suite mismatch Fail3
Android 4.4.2 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   FS 256
BingBot Dec 2013   No SNI 2 Protocol or cipher suite mismatch Fail3
BingPreview Jun 2014 Protocol or cipher suite mismatch Fail3
Chrome 37 / OS X  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   FS 128
Firefox 24.2.0 ESR / Win 7 Protocol or cipher suite mismatch Fail3
Firefox 32 / OS X  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   FS 128
Googlebot Jun 2014 Protocol or cipher suite mismatch Fail3
IE 6 / XP   No FS 1   No SNI 2 Protocol or cipher suite mismatch Fail3
IE 7 / Vista Protocol or cipher suite mismatch Fail3
IE 8 / XP   No FS 1   No SNI 2 Protocol or cipher suite mismatch Fail3
IE 8-10 / Win 7  R Protocol or cipher suite mismatch Fail3
IE 11 / Win 7  R TLS 1.2 TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)   No FS 128
IE 11 / Win 8.1  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   FS 256
IE Mobile 10 / Win Phone 8.0 Protocol or cipher suite mismatch Fail3
IE Mobile 11 / Win Phone 8.1 TLS 1.2 TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)   No FS 128
Java 6u45   No SNI 2 Protocol or cipher suite mismatch Fail3
Java 7u25 Protocol or cipher suite mismatch Fail3
Java 8b132 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   FS 128
OpenSSL 0.9.8y Protocol or cipher suite mismatch Fail3
OpenSSL 1.0.1h TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   FS 256
Safari 5.1.9 / OS X 10.6.8 Protocol or cipher suite mismatch Fail3
Safari 6 / iOS 6.0.1  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   FS 256
Safari 7 / iOS 7.1  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   FS 256
Safari 8 / iOS 8.0 Beta  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   FS 256
Safari 6.0.4 / OS X 10.8.4  R Protocol or cipher suite mismatch Fail3
Safari 7 / OS X 10.9  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   FS 256
Yahoo Slurp Jun 2014   No SNI 2 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   FS 256
YandexBot Sep 2014 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   FS 256
(1) Clients that do not support Forward Secrecy (FS) are excluded when determining support for it.
(2) No support for virtual SSL hosting (SNI). Connects to the default site if the server uses SNI.
(3) Only first connection attempt simulated. Browsers tend to retry with a lower protocol version.
(R) Denotes a reference browser or client, with which we expect better effective security.
(All) We use defaults, but some platforms do not use their best protocols and features (e.g., Java 6 & 7, older IE).

Überarbeitete Konfiguration

Eintrag:

SSLProtocol all -SSLv2 -SSLv3

SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5

Ergebnis unter Debian:

debianssl

Unterstützte Browsersuiten:

Handshake Simulation
Android 2.3.7   No SNI 2 TLS 1.0 TLS_RSA_WITH_RC4_128_SHA (0x5)   No FS   RC4 128
Android 4.0.4 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   FS 256
Android 4.1.1 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   FS 256
Android 4.2.2 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   FS 256
Android 4.3 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   FS 256
Android 4.4.2 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   FS 256
BingBot Dec 2013   No SNI 2 TLS 1.0 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)   No FS 128
BingPreview Jun 2014 TLS 1.0 TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)   FS 256
Chrome 37 / OS X  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   FS 128
Firefox 24.2.0 ESR / Win 7 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   FS 256
Firefox 32 / OS X  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   FS 128
Googlebot Jun 2014 TLS 1.0 TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)   FS   RC4 128
IE 6 / XP   No FS 1   No SNI 2 Protocol or cipher suite mismatch Fail3
IE 7 / Vista TLS 1.0 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)   No FS 128
IE 8 / XP   No FS 1   No SNI 2 TLS 1.0 TLS_RSA_WITH_RC4_128_SHA (0x5)   No FS   RC4 128
IE 8-10 / Win 7  R TLS 1.0 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)   No FS 128
IE 11 / Win 7  R TLS 1.2 TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)   No FS 128
IE 11 / Win 8.1  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   FS 256
IE Mobile 10 / Win Phone 8.0 TLS 1.0 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)   No FS 128
IE Mobile 11 / Win Phone 8.1 TLS 1.2 TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)   No FS 128
Java 6u45   No SNI 2 TLS 1.0 TLS_RSA_WITH_RC4_128_SHA (0x5)   No FS   RC4 128
Java 7u25 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   FS 128
Java 8b132 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   FS 128
OpenSSL 0.9.8y TLS 1.0 TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)   FS 256
OpenSSL 1.0.1h TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   FS 256
Safari 5.1.9 / OS X 10.6.8 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   FS 128
Safari 6 / iOS 6.0.1  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   FS 256
Safari 7 / iOS 7.1  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   FS 256
Safari 8 / iOS 8.0 Beta  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   FS 256
Safari 6.0.4 / OS X 10.8.4  R TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   FS 256
Safari 7 / OS X 10.9  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   FS 256
Yahoo Slurp Jun 2014   No SNI 2 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   FS 256
YandexBot Sep 2014 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   FS 256
(1) Clients that do not support Forward Secrecy (FS) are excluded when determining support for it.
(2) No support for virtual SSL hosting (SNI). Connects to the default site if the server uses SNI.
(3) Only first connection attempt simulated. Browsers tend to retry with a lower protocol version.
(R) Denotes a reference browser or client, with which we expect better effective security.
(All) We use defaults, but some platforms do not use their best protocols and features (e.g., Java 6 & 7, older IE).

Herzblutfolgen

Meine beiden Schuldomains kvfg.net und kvfg.org hatten COMODO Zertifikate, die ich bei PSW aus der Kategorie Lite kaufte und die sich austauschen ließen. Bisher erfolgte die Lieferung derselben zusammen mit allen nötigen Dateien für den Aufbau einer passenden Zertifizierungskette. Dieses mal war dem nicht so.

Ich erhielt von PSW zwar wieder die cert.cabundle Datei – ein Austausch derselben gegen die vorhandene cert.cabundle reichte für Firefox aber nicht aus. Firefox meldete

sec_error_unknown_issuer

Chromium zickte nicht rum, dafür aber auch Rekonq und Konqueror. Nach der Lektüre von gefühlt 100 falschen Anleitungen im Netz und nach etwas herumprobieren, wie ich mir selbst die richtigen Teile einer Zertifizierungskette zusammenkleben könnte, weiß ich nun endlich, wie es geht:

Man besorgt sich hier bei Comodo die nötigen Dateien

  • COMODORSAAddTrustCA.crt
  • COMODORSADomainValidationSecureServerCA.crt
  • ComodoSSL.ca-bundle

und klebt diese mit cat in der folgenden Reihenfolge zusammen:

cat COMODORSAAddTrustCA.crt COMODORSADomainValidationSecureServerCA.crt ComodoSSL.ca-bundle > mydomain.bundle

DIese Bundle Datei kommt zur Direktive SSLCertificateChainFile:

SSLEngine On
SSLCertificateKeyFile /etc/apache2/ssl/mydomain/mydomain.key
SSLCertificateFile /etc/apache2/ssl/mydomain/certificate.crt
SSLCertificateChainFile /etc/apache2/ssl/mydomain/mydomain.bundle

Dann den Apachen neu starten, mit Firefox probieren und zur Sicherheit auch noch hiermit überprüfen: http://www.sslshopper.com/ssl-checker.html

Jetzt fehlt noch der Austausch meiner StartSSL Zertifikate, dann die große Passwortänderungsaktion und das Herzbluten wäre überstanden.

ZwangsGnuPG

Hier überlegte ich noch, ob wir nicht an der Schule ein Horde mit Verschlüsselungsfunktion für die Kollegen einrichten sollten und wollte dies zuerst ausführlich mit ein paar Unerschrockenen testen. Soweit ist es noch nicht – aber die nächsten Schritte stehen an … und da fiel der Blick auch wieder zurück auf mögliche Alternativen und Erweiterungen.

Daniel und ich diskutierten die Möglichkeit einer Autoverschlüsselung von E-Mails, wenn diese an Kollegen gerichtet sind. Technisch ginge das z.B. mit:

  • GNU Anubis (ein message submission daemon). Der wird aber seit ein paar Jahren wohl nicht mehr weiter entwickelt;
  • DJIGZO (ein Gateway), das im Prinzip recht interessant aussieht, aber leider nur S/MIME und encrypted PDF kann;
  • gpg-mailgate (ein Postscript Filter) und dessen Forks, der das leisten würde, was wir diskutierten, aber noch ziemlich frisch ist;

Für uns schien zuerst gpg-mailgate der vielversprechendste Kandidat zu sein – aber noch kann gpg-mailgate kein Multipart. Die Anhänge würden demnach unverschlüsselt durchrutschen und genau da stecken bei uns die relevanten Informationen drin.

Dazu kommen noch weitere Kritikpunkte an der Idee an sich:

  1. jede Nachricht zu verschlüsseln ist eigentlich overkill, weil wir bei Mails von Kollege1 an Kollege2 lediglich lokal einen copy machen;
  2. Es nervt, jedes mal ein extra Passwort für den Key einzugeben, nur um eine harmlose Mail zu lesen. Das führt zur Ablehnung des Gesamtsystems und zu verdammt kurzen Passwörtern. Diesen Weg könnten wir nur beschreiten, wenn wir auch automatisch entschlüsseln (also der Kontologin den Private Key gleich mit auspackt);
  3. Es entlastet zwar – aber damit verhindert es auch, dass man sich mit dem Thema Datenschutz überhaupt auseinander setzt. Es ist demnach anti-aufklärerisch … und wenn dann alle Kollegen gar nicht mehr denken, weil ja alles automatisch passiert, dann denken sie auch nicht mehr an das Thema, wenn sie eine Mail an Eltern verfassen. Datenschutz ist eben auch und vor allem eine Kopffrage.

Im Moment will ich lieber keinen ganz so radikalen Schritt. Wir sollten auf den Kopf unserer akademisch gebildeten Kollegen setzen, das Thema damit warm halten und lieber riskieren, dass mal die eine oder andere Mail unverschlüsselt durchläuft – also auf unserem Mailserver von /home/mailuser/1 nach /home/mailuser/2 kopiert wird.

Ein fester Slot „Datenschutz“ in jeder (zweiten?) GLK, evtl. noch nett verpackt als Rätselaufgabe zu einem aktuellen Fall, halte ich im Moment für zielführender und wirksamer.

Wenn wir dann eines Tages doch noch auf die Default-Verschlüsselung umsteigen wollen, dann könnte Horde selbst schon genug können, sofern den Kollegen klar ist, warum sie dies tun sollen.

hordeeinstellunggpg

In den Einstellungen von Webmail kann bei Horde im Bereich „Erstellen“ hinterlegt werden, dass jede neue Nachricht standardmäßig unterschrieben und verschlüsselt werden soll. Das kann ein Nutzer dann zwar wieder abknipsen … aber dann haftet er auch. Oder man nagelt diese Einstellung in der Datenbank über die Konfiguration von Horde selbst fest, statt sich mit mail-gateway und Freunden gleich die nächste zu betreuende Technik an Bord zu holen.

Truecrypt mit Benutzerrechten

Da Lehrer ihren Rechner in einem gemischten Betrieb – privat und dienstlich – einsetzen, müssen diese besondere Vorkehrungen treffen, dass Schülerdaten nicht in fremde Hände gelangen können. Das Programm der Wahl hierzu ist Truecrypt.

Ist man Root an seinem Rechner hat man keine Probleme mit Truecrypt, das für das Einbinden von Tresordateien Adminrechte benötigt. Die treten erst auf, wenn weitere Mitglieder der Familie (oder Kollegen, Schüler etc.) den Rechner ebenfalls nutzen wollen. Diesen nun für das Einbinden von Truecrypt Volumes Adminrechte zu geben ist nicht schlau. Besser ist der folgende Weg:

sudo visudo

startet einen speziellen Editor für die Datei /etc/sudoers. Hier dann am Ende die folgenden Zeilen hinzufügen:

# Truecrypt fuer normale Nutzer

%users  ALL=(root) NOPASSWD:/usr/bin/truecrypt

Jetzt haben alle Mitglieder der Benutzergruppe users die Möglichkeit ohne Eingabe eines Passworts Truecrypt auszuführen. Damit keine Missverständnisse auftreten: Für das Öffnen einer Tresordatei braucht man selbstverständlich weiterhin das zu dieser passende Passwort!

Wer noch radikalere Lösungen bevorzugt, könnte dieses Recht auch allen Nutzern unabhängig von der konkreten Benutzergruppe geben:

ALL  ALL=(root) NOPASSWD:/usr/bin/truecrypt

Weitere Informationen sowie Installations- und Konfigurationshinweise für Windows sind auf dem LFB zu finden. Weitere Informationen rund um sudo Konfigurationsmöglichkeiten sind bei ubuntuusers im Wiki.