Schlagwort-Archive: apache

CODE versus OO

Die Installation von Collabora (CODE) in nextCloud hinter einem HTTPS-Apache-Proxy verläuft ohne Zicken. Einfach die Anleitung nachturnen und es funktioniert. Aber es funktioniert zäh und das auch bei 32GB RAM auf einem (etwas in die Jahre geratenen aber durchaus noch webtauglichen) Dell Poweredge T710 mit zwei Xeon Prozessoren. Zumindest im Vergleich zu einem OnlyOffice (OO).

OnlyOffice bringt viel mehr Funktionen mit, lässt sich flutschiger bedienen und sieht darüber hinaus auch noch schicker aus. Im Vergleich dazu fällt Collabora sehr weit zurück: zähe, zickige und schnarchige Bedienung und gerade mal ein paar Basisfunktionen an Bord. Hat man einmal mit OO gespielt, will man nicht mehr zu CODE zurück. Dafür würde ich sogar hinnehmen, dass OO alles ins OOXML Format konvertieren will.

Jedoch: OnlyOffice in ownCloud hinter einem HTTPS-Apache-Proxy warf sich mir mit weitaus mehr Problemen bei der Installation in den Weg als CODE. Aktuell habe ich noch nicht alle im Griff – es funktioniert erst im Prinzip. Und zwar hiermit:

docker pull onlyoffice/documentserver

Die Virtualhost für den Apache anpassen:

<VirtualHost *:443>
     ServerName onlyoffice.domain.tld:443

     SSLEngine on
     ServerSignature On
     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

     SSLCertificateFile /etc/letsencrypt/live/onlyoffice.domain.tld/fullchain.pem
     SSLCertificateKeyFile /etc/letsencrypt/live/onlyoffice.domain.tld/privkey.pem

     LogLevel warn
     CustomLog ${APACHE_LOG_DIR}/access.log combined
     ErrorLog ${APACHE_LOG_DIR}/error.log

# Just in case - see below
SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off

# contra mixed content warnings
RequestHeader set X-Forwarded-Proto "https"

# basic proxy settings
ProxyRequests off

        ProxyPass / http://127.0.0.3:9090/
        <Location />
                ProxyPassReverse /
        </Location>
</VirtualHost>

Den OO Container starten:

docker run -i -t -d -p 127.0.0.3:9090:80 --restart always  onlyoffice/documentserver

die ownCloud App für OO installieren und die Kiste läuft. Im Prinzip.

Textverarbeitung funktioniert.

Präsentationssoftware funktioniert.

Tabellenkalkulation funktioniert.

Aber: Es funktioniert eben nur im Prinzip.

Denn man muss damit leben, dass einem der Firefox weiterhin in der Debug-Console Meldungen entgegen wirft:

Firefox kann keine Verbindung zu dem Server unter wss://onlyoffice.domain.tld/2017-02-17-15-53/doc/271488117372/c/493/1niaepga/websocket aufbauen.  sockjs.min.js:3:4835

Ich fummel mir hier nun seit Tagen einen ab, um diese Meldungen los zu werden. In der VHost Konfiguration des Apachen oben sind ja noch Reste davon zu sehen.

Für diese Versuche startete ich den docker container so, dass dessen Port 443 zum Wirt auf Port 9091 weiter gereicht wird

docker run -i -t -d -p 127.0.0.3:9090:80 -p 127.0.0.3:9091:443 onlyoffice/documentserver

und stellte dann Versuche in der VHost Config des Apachen nach dem Schema (!)

ProxyPassMatch "/(.*)/websocket"  wss://127.0.0.3:9091/$1/websocket

an. Erfolglos. Auch meine Versuche mit ProxyPass, ProxyPassReverse oder ReWrite Regeln scheiterten bisher.

Ich glaube, ich habe nun alle Anleitungen und Tutorials rund um Websockets mit HTTPs und Apache Proxy durch – ich fahr da noch immer vor die Wand. Und vor allem: Ich hab keine blassen Dunst, was ich eigentlich genau verzocke.

Drängen tut das Problem nicht. Ich roll weder OO noch CODE zum aktuellen Zeitpunkt aus. Denn ich vertraue weder dem auf einer eigenen Subdomain laufende OO Documentserver noch dem CODE Container. Zwar können Besucher theoretisch nur in den docker container reinfummeln und wohl nicht aus diesem oder dem Apache Proxy ausbrechen, aber schon dass finde ich irritierend.

Schlimmer ist vielmehr, dass ich den Websocket nicht an den Apache HTTPS Proxy so dran bekomme, dass der Firefox endlich Ruhe gibt. Falls da einer ne Idee hat … ich hab ein offenes Ohr. Vielleicht ist ja was dabei, was ich noch nicht probiert habe.

Redis Server und HSTS für ownCloud

Im Backend vermeldete ownCloud schon längere Zeit, dass es einen funktionierenden PHP Memory Cache vermisse. Bisher war mir das relativ egal, weil ich nicht viele Dateien und auch nicht viele Nutzer/innen hatte. Das hatte sich in den letzten Wochen und Monaten aber gründlich geändert, so dass ich bei drei meiner oC Installationen tätig werden musste. Nach dem Update auf oC 8.2.2 und Dank etwas freier Zeit ging ich das Problem endlich an.

APC und APCu waren zwar bei allen Servern an Bord, aber unter Ubuntu 14.04 und PHP5 „zu alt“. Ich probierte es mit Redis. Hier ist das PHP5 Modul von Ubuntu 14.04 zwar ebenfalls zu alt, aber es gibt in den PECL Repositories einfach zu installierenden Ersatz.

Ein

dpkg -l | grep php5-redis

klärt, ob ein solches PHP Modul installiert ist. Wenn ja, dann muss dieses zuerst runter vom Server. Danach kann der Redis Server an Bord:

apt-get install redis-server

Ein Blick in

/etc/redis/redis.conf

sollte ergeben, dass Redis an 127.0.0.1 lauscht und somit nicht von außen zu erreichen ist. Wer sich nicht sicher ist, kann von außen mit telnet nachsehen. Weiter sollte ein

service redis-server status

zeigen, dass der Redis-Server auch läuft.

Um PECL nutzen zu können benötigen wir noch die folgenden Pakete

apt-get install php-pear php5-dev

Wer, wie ich hier, Horde5 über PEAR bezieht, hat die Pakete schon. Ein

pecl install redis

bringt dann ein frischeres php Modul für Redis an Bord. Am Ende der Installation weißt PECL darauf hin, dass dieses Modul der vorhandenen PHP Umgebung bekannt gegeben werden muss. Da hilft

echo 'extension=redis.so' > /etc/php5/mods-available/redis.ini
php5enmod redis
service apache2 restart

Dann wird der Memory Cache ownCloud in

/pfad/zu/owncloud/config/config.php

bekannt gegeben, indem der folgenden Code ans Ende gehängt wird (vor die letzte schließende Klammer):

  'memcache.local' => '\\OC\\Memcache\\Redis',
  'filelocking.enabled' => 'true',
  'memcache.distributed' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' =>
    array (
      'host' => 'localhost',
      'port' => 6379,
      'timeout' => 0,
      'dbindex' => 0,
     ),

Im Backend von ownCloud herrscht nun etwas mehr Ruhe.

Was ownCloud leider nicht überprüft ist, ob es überhaupt über HTTP zu erreichen ist. Es schimpft immer über eine fehlende HSTS Konfiguration, bis eine solche eingerichtet ist.

Das ist mit

a2enmod headers

und dem Eintrag

Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains"

für die ownCloud Domain dann nach einem Neustart des Apachen auch erledigt, hat aber Nebenwirkungen: HTTP Verbindungen sind hiermit für die gesamte Domain ab dem ersten Aufruf über HTTPS für den Client-Browser erledigt. Muss man wollen.

Geholfen beim Einrichten haben mir die folgenden empfehlenswerten Quellen: 1, 2, 3, 4

De B ian

Was ich auch an einem Debian 7 mit Apache 2.2 zu drehen versuche, mehr als ein B hole ich bei SSLLabs nicht raus. Apache 2.2 kennt

SSLOpenSSLConfCmd

nicht und damit scheint man am Ende.

Wer einen moderneren Apachen fährt, dem sollte ein

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder  on
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

zumindest nicht nur meiner Denke nach weiterhelfen.

Unter Ubuntu 14.04 mit Apache 2.4 reicht auch das

SSLHonorCipherOrder on
SSLProtocol All -SSLv3
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

meinen Versuchen nach für ein A Rating, sofern die Schlüssel lang genug sind.

Es ist ein Gewürge …

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:

1_kvfgeu

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:

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:

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

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

SSL Check

Beachte: Update des Beitrags!

Ich bin mal meine Domains durchgegangen und habe deren Vertrauenswürdigkeit getestet. Was offensichtlich überall nicht richtig funktioniert ist Perfect Forward Secrecy mit jedem beliebigen Browser. Nur wenn dieser selbst nach den entsprechenden Verschlüsselungsverfahren fragt (Firefox tut dies), dann bekommt der auch PFS geliefert.

bdjlde

Apache 2.2 auf Debian erreicht ein A-. Geholfen hat erst der folgende Eintrag in die Konfigurationsdatei des Apachen:

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

Alles, was ich davor probierte oder gar aus der Konfiguration von Apache 2.4 Servern auf Apache 2.2 übernahm, führte zu heftigem Abzug bei der Wertung.

scolisde

Apache 2.4 erreicht ebenfalls ein A- und zeigt das gleiche PFS Problem.

Webserver von 12.04 auf 14.04

Nach dem Upgrade von Ubuntu 12.04 auf 14.04 warf Apache 2.4 mit einer ganzen Reihe von Fehlermeldungen nach mir, weil sich die Syntax einiger Konfigurationsdateien geändert hatte. Einen Überblick über die Änderungen liefert diese Seite:

http://httpd.apache.org/docs/2.4/upgrading.html

Lokal kommt man fast allen Problemen auf die Schliche, wenn man nach dem erfolgreichen Upgrade das Apache-eigene Tool apache2ctl einsetzt und dann die ausgeworfenen Fehlermeldungen Stück für Stück abarbeitet. In fast allen Fällen dürfte das Auskommentieren der beanstandeten Zeilen in den Konfigurationsdateien erst einmal ausreichen, um zu einem wieder funktionierenden Webserver zu gelangen:

sudo apache2ctl configtest

Was dann bei mir noch blieb war eine leere Seite, statt eines Logins für phpMyAdmin. In /var/log/syslog steht der Grund:

PHP Fatal error:  require_once(): Failed opening required ‚./libraries/php-gettext/gettext.inc‘ (include_path=‘.‘) in /usr/share/phpmyadmin/libraries/select_lang.lib.php on line 395

In der phpmyadmin.conf Datei fehlt hier der entsprechende Eintrag im Abschnitt <IfModule mod_php5.c> und dort in der open_basedir Anweisung

php_admin_value open_basedir /usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/

muss ergänzt werden:

php_admin_value open_basedir /usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/:/usr/share/php/php-gettext/

Dann den Apachen neu starten und es sollte wieder tun.

phpMyAdmin schimpfte dann, dass ihm die Bibliothek mcrypt fehle, die jedoch installiert war. Ein

php5enmod mcrypt

löste auch dieses Problem.

Apache 2.4 warnt beim Start vor SNI mit der Meldung

Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)

das sollte heute aber nur noch für Windows XP und den dortigen IE gelten. Chromium, Rekonq, Konqueror und Firefox funktionieren ohne Zicken.

Weiter: Mailserver 12.04 auf 14.04

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.

GoAccess

accesslogfiles

Logfileanalyse frisst im Normalfall Systemressourcen – nicht viele, aber unnötig viele, wenn man sich nicht wirklich für die Zugriffszahlen interessiert und nur alle paar Wochen einmal guckt. Dazu ein AwStats oder einen Webalizer zu betreiben ist overkill. Der Einsatz von PiWik ist praktisch, aber das Programm hält sich derartig brav an die Do Not Track Einstellungen, dass man nicht erfährt, wie viele Menschen einen wirklich besucht haben. Hier einmal im Vierteljahr vergleichen zu können ist schön.

Praktisch ist ein Tool wie GoAccess, das man nur bei Bedarf einsetzt und das man gezielt auf ausgewählte Logfiles loslassen kann. Das jeweils aktuelle Apache Log holt man sich mit

goaccess -f access.log.1

in den Betrachter. Will man gz archivierte Archive betrachten, muss man diese zuerst auspacken – z.B. mit zcat. Wenn man sich schon die Mühe macht, dann kann gleich ein ganzer Monat zusammen ausgepackt und dann betrachtet werden. Dazu schaut man die Logs in ihrem Verzeichnis zuerst mit ls -lat an, um das Datum etwas einzugrenzen und erzeugt dann ein Gesamtdokument aus der Auswahl:

zcat access.log.[4-7].gz >> accesslogcombined ; goaccess -f accesslogcombined

Wenn man fertig ist, kann man die kombinierte Logdatei wieder löschen.

Neuere Versionen von goaccess – nicht jedoch die für Debian aus den Repos verfügbaren Oldtimer – erlauben auch das Erstellen von HTML Reports. Sehr praktisch. Und viel hübscher als eine nscurses Oberfläche ist es auch.