News ACMEv2: Let's Encrypt stellt ab sofort Wildcard-Zertifikate aus

[Blutschlumpf]

Ich rede nicht davon ein Zertifikat auf 20 gleiche Server hochzuladen, sondern ein Zertifikat auf 20 verschiedenen Systemtypen zu verwenden.
Z.B. wenn du *.mgmt.meinefirma.de für die Management-Logins diverser Webinterfaces (Firewalls, Switches, LBs bis hin zur Klimaanlagensteuerung des Büros) benutzt, natürlich abteilungsübergreifend.
Es reicht ja wenn 2 dabei sind, die du nicht ohne weiteres automatisch updaten kannst und schon hast du alle 3 Monate die Update-Not.

Geht nicht immer von der Frickelbude oder Google aus, es gibt auch Firmen dazwischen.
Da braucht nur irgendwo im 1000 Mitarbeiter-Konzern ne Policy existieren, dass man kein self-signed benutzen darf (keiner weiß warum, aber braucht man für die Zertifizierung xy).
Da ist die Kohle fürs Zertifikat evtl. überhaupt nicht von Belang.
Da gibts evtl. auch nicht mal eben ne DevOps Abteilung, die sowas nebenbei in Ansible zusammenschustert.

Ich will euch ja LE nicht ausreden (habs selber testweise laufen und würde privat nie Geld für ein SSL-Zertifikat ausgeben wollen), aber deren Grundidee funktioniert nicht überall in der Wirklichkeit.

 

[GokuSS4]

Ein A wäre besser als ein B, ja. Aber im Vergleich zur Konkurrenz ist ein B offenbar richtig gut: Heise (F), Golem (F), PCGH (F), WinFuture (F), CHIP (F), Mobilegeeks (F).

@Steffen

Gibt es ne bessere Alternative zu den aktuell eingesetzten Headern?
Referrer Policy: "no-referrer-when-downgrade" -> "no-referrer", "same-origin", "strict-origin" or "strict-origin-when-cross-origin" ?

Wie wäre es mit X25519 und als Fallback P-256?
https://www.rochestersecurity.org/wp-content/uploads/2017/10/RSS2017-T2-Testa.pdf
Im OpenSSL Changelog liest man auch sowas:

*) Change the ECC default curve list to be this, in order: x25519,
secp256r1, secp521r1, secp384r1.
[Rich Salz]



Und Cipher vielleicht idealerweise so (nur GCM statt CBC, TLS 1.2 statt 1.1 und 1.0 und PFS)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)

 

[Der-Orden-Xar]

Und Cipher vielleicht idealerweise so (nur GCM statt CBC, TLS 1.2 statt 1.1 und 1.0 und PFS)

Das wäre zwar Stand jetzt das sicherste, das machbar ist, aber CB wird sicher nicht übermäßig viele Menschen aussperren wollen.
Und mit ECDHE+GCM only sperrt man alles IE User (außer IE 10), Android vor 4.4, Safari bis Version 8 und noch ein paar andere.

Interessanter fände ich da, die Dinge ohne PFS oder 3DES zu killen.

Zudem: Selbst die Mozilla modern Empfhelung nutzt noch CBC. Steffen hat erst kürzlich geschrieben, dass er sich an der Intermediate Empfehlung dort hält.

 

[GokuSS4]

Es würde Windows XP/Vista User treffen, wer damit online geht ist ja auch selbst schuld. Und ab Android 4.1+ lässt sich ja auch die aktuellste Version von Google Chrome statt des AOSP Browsers nutzen. Könnte doch einfach mal ne Warnung sein: Bitte Browser aktualisieren?

 

[knoxxi]

Die Meldung "Bitte Browser aktualisieren" bekomme ich auch dauernd, obwohl ich mit dem Firefox nightly am PC unterwegs bin

 

[GokuSS4]

mit dem IE lässt sich die Seite garnicht erst öffnen

 

[Steffen]

Gibt es ne bessere Alternative zu den aktuell eingesetzten Headern?
Referrer Policy: "no-referrer-when-downgrade" -> "no-referrer", "same-origin", "strict-origin" or "strict-origin-when-cross-origin" ?

Ich glaube teilweise war dafür bis vor rund einem Jahr der Browser-Suppport noch recht mau (Chrome, Firefox). Ich bin mir spontan auch nicht sicher, ob wir das Senden des Referrers an externe Seiten wirklich immer unterdrücken sollten. Im Online-Banking-Interface meiner Bank würde ich das erwarten, aber in unserem Fall sehe ich das nicht so eindeutig. Es ist ja durchaus interessant zu wissen, wo man verlinkt wird. (Und wer der Meinung ist an keine Website sollten externe Referrer gesendet werden, der kann auch den eigenen Browser entsprechend konfigurieren.)

Wie wäre es mit X25519 und als Fallback P-256?

Das erfordert soweit ich weiß OpenSSL 1.1, wir nutzen noch 1.0.2. Ich denke auf OpenSSL 1.1 werden wir erst wechseln, "wenn es sich richtig lohnt" (also sobald es eine stabile Version von OpenSSL 1.1 mit Unterstützung für TLS 1.3 gibt). Aber das dürfte ja schon in den nächsten paar Monaten der Fall sein.

Und Cipher vielleicht idealerweise so (nur GCM statt CBC, TLS 1.2 statt 1.1 und 1.0 und PFS)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)

Ende Juni 2018 werden einige andere Websites TLS 1.0 und 1.1 abschalten müssen, um weiterhin PCI-compliant zu sein. Unser TLS-Setup wird aktuell schon mit A+ benotet und ich denke nicht, dass wir da jetzt weiter vorpreschen sollten, denn wer nur noch TLS 1.2 unterstützt sperrt zum Beispiel IE 8-10 und Android 4 aus (https://caniuse.com/#feat=tls1-2). Wenn die Betroffenen plötzlich nur auf ComputerBase nicht mehr zugreifen können, dann vermuten sie das Problem natürlich bei CB. Wenn hingegen mehrere Websites betroffen sind, dann vermutet der Nutzer das Problem vermutlich eher bei sich. Ich denke das wäre angesichts der nicht gebotenen Dringlichkeit für alle besser.

Bei den Ciphers halte ich mich an die "Intermediate"-Empfehlung von Mozilla. Hier wird/wurde über Änderungen diskutiert: https://github.com/mozilla/server-side-tls/issues/178 (ich vermute da wird es im Zuge des Inkrafttretens der PCI-Richtlinien und der Einführung von TLS 1.3 nochmal vorangehen)

Was wir in absehbarer Zeit eventuell machen ist, 3DES abzuschalten. Denn diese Cipher wird ja nur noch für IE8 unter Windows XP gebraucht und ich glaube das neue Forum unterstützt CSS- und JS-technisch IE8 ohnehin kaum noch oder gar nicht mehr, so dass wir im Rahmen der Einstellung des Supports für IE8 auch direkt 3DES kicken können.

mit dem IE lässt sich die Seite garnicht erst öffnen

Welche?

 

[GokuSS4]

Das erfordert soweit ich weiß OpenSSL 1.1, wir nutzen noch 1.0.2. Ich denke auf OpenSSL 1.1 werden wir erst wechseln, "wenn es sich richtig lohnt" (also sobald es eine stabile Version von OpenSSL 1.1 mit Unterstützung für TLS 1.3 gibt). Aber das dürfte ja schon in den nächsten paar Monaten der Fall sein.

wäre es nicht sinnvoll im Zuge des Upgrades auf Xenforo direkt auch auf OpenSSL 1.1 zu gehen? 1.1.1 steht schon in den Startlöchern und ich schätze 1.1 ist stable

Ende Juni 2018 werden einige andere Websites TLS 1.0 und 1.1 abschalten müssen, um weiterhin PCI-compliant zu sein. Unser TLS-Setup wird aktuell schon mit A+ benotet und ich denke nicht, dass wir da jetzt weiter vorpreschen sollten, denn wer nur noch TLS 1.2 unterstützt sperrt zum Beispiel IE 8-10 und Android 4 aus (https://caniuse.com/#feat=tls1-2). Wenn die Betroffenen plötzlich nur auf ComputerBase nicht mehr zugreifen können, dann vermuten sie das Problem natürlich bei CB. Wenn hingegen mehrere Websites betroffen sind, dann vermutet der Nutzer das Problem vermutlich eher bei sich. Ich denke das wäre angesichts der nicht gebotenen Dringlichkeit für alle besser.

Ja stimmt, da hast du recht.
Android 4.1+ läuft mit der aktuellsten Chrome Version und ist mit TLS 1.3 kompatibel

Bei den Ciphers halte ich mich an die "Intermediate"-Empfehlung von Mozilla. Hier wird/wurde über Änderungen diskutiert: https://github.com/mozilla/server-side-tls/issues/178 (ich vermute da wird es im Zuge des Inkrafttretens der PCI-Richtlinien und der Einführung von TLS 1.3 nochmal vorangehen)

danke für den Link

Was wir in absehbarer Zeit eventuell machen ist, 3DES abzuschalten. Denn diese Cipher wird ja nur noch für IE8 unter Windows XP gebraucht und ich glaube das neue Forum unterstützt CSS- und JS-technisch IE8 ohnehin kaum noch oder gar nicht mehr, so dass wir im Rahmen der Einstellung des Supports für IE8 auch direkt 3DES kicken können.

Es entzieht sich sowieso meinem Verstand überhaupt noch IE8 und Windows XP einzusetzen. Firefox 52 ESR läuft als letzte Version noch auf Windows XP.

Welche?

Naja wenn ich mit dem IE8 und den oben genannten Cipher (bzw. TLS 1.2 only) auf Computerbase.de surfen würde, gäbe es ja gar keinen Handshake
Der Nutzer würde ja leider kein "Sorry dein Browser ist einfach zu alt" als Fehlermeldung bekommen.

Ergänzung (23. März 2018)

https://observatory.mozilla.org/analyze.html?host=banking.ing-diba.de#tls
https://observatory.mozilla.org/analyze.html?host=my.n26.com#tls

N26 scheint auch vollständig auf TLS 1.2 zu setzen.
ING bietet leider noch TLS 1.0, TLS 1.1 und Cipher ohne PFS an.

https://tls.imirhil.fr/https/banking.ing-diba.de
https://tls.imirhil.fr/https/my.n26.com

Gut, ist ein anderer Schnack, bei Banking muss das halt auch so sein

 

[Steffen]

wäre es nicht sinnvoll im Zuge des Upgrades auf Xenforo direkt auch auf OpenSSL 1.1 zu gehen? 1.1.1 steht schon in den Startlöchern und ich schätze 1.1 ist stable

Das Forum-Upgrade ist so schon groß genug, da werde ich nicht noch ein OpenSSL-Upgrade obendraufpacken.