News In eigener Sache: ComputerBase nutzt TLS 1.3, ECDSA und Let's Encrypt

[SVΞN]

Diesbezüglich ist cb wirklich ein Vorreiter, davon können sich manch andere eine Scheibe abschneiden.

Ich freue mich auch immer wieder, dass das von mir bevorzugte Tech Magazin eine Vorreiterrolle bei solchen Entwicklungen innehat.

Bleibt bitte auch zukünftig so innovativ und lasst euch nicht von diesem Weg abbringen.

24 Monate ComputerBase Pro haben sich bisher ohne jeden Zweifel gelohnt.

Liebe Grüße
Sven

 

[GGG107]

Sehr schön. Hier auch wieder ein Punkt wo CB schon vorbildlich agiert.

 

[Steffen]

Ja auf jeden Fall. Allerdings frage ich mich, warum noch die Unterstützung für "TLS 1.0" und "TLS 1.1" aktiv ist. Konsequenterweise sollte diese deaktiviert werden.

Fallback für alte Handys, Tablets etc. vielleicht.

Hier sieht man im Abschnitt "Handshake Simulation", welche Clients nur TLS 1.0 oder 1.1 unterstützen: https://www.ssllabs.com/ssltest/analyze.html?d=www.computerbase.de&s=87.230.75.2

Alternativ hier die Browser, die TLS 1.2 unterstützen: https://caniuse.com/#feat=tls1-2

Ohne TLS 1.0 / 1.1 würde man u.a. Nutzern von Android 4.x, Chrome 29-, Firefox 26-, IE10-, Windows Phone 8- und Safari 6- einen Besuch von ComputerBase unmöglich machen. Zusammen kommen diese Browser immerhin noch auf 0,1–0,2 Prozent der Seitenaufrufe, deshalb würde ich TLS 1.0 und 1.1 jetzt noch nicht abschalten. Allzu lange werden wir damit aber eventuell auch nicht mehr warten.

 

[Jesterfox]

Nutzern von Android 4.x,

Betrifft das nur den Android Browser oder alle Browser auf Android 4? Eigentlich würde ich von ersterem ausgehen. Aber mich interessiert es grad weil ich noch n altes Tablet hab das nur Android 4 kennt (aber ich nutz den Edge drauf ;-)

 

[Cool Master]

Betrifft das nur den Android Browser oder alle Browser auf Android 4?

Kenn mich mit Android nicht aus aber wenn die Apps auf vorhandene Bibliotheken setzen betrifft es alle Browser auf Android 4, außer es gibt einen der alles in der App dabei hat. Der könnte dann, zumindest in der Theorie, gehen.

 

[Steffen]

@Jesterfox Es betrifft definitiv den Stock-Browser von Android 4.x. Ob unter Android 4.x auch andere Browser TLS 1.2 nicht unterstützen hängt vermutlich davon ab, ob sie eine eigene Rendering-Engine mitbringen oder die Android-"Webview" nutzen. Wenn man Chrome oder Firefox unter Android 4.x installiert (angenommen die funktionieren beide noch unter Android 4.x), dann nutzen beide ihre eigene Rendering-Engine und sollten TLS 1.2 (und bald auch TLS 1.3) unterstützen.

Du kannst das hier testen: https://www.ssllabs.com/ssltest/viewMyClient.html

 

[luky37]

Ihr präferiert (den OpenSSL 1.1.1 default):

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

Es ginge noch besser:
Hier sollte AES_128_GCM vor AES_256_GCM gestellt werden, weil es kein Sicherheitspuls dadurch gibt (eher noch Timing Attacken bei AES_256_GCM afaik), aber Performance Nachteile (deswegen laufen alle Seiten normalerweise in AES_128_GCM - wie auch Computerbase unter TLSv1.2).
Das erfordert nginx support für die OpenSSL Funktion SSL_CTX_set_ciphersuites(), was leider noch nicht da ist.

Und zweitens sollte Chacha20 vorgezogen werden, wenn der Client das auch vorzieht (für mobile Geräte ohne AES Beschleunigung). Dazu müsste nginx SSL_OP_PRIORITIZE_CHACHA mit SSL_CTX_set_options setzen. Dann könntet ihr bei TLSv1.2 AES_128_GCM vor Chacha20 stellen, damit defaultmäßig bei AES HW support auch AES benutzt wird und trotzdem für Geräte ohne AES HW support Chacha20 benutzt wird.

Die Sachen aber nicht mit ssllabs testen, denn der TLSv1.3 Ciphersuite Prioritätstests ist da selbst noch buggy, wenn Chacha20 abhängig vom Client priorisiert wird oder nicht.

 

[startaq]

Super, hätte nicht gedacht, dass ihr das so schnell umsetzt. Unter Gentoo ist openssl-1.1.1 ja auch noch im hard mask, also mutig mutig

 

[cbtestarossa]

@luky37
Also bei mir gerade im
Palemoon: TLS1.2 - CHACHA20POLY1305_SHA256
Firefox62: TLS1.2 - ECDHE_ECDSA_with_CHACHA20POLY1305_SHA256
was wäre dann bei TLS1.3 eventuell besser?

 

[luky37]

@cbtestarossa Ja, mit TLSv1.2. Weil der finale TLSv1.3 Standard erst ab Firefox 63 unterstützt wird.

 

[Silent1337]

Diesbezüglich ist cb wirklich ein Vorreiter, davon können sich manch andere eine Scheibe abschneiden.

So einfach ist das leider nicht.
Die meisten Distributionen im stable Branch können noch kein TLS 1.3, berechtigterweise warten die meisten ab, bis die libs in den Stable Repos sind.

 

[Jesterfox]

Wenn man Chrome oder Firefox unter Android 4.x installiert (angenommen die funktionieren beide noch unter Android 4.x), dann nutzen beide ihre eigene Rendering-Engine und sollten TLS 1.2 (und bald auch TLS 1.3) unterstützen.

Der Edge für Android bring ja glaub ich auch seine eigene Chromium-Engine mit (und der läuft auf dem alten Tablet Z), wenn die ihre eigenen TLS Bibliotheken mit dabei hat müsste es gehen. Ich wird das später mal testen.

 

[cbtestarossa]

@luky37
Ja das schon, aber gibt es dann bei TLS 1.3 noch ne bessere Verschlüsselung?
Das meinte ich.

 

[luky37]

Es gibt einige Verbesserungen in TLSv1.3, aber der Punkt ist das die Listen der zu priorisierenden Ciphersuites getrennt sind (TLSv1.2=> auf der einen Seite: wo CB Chacha20 priorisiert und TLSv1.3 wo CB den OpenSSL 1.1.1 default AES_256_GCM priorisiert).

Die darunterliegenden kryptograpischen Technologien wie AES-GCM oder Chacha20 bleiben die gleichen, es gibt aber eine Anzahl an anderen Verbesserungen in TLSv1.3 die die Sicherheit erhöhen.

 

[cbtestarossa]

Achso ging dir nur um die HW Unterstützung und Reihenfolge. Alles klar danke.
Wenigstens weiß ich nun auch warum einige AES256 Seiten plötzlich nur noch AES128 hatten.

 

[BamLee2k]

Das Lob ich mir.

PCGH schafft es nicht einmal auf HTTPS zu wechseln. ERBÄRMLICH für eine Hardware Seite.

 

[cbtestarossa]

Winfuture hatte es vor kurzem auch (noch/wieder) nicht. Scheinbar rennts nun.

 

[fahr_rad]

Das freut mich zu hören!

 

[DireWolf]

mal einfach, Danke!

 

[Steffen]

Hier sollte AES_128_GCM vor AES_256_GCM gestellt werden, weil es kein Sicherheitspuls dadurch gibt (eher noch Timing Attacken bei AES_256_GCM afaik), aber Performance Nachteile (deswegen laufen alle Seiten normalerweise in AES_128_GCM - wie auch Computerbase unter TLSv1.2).
Das erfordert nginx support für die OpenSSL Funktion SSL_CTX_set_ciphersuites(), was leider noch nicht da ist.

Ja, es scheint leider so als gäbe es in nginx derzeit keine Möglichkeit, die Priorität der TLS-1.3-Ciphers festzulegen (https://trac.nginx.org/nginx/ticket/1529). Ich habe da mal vorsichtig nachgefragt, Danke für den Hinweis!

Und zweitens sollte Chacha20 vorgezogen werden, wenn der Client das auch vorzieht (für mobile Geräte ohne AES Beschleunigung). Dazu müsste nginx SSL_OP_PRIORITIZE_CHACHA mit SSL_CTX_set_options setzen. Dann könntet ihr bei TLSv1.2 AES_128_GCM vor Chacha20 stellen, damit defaultmäßig bei AES HW support auch AES benutzt wird und trotzdem für Geräte ohne AES HW support Chacha20 benutzt wird.

Die nginx-Entwickler halten "SSL_OP_PRIORITIZE_CHACHA"-Unterstützung leider für einen Hack (https://trac.nginx.org/nginx/ticket/1445). Es kommen nach wie vor viele SoCs ohne AES-NI-Support auf den Markt, oder? Eine kurzen Recherche scheinen zum Beispiel von Qualcomm nur die Topmodelle aus der 800er-Serie AES-NI zu unterstützen (oder liege ich damit falsch?).

Vielleicht sollte man mal drüber nachdenken, wieder den Client anstatt den Server die Cipher-Order festlegen zu lassen? Vermutlich tritt man sich dann leider Ciphers ein, die man lieber nicht mehr unterstützen würde.

Super, hätte nicht gedacht, dass ihr das so schnell umsetzt. Unter Gentoo ist openssl-1.1.1 ja auch noch im hard mask, also mutig mutig

Wir haben nur nginx mit OpenSSL 1.1.1 gebaut, nicht das ganze System. Im Worst-Case hätte es uns also nginx zerlegt und wir wären ein paar Minuten down gewesen bis wir nginx wieder mit OpenSSL 1.0.2 gebaut hätten.

Hier der Patch für das Ebuild, falls es interessiert:

--- a/www-servers/nginx/nginx-1.15.5.ebuild
+++ b/www-servers/nginx/nginx-1.15.5.ebuild
@@ -195,6 +195,7 @@ SRC_URI="https://nginx.org/download/${P}.tar.gz
        nginx_modules_http_vhost_traffic_status? ( ${HTTP_VHOST_TRAFFIC_STATUS_MODULE_URI} -> ${HTTP_VHOST_TRAFFIC_STATUS_MODULE_P}.tar.gz )
        nginx_modules_stream_geoip2? ( ${GEOIP2_MODULE_URI} -> ${GEOIP2_MODULE_P}.tar.gz )
        nginx_modules_stream_javascript? ( ${NJS_MODULE_URI} -> ${NJS_MODULE_P}.tar.gz )
+       https://www.openssl.org/source/openssl-1.1.1.tar.gz
        rtmp? ( ${RTMP_MODULE_URI} -> ${RTMP_MODULE_P}.tar.gz )"
 
 LICENSE="BSD-2 BSD SSLeay MIT GPL-2 GPL-2+
@@ -381,6 +382,8 @@ src_prepare() {
        eapply "${FILESDIR}/${PN}-1.4.1-fix-perl-install-path.patch"
        eapply "${FILESDIR}/${PN}-httpoxy-mitigation-r1.patch"
 
+       unpack openssl-1.1.1.tar.gz
+
        if use nginx_modules_http_brotli; then
                cd "${HTTP_BROTLI_MODULE_WD}" || die
                eapply "${FILESDIR}"/http_brotli-detect-brotli-r1.patch
@@ -459,6 +462,8 @@ src_configure() {
        use pcre-jit  && myconf+=( --with-pcre-jit )
        use threads   && myconf+=( --with-threads )
 
+       myconf+=( --with-openssl=./openssl-1.1.1/ )
+
        # HTTP modules
        for mod in $NGINX_MODULES_STD; do
                if use nginx_modules_http_${mod}; then