Archiv der Kategorie: Schule

Etherpad Canvas

Verbinde ich mich mit meinem Firefox auf das schulische Etherpad-Lite erhalte ich zuerst eine schnell vorüberziehende Fehlermeldung, dann erscheint der Inhalt des Pads und will ich dann einen Eintrag vornehmen, meldet mir dieses:

Pad-Server nicht erreichbar.
Es konnte keine Verbindung zum Pad-Server hergestellt werden.
Dies könnte an Ihrem Browser oder Ihrer Internet-Verbindung liegen.

Mit Chromium oder Rekonq funktioniert es jedoch.

Bei mir lag das an einem Firefox Addon zum Blockieren von Canvas Skripts:

https://addons.mozilla.org/de/firefox/addon/canvasblocker/?src=api

Trage ich in diesem Addon die schulische Etherpad-Installation in die Whitelist ein, dann läuft das Ganze auch wieder in Firefox.

LD-Server und HTTPS

Webseiten und Dienste auf einem LD-Server laufen intern in LXC Containern oder auf einem Apache, sind jedoch nach Außen über Pound angebunden – und da ist die mitgelieferte Version ein Stück Softwaregeschichte. „Aktuell“ auf LD-Servern ist Version 2.5-1, der in der Default-Konfiguration eine ganze Reihe von Sicherheitsproblemen mit sich bringt. Nicht umsonst erhält man bei SSLLabs für eine nicht-angepasste LD-Server-Installation ein schlichtes F-Rating.

Man muss sich selbst helfen. Support oder Hilfe über die Foren darf man bei einem „Hauptsacheestutsystem“ nicht erwarten.

Mit dem folgenden Eintrag in die /etc/pound/pound.cfg stellt man sich zumindest bezogen auf das SSLLabs-Rating schon einmal viel besser auf und erhält ein C.

# Listen HTTPS
Ciphers "ALL:!ADH:!EXPORT56:RC4+RSA:HIGH:MEDIUM:!LOW:!SSLv2:+EXP:!eNUL:!EXP-DES-CBC-SHA:!EXP-RC2-CBC-MD5:!EXP-RC4-MD5:!EXP-DES-CBC-SHA:!EXP-RC2-CBC-MD5:!EXP"

Der Weisheit letzter Schluss ist das nicht: Die Konfiguration wird nach Systemupdates immer mal wieder überschrieben, so dass man hier gelegentlich vorbei schauen sollte. Außerdem hinterlässt auch die Zeile oben noch das eine oder andere Leck.

Aber es ist besser als vorher.

PS: Ein aktuelles Ubuntu Trusty hätte einen Pound 2.6-3 an Bord. Siehe http://packages.ubuntu.com/trusty/pound Der 2.5-1er Pound auf dem LD-Server scheint aus Oneiric zu stammen. Das war im Jahr 2011.

Wiedergänger

Direkt nach dem Umstieg von Ubuntu 12.04 auf 14.04 wollte sich die Horde-Installation meiner Schule nicht auf den neuesten Stand bringen lassen. Das übliche und sonst erfolgreiche

pear upgrade -a -B -c horde

brachte Fehlermeldungen nach dem folgenden Schema

downloading Horde_ActiveSync-2.25.0.tgz ...
Starting to download Horde_ActiveSync-2.25.0.tgz (345,324 bytes)
......................................................................done: 345,324 bytes
could not extract the package.xml file from "/build/buildd/php5-5.5.9+dfsg/pear-build-download/Horde_ActiveSync-2.25.0.tgz"
Download of "horde/horde_activesync" succeeded, but it is not a valid package archive
Error: cannot download "horde/Horde_ActiveSync"
downloading Horde_Compress-2.1.0.tgz ...
Starting to download Horde_Compress-2.1.0.tgz (2,187,446 bytes)
...done: 2,187,446 bytes
could not extract the package.xml file from "/build/buildd/php5-5.5.9+dfsg/pear-build-download/Horde_Compress-2.1.0.tgz"
Download of "horde/horde_compress" succeeded, but it is not a valid package archive
Error: cannot download "horde/Horde_Compress"
Download failed
upgrade failed

Damals half mir der folgende Bugreport bei launchpad weiter, der mich im Beitrag #9 auf die richtige Spur brachte. Der Fehler sitzt in der Datei

/usr/share/php/Archive/Tar.php

Hier muss gzopen durch gzopen64 ersetzt werden und gztell durch gztell64 und gzseek durch gzseek64.

Irgendwann im Laufe der letzten Woche muss ein Update gekommen sein, das die Tar.php ersetzte. Aktuell befinden sich die zu ändernden Zeilen samt angepasstem Inhalt in der Tar.php hier:

679:  if ($this->_compress_type == 'gz' && function_exists('gzopen64'))
680:  $this->_file = @gzopen64($this->_tarname, "wb9");
734:  if ($this->_compress_type == 'gz' && function_exists('gzopen64'))
735:  $this->_file = @gzopen64($v_filename, "rb");
759:  $this->_file = @gzopen64($this->_tarname, "r+b");
1782: $v_temp_tar = @gzopen64($this->_tarname.".tmp", "rb");
889:  @gzseek64($this->_file, gztell64($this->_file)+($p_len*512));

Dann läuft das Upgrade von Horde brav durch:

downloading Horde_ActiveSync-2.25.0.tgz ...
Starting to download Horde_ActiveSync-2.25.0.tgz (345,324 bytes)
......................................................................done: 345,324 bytes
downloading Horde_Compress-2.1.0.tgz ...
Starting to download Horde_Compress-2.1.0.tgz (2,187,446 bytes)
...done: 2,187,446 bytes
upgrade ok: channel://pear.horde.org/Horde_Compress-2.1.0
upgrade ok: channel://pear.horde.org/Horde_ActiveSync-2.25.0

Bis zum nächsten Mal.

Locale Probleme mit Dudle auf 14.04

Sollten sich bei einer Dudle Installation auf 14.04 die Apache error.logs mit Meldungen in der folgenden Art füllen

[cgi:error] [pid 20502] AH01215: /var/www/pfad/zu/dudle/vcs_git.rb:53:in `split': invalid byte sequence in US-ASCII (ArgumentError), referer: https://pfad.zu/dudle/
[cgi:error] [pid 20502] AH01215: \tfrom /var/www/pfad/zu/dudle/vcs_git.rb:53:in `history', referer: https://pfad.zu/dudle/
[cgi:error] [pid 20502] AH01215: \tfrom /var/www/pfad/zu/dudle/giykf19s/edit_columns.cgi:47:in `<main>', referer: https://pfad.zu/dudle/
[cgi:error] [pid 20502] End of script output before headers: edit_columns.cgi, referer: https://pfad.zu/dudle/

und Dudle einen bei der Eingabe von Worten mit Umlauten und / oder Ligaturen wieder auf seine Startseite werfen, dann hilft das Folgende: Zuerst ausschließen, dass man auf dem Server ein generelles Problem mit seinem locales hat. Es hilft ein

dpkg-reconfigure locales

Ein kontrollierender Blick in die folgenden Systemdateien sollte auch nicht schaden. Hier werden die Defaults gesetzt:

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
LC_ALL="de_DE.UTF-8"
LANG="de_DE.UTF-8"
/etc/environment (END)

und

LANG="de_DE.UTF-8"
LC_ALL="de_DE.UTF-8"
/etc/default/locale (END)

Ist hier alles in Ordnung, dann kann der folgende Eintrag in die dudle.rb helfen:

# /var/www/pfad/zu/dudle/dudle.rb

# coding: utf-8
Encoding.default_external = Encoding::UTF_8
Encoding.default_internal = Encoding::UTF_8

Nach einigem Hin und Her haben mir vor allem diese Einträge bei stackoverflow geholfen auf die richtige Spur zu kommen.

Wer unter CentOS und damit ruby 1.8 arbeitet hat noch Glück: Der Fehler geht an einem vorbei, scheint demnach ein Ubuntu Server und ruby 1.9.x Problemchen zu sein.

Pydio auf LD-Server über HTTPS

Pydio wird vom LD-Server in einem LXC Container als Virtuallisierungsschicht mitgeliefert. Nur dumm, dass die gesamte Konfiguration des LD-Servers immer über Subdomains läuft, was den Einsatz eines günstigen Zertifikats für nur eine Domain unmöglich macht, will man nicht auf self-signed zurückgreifen. Self-signed verbietet sich jedoch im schulischen Umfeld für die Dienste, die alle nutzen können sollten, weil man so die LuL und SuS dazu erzieht, Zertifikatswarnungen nicht ernst zu nehmen. Meine Lösung verwendet nun einen Apache Reverse Proxy [1], um die interne Pydio Domain extern in einem Unterverzeichnis der SSL-verschlüsselbaren Schuldomain einzublenden. Damit das klappt, müssen der Reverse Proxy Pound des LD-Servers mit dem Reverse Proxy Apache und dem NGinx im LXC-Container in Reihe geschaltet werden. Das geht so:

1. Kontrollieren ob der Symlink auf /etc/apache2/sites-available/pydio in /etc/apache2/sites-enabled weg ist (die Konfiguration findet an anderer Stelle statt).

2. In der /etc/apache2/sites-enabled/000-default die folgenden Einträge in den Abschnitt für VirtualHost * und auch in den Abschnitt für VirtualHost *:443 vornehmen:

ProxyRequests Off
   <Proxy *>
    Order allow,deny
    Allow from all
  </Proxy>
ProxyPass /pydio http://pydio/
ProxyPassReverse /pydio http://pydio/

3. In der /etc/logodidact/service.conf Pydio für die Domain, die man schon mit SSL versorgt, einschalten:

[Pydio]
Host sub.domain.tld
Alias pydio.sub.domain.tld
AllowExternalHTTPS yes
URL sub.domain.tld/pydio
RedirectExternalHTTP https://sub.domain.tld/pydio

4. Die beteiligten Dienste neu starten:

ldfirewall restart
update_pound_config -r
/etc/init.d/apache2 restart

Ein

host pydio

auf dem LD-Server muss eine Antwort liefern, sonst braucht man nicht weiterforschen, sondern muss die DNS Probleme in den Griff bekommen. Auch ein

links2 http://pydio
links2 https://pydio # weniger relevant, s.U.

sollte Ergebnisse liefern – mindestens eine Zeile HTML Code sollte zu sehen sein, mehr schafft links2 nicht, weil es kein JavaScript kann.

Der Aufruf von Pydio funktioniert dann reibungslos, wenn man den „trailing slash“ im URI zu Pydio nicht vergisst. Ohne diesen sieht man nur ein leeres Fenster. Alle Links für die Kolleg/innen und Schüler/innen sollten also so aussehen:

https://sub.domain.tld/pydio/

Jetzt funktioniert das Setup durchgehend ohne Zertifikatswarnungen und zumindest bis zum internen Reverse Proxy Pound auch verschlüsselt.

Wie und ob Pound dann dem Apache Reverse Proxy (als Übersetzer zwischen Internet und virtueller Pydio Maschine m LXC Container) die Daten verschlüsselt weiterreicht habe ich nicht geprüft. Ich vermute aber, auf Grund der Konfiguration, dass dem nicht so ist. Das sollte aber kein Problem darstellen, da an diesen Datenstrom nur root direkt auf dem Server rankommt.

Zu empfehlen ist eine Konfiguration von Pydio durch den Benutzer admin. Auf Pydio ist dieser mit den nötigen Rechten ausgestattet, weil der LXC Container über LDAP am LD-Server hängt. Hier sollte man alles abschalten was geht – vor allem die Funktionen zum unbegrenzten Teilen per Link und ohne Passwort. Denn: LD stellt Pydio extrem offen zur Verfügung. So offen, dass man aus Urheberrechts- und Datenschutzsicht Einschränkungen vornehmen muss, will man seine Schule und Schüler nicht ausliefern.

Weiter ist die Pydio Installation auch komplett veraltet (Version 5.0.4 – aktuell ist 6). Damit muss man wohl leben bei dieser Schulserverlösung. Deren Marketingabteilung wird das Konzept sicherlich als „bewährte Software“ verticken. Auf den bekannteren Exploit-DBs fand ich aktuell aber nichts, was Skript-Kiddies auf die Schnelle gegen Pydio einsetzen könnten.

LDAPs von ownCloud auf LD-Server

Nicht nur die Anbindung des LD-Servers an eine externe DokuWiki Installation, sondern auch an ein externes ownCloud funktioniert über LDAPs und lässt sich wie folgt einrichten:

Der erste Schritt ist vom OC-Administrator vorzunehmen, der im Backend die LDAP App einschalten muss. Weiter muss auf dem ownCloud-Server auch php5-ldap installiert sein und in der folgenden Datei die Prüfung auf Zertifikate abgeschaltet werden, wenn man intern auf dem LD-Server für den eigenen LDAP nur selbst-signierte Zertifikate einsetzt (was in den meisten Fällen zutreffen dürfte – leider):

# /etc/ldap/ldap.conf

TLS_REQCERT allow

Als OC-Administrator lässt sich dann unter dem Menü-Eintrag /Administration die restliche Konfiguration vornehmen.

In der Server-Registerkarte ist die URL (besser: IP) für den LD-Server zu hinterlegen. Danach klickt man einmal in Benutzer-DN, trägt aber nix ein, klickt einmal in Passwort, trägt aber nix ein und schreibt dann die DN Angaben in das letzte Feld. Bei BelWü-Kunden dürfte es sich hierbei um einen Eintrag in der folgenden Form handeln:

dc=schulkuerzel,dc=stadt,dc=schule-bw,dc=de

Dann klickt man auf Fortsetzen – wie auch bei allen anderen folgenden Registerkarten.

In der Nutzer-Filter-Registerkarte sollte inetOrgPerson vorausgewählt sein und ownCloud auch gleich alle internen Benutzer (und Workstations etc.) finden. Im Bild oben sind dies 1008 Benutzer. Das sind etwas viele, die sich anmelden dürften, weswegen man Beschränkungen vornehmen sollte. Im Folgenden beschränke ich die Nutzung für die Gruppe der Lehrer/innen.

Die Beschränkung erfolgt schon bei der Anmeldung: Nur Mitglieder der Gruppe teacher werden akzeptiert. Die entscheidende Funktion wird durch vorauswählbare Einträge nicht scharf schaltbar, weshalb man selbst den Original-Filter bearbeiten muss, so dass dieser am Ende wie folgt aussieht:

(&(|(objectclass=inetOrgPerson))(|(ldRole=teacher))(|(uid=%uid)(|(mailPrimaryAddress=%uid)(mail=%uid))(|(cn=%uid))))

Hinzugefügt wurde in die Voreinstellungen ein

(|(ldRole=teacher))

Der Gruppen-Filter von ownCloud bezieht sich nämlich nicht auf die Benutzerrechte im Anmeldekontext, sondern lediglich auf das Recht, innerhalb von ownCloud Gruppen bilden zu dürfen.

Was bei der Arbeit auf jeden Fall hilft, ist einmal auf dem LD-Server mit tshark zu gucken, ob überhaupt LDAPs Anfragen ankommen.

tshark -i extern port 636

Weiter macht es Sinn mit

tail -f /var/www/owncloud/data/owncloud.log

zu verfolgen, was alles bei den Anmeldeversuchen schief läuft. Man braucht mindestens einen Lehreraccount und einen Schüleraccount zum Testen – sonst wird man irre. Auch darf man damit rechnen, dass man mehrfach

service apache2 restart

auf dem ownCloud Server benötigt, weil sich dieser an den Einstellungen verschluckt hat. Das kann man gut in der owncloud.log verfolgen: Sollte diese im Sekundenabstand mit Zeilen gefüllt werden, die ungefähr diese Angaben enthalten, dann ist es mal wieder Zeit für einen Apache Restart und einen erneuten Versuch im OC-Backend:

{"app":"user_ldap","message":"Configuration Error (prefix ): Not a single Base DN given.","level":2,"time":"2014-12-19T16:50:15+00:00"}
{"app":"user_ldap","message":"Configuration Error (prefix ): login filter does not contain %uid place holder.","level":2,"time":"2014-12-19T16:50:15+00:00"}

Wer das alles für seine Linuxmuster.net Lösung haben will, wird im Wiki fündig. Wie immer sind die freien Schulserver-Lösungen bei der Dokumentation von Sonderwünschen und Erweiterungen vorbildlich.

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:

SSLHonorCipherOrder on
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

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

openssl req -new -nodes -sha256 -keyout server.key -out server.csr -newkey rsa:4096

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

Die Keychain lässt sich jedoch einfach umbauen: Ein

wget https://www.startssl.com/certs/class1/sha2/pem/sub.class1.server.sha2.ca.pem

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

SSLCertificateChainFile /etc/apache2/ssl/startssl/sub.class1.server.sha2.ca.pem
SSLCACertificateFile /etc/apache2/ssl/startssl/ca.pem # unverändert

zusammen mit einem

service apache2 restart

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

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.

Dudle auf 14.04

Der Dienst Dudle ist datenschutzrechtlich eine saubere Alternative zu Doodle, das zwar in der Schweiz zu Hause ist, jedoch Google Analytics einsetzt und die Benutzer mit Werbung bewirft. Außerdem ist die Verwendung von Doodle für Beamte in Baden-Württemberg schlicht verboten.

Die Installation ist kein Zuckerschlecken, geht aber insgesamt dann doch eher freundlich als kompliziert über die Bühne. Das ganze Gefrickel lohnt nur dann, wenn man eine HTTPS Verschlüsselung für die eigenen Seiten schon am Laufen hat – wenn nicht, dann verwendet man besser den Dienst der TUD direkt.

Es kann durchaus sein, dass ich im folgenden ein paar Pakete zu viel an Bord hole – das mag dann bitte jeder selbst für sich prüfen. Außerdem kann es sein, dass einige Pakete nicht installiert wurden, weil diese auf meinem Zielsystem schon vorhanden waren. Anyway – so ging’s bei mir:

apt-get install bzr libgettext-rails-ruby1.8 potool make libgettext-rails-ruby ruby-gettext gettext

Bei mir kamen hierbei die Pakete ruby1.9.1-dev ruby-dev schon mit an Bord und auch die Symlinks von ruby auf ruby1.9.1 wurden eingerichtet.

cd /var/www/ # oder wo auch immer dudle später hin soll

Ein simples bzr branch https://dudle.inf.tu-dresden.de/ dudle bewirft den Benutzer mit Fehlermeldungen. So will es dann klappen:

bzr -Ossl.cert_reqs=none branch https://dudle.inf.tu-dresden.de/ dudle

Das Verzeichnis /var/www/dudle wird mittels des Befehls angelegt, gehört aber erst einmal root, was wir nicht wollen.

chown -R www-data.www-data dudle/
cd dudle/
cp -p config_sample.rb config.rb

In die .htacces im Stammverzeichnis von Dudle sollte man bei der Nutzung von Ruby 1.9.1 (also auf einem 14.04 Server) hinzufügen:

SetEnv RUBYLIB /var/www/dudle/

Geschieht dies nicht, dann wirft Dudle Fehlermeldungen in die Apache error.log, die darauf hindeuten, dass Dudle seine Ruby Dateien nicht findet.

Wir holen uns noch die Sprachpakete für Dudle an Bord:

for i in locale/??; do wget -O $i/dudle.mo https://dudle.inf.tu-dresden.de/locale/`basename $i`/dudle.mo ; done

Die folgenden Schritte integrieren Dudle in den Webserver:

a2enmod auth_digest

Dann die Sitekonfiguration des Apachen bearbeiten – das könnte je nach System z.B. in die folgende Datei sein: /etc/apache2/sites-available/default-ssl.conf

Alias /dudle /var/www/dudle
<Directory /var/www/dudle>
     Options +ExecCGI
     AllowOverride All
     Order allow,deny
     Allow from all
</Directory>

Nachdem die Voraussetzung nun geschaffen sind, Dudle zu installieren, kann der Compiler im Verzeichnis /var/www/dudle angeworfen werden:

make

In den hier auftauchenden Fehlermeldungen (eigentlich sollten keine mehr kommen – die obigen Schritte integrieren alles, was ich habe lernen müssen) kann man sehen, was Dudle noch fehlt. Zumindest so ungefähr. Meistens, so musste ich erfahren, hilft nur eine Suchmaschine weiter, weil die Ruby-Fehlermeldungen etwas kryptisch für mich waren.

Ging alles glatt – den Apachen neu starten:

service apache2 restart

Der Rest ist Anhübschungskram – z.B. durch Anpassung der Dateien im Verzeichnis dudle/css. Empfehlenswert ist das folgende Stylesheet:

wget https://dudle.inf.tu-dresden.de/css/TUD2.css
wget https://dudle.inf.tu-dresden.de/css/tud/logo.png

Ich hab dann noch das Logo ausgetauscht, die Rechte wieder angepasst und beschlossen, dass nun erst einmal alles gut ist.

Dudle legt neue Abfragen im Stammverzeichnis /dudle/ unter jeweils recht kryptisch anmutenden Namen als Ordner an, die alle Umfragedaten (Benutzer, Passwörter derselben, Zeiten etc.) enthalten. Die Passwörter landen gehashed in .htdigest Dateien.

Meine Schule wäre versorgt – andere können den Dienst bei der TUD (Link siehe oben) oder auch gerne das Dudle auf dem Lehrerforbildungsserver nutzen:

https://lehrerfortbildung-bw.de/dudle/

Bei Problemen nach der Eingabe von Umlauten oder Ligaturen in die Dudle Felder: hier weiterlesen.

Atto, TinyMCE und Moodle 2.7.x

Mit der Schule bin ich gestern erst auf die Moodle 2.7.2er Reihe von 2.6.5 aus umgestiegen. Da etwas länger zu warten bringt am Ende weniger Bugs und Ärger. Abgesehen von einer Anpassung der Aufgabenformate ist mir aufgefallen, dass nun Atto als Default-Editor keinen Schalter für Emoticons mehr zeigte. Dieser lässt sich aber nachrüsten:

Unter /Plugins /Texteditoren /Texteditor Atto /Einstellungen findet man eine Liste der Editorenfunktionen und darunter ein Feld, in das man seine Ergänzungen eintragen kann oder über das man die Reihenfolge der Knöpfe verändert.

Ein emoticon = emoticon fügt Atto den wichtigsten Knopf im System wieder hinzu.

Will man lieber gleich zum mächtigeren TinyMCE wechseln, dann schiebt man diesen unter /Texteditoren /Übersicht über Atto.

Da ist dann der Emoticon-Schalter gleich wieder mit dabei.

Nebenwirkungen

TinyMCE verwendet DragMath als Formeleditor. Das bedeutet Java Plugins müssen im Browser aktiviert werden können (IcedTea). Atto nutzt hierfür MathJAX. Das klappt zwar ohne Java – dafür lädt sich dieser Formeleditor Code aus den USA nach und was dabei in die andere Richtung über den Atlantik geht, weiß wieder keiner.

Man hat demnach die Wahl zwischen Java und NSA. Super.

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:

Unterstützte Browsersuiten:

Handshake Simulation
Android 2.3.7 No SNI ²	Protocol or cipher suite mismatch		Fail³
Android 4.0.4	Protocol or cipher suite mismatch		Fail³
Android 4.1.1	Protocol or cipher suite mismatch		Fail³
Android 4.2.2	Protocol or cipher suite mismatch		Fail³
Android 4.3	Protocol or cipher suite mismatch		Fail³
Android 4.4.2	TLS 1.2	TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (`0xc030`) FS	256
BingBot Dec 2013 No SNI ²	Protocol or cipher suite mismatch		Fail³
BingPreview Jun 2014	Protocol or cipher suite mismatch		Fail³
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		Fail³
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		Fail³
IE 6 / XP No FS ¹ No SNI ²	Protocol or cipher suite mismatch		Fail³
IE 7 / Vista	Protocol or cipher suite mismatch		Fail³
IE 8 / XP No FS ¹ No SNI ²	Protocol or cipher suite mismatch		Fail³
IE 8-10 / Win 7 R	Protocol or cipher suite mismatch		Fail³
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		Fail³
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 ²	Protocol or cipher suite mismatch		Fail³
Java 7u25	Protocol or cipher suite mismatch		Fail³
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		Fail³
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		Fail³
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		Fail³
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 ²	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