News In eigener Sache: ComputerBase nutzt jetzt durchgehend HTTPS und HTTP/2

[M@rsupil@mi]

Feine Sache. Wirklich klasse, dass solche Sicherheitsthemen / -Aspekte hier so weit oben auf der Prioritätenliste stehen.

 

[heubergen]

Dankeschön für die ausführliche News und die Infos!

Mozilla ist auch schon an der Unterstützung aller drei Plattformen dran

 

[Pry_T800]

Echt super, dass sich auch in diesem Bereich etwas tut! Danke



Cu der Pry

 

[iophobia]

... Das von dir angesprochene 0-RTT erfordert darüber hinaus TLS 1.3, das wir erst unterstützen können sobald es TLS-1.3-Support in OpenSSL gibt.

Lange kann es nicht mehr dauern mit der Unterstützung von 0-RTT, jetzt da nginx mit Support für TLS1.3 veröffentlicht wurde. Wenn OpenSSL dann offiziell nachzieht, seid ihr sicher die Ersten (und Einzigen), die es implementieren.

 

[Steffen]

Auf unserem Entwicklungsserver läuft seit heute nginx 1.13 mit einer Vorabversion von OpenSSL 1.1.1 und TLS 1.3 (Draft 18). Zum jetzigen Zeitpunkt unterstützt allerdings noch kein Browser standardmäßig TLS 1.3 (also ohne Eingriffe auf chrome://config bzw. about:config), weil bei manchen Nutzern "tolle" Enterprise-Middleware dazwischenfunkt (https://bugs.chromium.org/p/chromium/issues/detail?id=694593). Es besteht also kein Druck, mit einer Vorabversion von OpenSSL 1.1.1 im Produktionsbetrieb zu hantieren. Und eigentlich ist TLS 1.3 ja auch noch gar nicht fertig, sondern steht bei Draft 19. Ein paar (hoffentlich wenige) Monate müssen wir uns noch gedulden.

 

[Der-Orden-Xar]

Schön zu hören, dass dir euch nicht mit dem einmaligen Ergebnis zufrieden gebt, sondern auch weiterhin eine gute Config bieten wollt

Mal aus dem Bugzilla mit zwei kleinen Kommentaren dazu.

The earlier ones [compatibility testing] showed some issues that caused us to delay release. [mindestens für Firefox 52 & 53] It's fairly safe to flip the pref if you know what to expect, but there are a small number of people who will encounter compatibility issues and won't know how to deal with them, so we are keeping it off until we're certain that it's not regressing compatibility much.

In freier Wildbahn ist mir noch kein Problem damit aufgefallen, da ist kein TLS 1.0 schlimmer^^
Aber ich bin weder repräsentativ noch hänge ich hinter irgendeinem MitM (hoffe ich^^)

 

[Steffen]

Wir haben heute ein neues TLS-Zertifikat eingespielt bzw. das unser altes TLS-Zertifikat um 1 Jahr verlängert. Davon sollte niemand etwas mitbekommen. Weil HTTPS hier in den vergangenen Wochen Thema war, dachte ich sage ich kurz Bescheid.

Wir waren übrigens kurz davor, auf Let's Encrypt umzusteigen. Weil der Browser-Support von Let's Encrypt sehr gut aber nicht perfekt ist, haben wir uns dann aber doch dagegen entschieden. Konkret hätten wir durch einen Umstieg auf Let's Encrypt die Nutzer von BlackBerry OS 10.3.2 ausgesperrt. Zwar gibt es schon BlackBerry OS 10.3.3 mit Let's-Encrypt-Support, aber das wird zum Beispiel von der Telekom noch nicht ausgerollt.

Unser Let's-Encrypt-Setup mit automatischer Erneuerung der TLS-Zertifikate steht aber seit Sommer 2016 und funktioniert problemlos, sodass wir nächstes Jahr umsteigen können, wenn sich die Umstände bis dahn geändert haben.

 

[DeusoftheWired]

Andere Seiten bekommen nicht mal eine TLS-Instanz auf die Reihe und ihr haltet euch zwei parallel – wieder mal Hut ab vor so viel Leistung! An euch können sich etliche deutsche Seiten ein Beispiel nehmen.

 

[iophobia]

Hallo Steffen,

das Mozilla Observatory hat euch unlängst wegen eurer CSP-Implementierungen wieder auf ein B+ abgestuft. Vielleicht solltet ihr euch dessen mal annehmen.

https://observatory.mozilla.org/analyze.html?host=www.computerbase.de

Grüße,
io

 

[Steffen]

Dass dort früher die reine Existenz einer CSP als super gewertet wurde war auch etwas seltsam.

Auf Seiten mit Anzeigen müssen wir leider eine extrem lasche CSP nutzen, weil die Anzeigen mit allem anderen nicht klar kommen. Auf Seiten ohne Anzeigen hingegen nutzen wir eine sehr strikte CSP, also zum Beispiel auf https://www.computerbase.de/pro/ oder wenn man als Nutzer von ComputerBase Pro eingeloggt ist generell auf allen redaktionellen Seiten (also überall außerhalb des Forums), weil dann ja keine Werbebanner existieren.

Mit dem Mozilla Observatory kann man offenbar leider nur die Startseite scannen. Aber du kannst zum Beispiel mit SecurityHeaders.io nachvollziehen, dass wir auf Seiten ohne Anzeigen eine sehr viel striktere CSP nutzen.

Seiten mit Anzeigen:

frame-ancestors 'none'; upgrade-insecure-requests; report-uri /api/csp-report

Seiten ohne Anzeigen (insbesondere wird "script-src" eingeschränkt):

default-src 'none'; style-src 'self' 'unsafe-inline'; script-src 'self' https://*.ioam.de https://iam-agof.irquest.com https://www.google-analytics.com; font-src 'self'; img-src 'self' data: https://pics.computerbase.de https://qs.ioam.de https://iam-agof.irquest.com https://www.google-analytics.com; child-src 'self' https://*.ioam.de; frame-src 'self' https://*.ioam.de; connect-src 'self' https://irqs.ioam.de https://www.google-analytics.com; manifest-src 'self'; form-action 'self'; frame-ancestors 'none'; report-uri /api/csp-report

Ich bin mir sicher, dass diese CSP beim Mozilla Observatory nicht abgewertet würde. Leider können wir sie wie gesagt auf Seiten mit Anzeigen nicht nutzen, sondern nur auf den Seiten, die generell keine Anzeigen haben (Abo-Seite, Impressum, Backend-Seiten, ...), und bei Nutzern von ComputerBase Pro.

Wenn es irgendwann technisch möglich ist, dann werden wir die striktere CSP natürlich an alle Nutzer ausliefern (wie bei HTTPS, das wir auch erst exklusiv für Pro-Nutzer eingeführt hatten und dann als die Anzeigen HTTPS-kompatibel waren wie versprochen für alle freigeschaltet haben). Ich befürchte nur das könnte noch dauern, weil eine CSP-Einführung über die Anzeigen-Provider und deren Dienstleister hinweg viel schwieriger zu vermitteln und umzusetzen sein dürfte als "aktiviert endlich HTTPS" (und schon das hat Jahre gedauert und es nutzen bei weitem noch immer nicht alle News-Websites HTTPS).

 

[iophobia]

Gut zu wissen. Wie üblich sind also die Anzeigen schuld.

 

[boncha]

Google entzieht Symantec 2018 das Vertrauen
https://www.heise.de/security/meldu...ieht-Symantec-2018-das-Vertrauen-3828578.html

Ab April 2018 soll Google Chrome keine Zertifikate mehr akzeptieren, die eine der vielen Symantec-Zertifizierungsstellen vor dem 1.6.2016 ausgestellt hat. Wer also noch ein Zertifikat von Symantec oder deren Töchter Thawte, VeriSign, Equifax, GeoTrust oder RapidSSL im Einsatz hat, muss bis dahin handeln.

Computerbase hat doch auch das Zertifikat von GeoTrust Inc.
Werdet ihr zu Let's Encrypt wechseln?

 

[Steffen]

Unser aktuelles Zertifikat von GeoTrust (Symantec) ist noch bis Ende Mai 2018 gültig und wird bis dahin auch von Chrome und anderen Browsern akzeptiert werden. Warum wir bei der letzten Verlängerung im Mai 2017 noch nicht auf Let's Encrypt umgestiegen sind, hatte ich ein paar Beiträge weiter oben erklärt (Browser-Support): https://www.computerbase.de/forum/t...ttps-und-http-2.1595421/page-11#post-20037054

Unser Let's-Encrypt-Setup steht aber, schon seit über einem Jahr werden alle 60 Tage parallel zu unserem GeoTrust-Zertifikat vollautomatisch unsere Let's-Encrypt-Zertifikate erneuert. Wir könnten also jederzeit durch Änderung einer Zeile in der nginx-Konfiguration auf Let's Encrypt umsteigen. Aufgrund des minimal schlechteren Browser-Supports von Let's Encrypt werden wir damit aber noch etwas warten.

Aktuell ist der Plan, im Frühjahr 2018 umzusteigen.

 

[Steffen]

Seit wenigen Minuten nutzt ComputerBase ein SSL/TLS-Zertifikat von Let's Encrypt.

Der nicht ganz perfekte Browser-Support, der uns letztes Jahr noch vom Wechsel abgehalten hat (siehe oben), ist jetzt kein Problem mehr. BlackBerry OS 10.3.2 ist zugunsten von Version 10.3.3 (oder anderen Betriebssystemen) fast komplett aus unserem User-Agent-Log verschwunden. Darüber hinaus hat uns Let's Encrypt den Wechsel durch die Unterstützung von Wildcard-Zertifikaten versüßt.

Neu ist zudem, dass unser Server halbwegs modernen Browser jetzt ein ECDSA- anstatt RSA-Zertifikat anbietet, was kleine Vorteile in puncto Größe und Performance bringen soll: https://scotthelme.co.uk/ecdsa-certificates/

 

[LieberNetterFlo]

nice hab auch gleich mal das Wildcard Zertifikat bei mir aktiviert!

Wie entscheidet ihr welche Ciphers ihr anbietet? Ich halte mich bisher an die hier von Mozilla: https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy (habe HAProxy als Frontend im Einsatz)

 

[Steffen]

Ja, mache ich genauso.

 

[LieberNetterFlo]

Folgefrage: mit welchem Script erzeugt ihr euer Zertifikat? hatte bisher getssl im Einsatz, das kommt wohl mit Wildcard noch nicht so ganz zurecht, bin mal temporär auf acme.sh umgestiegen, leider kann das nicht direkt eine kombinierte .pem Dateien bauen wie sie HAProxy benötigt, muss also ein post-hook anhängen

 

[Steffen]

Ich habe den ACMEv2-Branch von acme-tiny etwas umgebaut, sodass Wildcard-Zertifikate mit der DNS-API von INWX (unser Domain- und DNS-Provider) ausgestellt werden können.

Ich habe das mal hier hochgeladen: https://github.com/steffenweber/acme-tiny/commit/1d00bf3be035e18849d5d6e17bf9aadfa4e39bd1