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

cbtestarossa schrieb:
Habs auch mit CPU-Z auch gecheckt. Core2Quad6600 momentan in dem PC. Sicher kein AES.
Stimmt, hat kein AES-NI: https://ark.intel.com/de/products/2...ocessor-Q6600-8M-Cache-2-40-GHz-1066-MHz-FSB-

cbtestarossa schrieb:
Im FF62 und Palemoon selbe Anzeige bei dem ClientTest.
Im Gegensatz zu Chrome präferiert Firefox AES gegenüber ChaCha20 auch dann, wenn die CPU kein AES-NI beherrscht (war mir bis gerade auch nicht bewusst): https://bugzilla.mozilla.org/show_bug.cgi?id=1279584

Konnte ich gerade auch auf einem Moto G (2015) mit Snapdragon 410 testen. Dieses SoC hat keine Hardware-Beschleunigung für AES (getestet via grep -m1 -o aes /proc/cpuinfo in Termux). Laut https://www.ssllabs.com/ssltest/viewMyClient.html präferiert Firefox dort AES, wohingegen Chrome ChaCha20 präferiert. Folglich nutzt beim Surfen auf ComputerBase auf diesem Smartphone nur Chrome das dort schnellere ChaCha20.

(Auf einem Nexus 5X mit Snapdragon 808 und AES-Support nutzen sowohl Chrome als auch Firefox ChaCha20 beim Surfen auf ComputerBase.)

In deinem Screenshot gehören die ersten drei Ciphers zu TLS 1.3 und wie man sieht steht ChaCha20 dort leider nicht an erster Stelle. Ab Eintrag 4 beginnen die TLS 1.2 Ciphers und auch dort steht ChaCha20 leider nicht an erster Stelle. Um das zu ändern müssten die Firefox-Entwickler sich um den genannten Bug kümmern.
 
  • Gefällt mir
Reaktionen: software2000
Ahja sehr interessant. Also doch die Browser.
Witzigerweise hatte ich aber vor der Umstellung noch CHACHADingsbums.

Ne und habe sogar dann noch Palemoon Portable ohne Addons auch probiert.
Keine Ahnung wo da ne Firewall sein soll. Im OS mal nicht und im Browser ohne irgendwas bestimmt auch nicht.
Und ich bin mir sicher früher zeigte mir die Testseite alles richtig an.
 
cbtestarossa schrieb:
Witzigerweise hatte ich aber vor der Umstellung noch CHACHADingsbums.
Bis vor ein paar Stunden hat unser Server ja auch noch pauschal ChaCha20 gegenüber AES bevorzugt. Jetzt bevorzugt unser Server AES, es sei denn bei dem Client steht ChaCha20 an erster Stelle auf der Cipher-Liste (und dafür sorgt auf Systemen ohne AES-NI leider nur Chrome, aber nicht Firefox, siehe den Bug).

Für Firefox auf Systemen ohne AES-NI war die Änderung vor ein paar Stunden also von Nachteil (weil die jetzt "Software-AES" anstatt ChaCha20 nutzen müssen). Für Chrome auf Systemen ohne AES-NI war die Änderung vor ein paar Stunden neutral (nutzt weiterhin "ChaCha20"). Für vermutlich alle Browser auf Systemen mit AES-NI war die Änderung vor ein paar Stunden von Vorteil (nutzen jetzt "Hardware-AES" anstatt ChaCha20).

Geschwindigkeit: Hardware-AES >>> ChaCha20 >>> Software-AES

Edit: https://calomel.org/aesni_ssl_performance.html
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: software2000
Wo genau ist eigentlich das Problem mit AES in SoCˋs?
Wenn mich nicht alles täuscht, hat Apple AES nativ bereits im A7(?) implementiert. Das wäre dann fünf Jahre her. Samsung hat’s auch schon länger drinnen.

Dementsprechend scheitert es bei den anderen wohl mehr am wollen, denn am können..?
Ergänzung ()

Dazu auch was interessantes beim googlen gefunden. AES512 schneller als 128? Hat da jemand weitere Infos zu..?

https://ieeexplore.ieee.org/document/8096255
 
Apple produziert halt ausschließlich relativ teure Smartphones und kann dort teure High-End-SoCs verbauen, bei denen etwas Aufpreis für zusätzliche Die-Fläche (?) für hardware-beschleunigtes AES keine große Rolle spielt. Die anderen Hersteller bauen in ihre High-End-SoCs soweit ich weiß ebenfalls hardware-beschleunigtes AES ein, aber vielleicht nicht unbedingt bei ihren preiswerteren SoCs für preiswertere Smartphones.

Zum Beispiel unterstützt sogar das drei Jahre alte Nexus 5X (mit damals recht schnellem Snapdragon 808) hardware-beschleunigtes AES. Und ich konnte eben testen, dass das recht preiswerte Moto G6 von 2018 mit Snapdragon 450 ebenfalls hardware-beschleunigtes AES unterstützt. Eventuell war das vor ein paar Jahren bei preiswerteren SoCs / Smartphones noch anders und es wurde an hardware-beschleunigtem AES gespart.

(Ich meine das wurde auch lange als Grund dafür genannt, dass preiswertere Android-Smartphones lange keine Dateisystem-Verschlüsselung genutzt haben, die hätte ohne hardware-beschleunigtes AES schlicht zu viel CPU-Leistung und somit Akku gekostet.)
 
  • Gefällt mir
Reaktionen: Sun_set_1
Der-Orden-Xar schrieb:
Unter 1804 kann Edge auch kein TLS1.3, ich meine unter 1809 auch nicht, habe aber kein System gerade, auf dem ich das testen möchte (bzw keine Lsut zu googeln^^).

Hab hier 1809, TLS1.3 wird in Edge (noch) nicht unterstützt.
 
Hm ja nun frag ich mich halt nur wie kann ich den FF dazu bringen CHACHABings zu bevorzugen.
Ich könnte natürlich AES ganz deaktivieren. Macht aber kein Sinn.
Nur ist die Frage gibt es einen getrennten AES Eintrag für HW und einen für Software?
Oder gäbe es irgendwo einen Wert einzustellen um etwas zu bevorzugen?
 
Danke für TLS 1.3. Was mir aber nun komisch vorkommt heute Mittag hatte ich im Browser TLS 1.3 auf CB nun hab ich aber nur noch TLS1.2 Browser Chrome: Version 72.0.3583.0
Code:
Connection - secure (strong TLS 1.2)
The connection to this site is encrypted and authenticated using TLS 1.2 (a strong protocol), ECDHE_ECDSA with X25519 (a strong key exchange), and AES_128_GCM (a strong cipher).
 
Zuletzt bearbeitet:
Smurfy1982 schrieb:
Hab hier 1809, TLS1.3 wird in Edge (noch) nicht unterstützt.
Unterstützen und unterstützen sind zwei Dinge ;). Gut, das du schonmal getestet hast, dass per default es nicht funktioniert. Ich habe auch in der Regestry die entsprechenden Chiphersuits stehen unter 1803 und 1809, nur habe ich nicht getestet, ob das setzen der Reg-Schlüssel für das Protokoll dieses auch aktiviert, denn ohne Protokoll nutzen die Ciphers nichts Unter 1803 gings nicht, aber nach dem was Steffen verlinkt hat, vermute ich auch unter 1809 nicht.

cbtestarossa schrieb:
Hm ja nun frag ich mich halt nur wie kann ich den FF dazu bringen CHACHABings zu bevorzugen.
Ich könnte natürlich AES ganz deaktivieren. Macht aber kein Sinn.
Nur ist die Frage gibt es einen getrennten AES Eintrag für HW und einen für Software?
Oder gäbe es irgendwo einen Wert einzustellen um etwas zu bevorzugen?
Nein, Firefox besitzt nur ein Ja-nein, keine Präferenz.

AES ganz verbietet macht keinen Sinn,das ist richtig. Aber TLS 1.3 ist wesentlich anders, als seine Vorgänger: Im Firefox bedeutet das setzen des Schalters für eine TLS 1.0-, 1.1- oder 1.2-Chiphersuit, dass diese auch für alle 3 (de)aktiviert wird.
TLS 1.3 nutzt aber (wie schon geschrieben) andere Namen und hat daher auch andere Schlüssel.
Du könntest jetzt also AES unter TLS 1.3 deaktivieren und damit zumindest hier auf computerbase ChaCha nutzen und auf Seiten, die noch kein TLS 1.3 können greift die Änderung eh nicht.

Theobald93 schrieb:
Interessant, dass lt https://www.ssllabs.com/ssltest/viewMyClient.html der Firefox ESR 60.2.2 auch TLS1.3 kann. Bekommt also doch mehr Features als nur die nötigsten Sicherheitsupdates.
cbtestarossa schrieb:
Ne kann er nicht oder nur einen Teil. Ab 63 gehts dann los.
Nope, die ESR kann schon TLS 1.3 und nicht nur teilweise. Jedoch nur als Draft (Draft 23, 26 oder 28, ka welche genau). Ab Firefox 63 dann aber den finalen Standard RFC 8446 . Das führt natürlich zu intressanten situationen, wo ich mit einer neueren Nightlyversion auf einaml nur noch TLS 1.2 zu einem bestimmten Server nutzen konnte, da Mozilla da schneller war als Cloudfare mit dem Update der Draftversion^^
 
  • Gefällt mir
Reaktionen: cbtestarossa
Naja also doch noch nicht ganz.
Denk dann bei FF63 und der nächsten ESR Vollunterstüzung oder kommen dann auch noch Dinge hinzu?
Bin schon neugierig wann Mozilla da nachbessert.
Kann ja nicht sein dass man da nix bevorzugen kann manuell aka Priorität.
Und das bräuchte man auch gar nicht wenn die einfach checken würden ob AES in HW läuft.
Aber zuätzlich manuelles Override is immer gut, denn mit dem Erkennen ist das immer so ne Sache.
 
Zuletzt bearbeitet:
Firefox kann TLSv1.3 erst ab 63 (Release müsste Anfang nächster Woche sein). Vorher sind nur die Draft Versionen drinnen. SSLlabs zeigt bei den Browsern TLSv1.3 an, auch wenn diese lediglich den draft supporten, und nicht den Standard.

AES-GCM in Software richtig zu implementieren ist extrem schwierig. Ob die Software Pfade in Firefox und Chrome deshalb wirklich fehlerfrei sind, und in den nächsten Jahren da nichts gefunden wird, muss sich raus stellen.

Deswegen ist die Geschichte nicht nur eine Performancefrage, sondern zumindest eine kleine, theoretische Sicherheitsfrage - sowohl Google als auch Mozilla scheinen das aber zu akzeptieren, weswegen das wohl nicht so schlimm sein kann. Aber zur Perfektion brauchts halt die Berücksichtigung der Client Präferenz (und das der Client die Präferenz basierend auf HW Features anpasst).

Mit HW Support kann man aber ohne Sorgen AES-GCM nutzen.



Steffen schrieb:
Ich habe den Patch nach einem kurzen Test auf unserem Entwicklungsserver daher jetzt ausnahmsweise direkt in den Live-Betrieb übernommen (falls es doch Probleme geben sollte, kann ich ihn binnen weniger Minuten wieder kicken) und ChaCha in unserer Cipher-Order weiter nach hinten geschoben. SSLLabs meldet jetzt: "This server prefers ChaCha20 suites with clients that don't have AES-NI (e.g., Android devices)". (https://www.ssllabs.com/ssltest/analyze.html?d=www.computerbase.de&s=87.230.75.2)

Vielen Dank! :)

Nice, thumbs up ;)
 
Steffen schrieb:
Wer sich fragt, welche TLS-Versionen der eigene Browser unterstützt, der kann das hier testen: https://www.ssllabs.com/ssltest/viewMyClient.html
Hm, wie muss ich das deuten wenn die Seite einerseits dick rot behauptet mein Browser könnte kein TLS 1.2 und dann unter Protocol-Features bei jeder TLS Version incl. 1.3 ein yes steht?

Browser ist Edge 42.0.0.2549 auf Android 5.1.1 (ist doch schon ein5er... dachte mein Tablet hätte nur ein 4er)
 
Ich zitiere mich mal kurz selbst:
Der-Orden-Xar schrieb:
manchmal klappt da aber einfach bei der Erkennung nicht. War bei mir gerade auch erst im 2. Anlauf korrekt erkannt.
Villeicht auch irgendwein Addon, die Firewall, da Anroid: bei Mobilfunk vielleicht auch die Verbindung.

Der Test nach den Protokollen scheint mir gerne mal etwas buggy zu sein.

Oder deaktivierte Ciphersuits verfälschen den Protokolltest auch interessant, was ich gerade festgestellt habe.

Zum Manuellen Testen:
Für TLS 1.0 bis 1.2: Wenn der Verbindung fehlschlägt heißt das wohl Protokoll nicht unterstützt. Die Prots 10200 und 10300 müssten für SSL 2 und 3 sein, aber 10304 scheint nicht für den TLS 1.3-Test zu sein.
https://www.ssllabs.com:10301/
https://www.ssllabs.com:10302/
https://www.ssllabs.com:10303/
 
Mit dem manuellen Test gings... hab dann nochmal nen reload bei der Testseite gemacht und jetzt sagt er auch das TLS 1.2 geht... und dazu als "Experimental" das TLS 1.3 geht.

Scheint dann ein aktueller Chromium mit passenden TLS Bibliotheken zu sein der da unter der Edge-Oberfläche steckt ;-) aber gut ich hatte ja ursprünglich befürchtet dass das Tablet noch ein 4er Android hätte, aber zumindest ist es schon ein 5er.
 
Zurück
Oben