Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › ROBOT-Angriff: 19 Jahre alter Angriff…

Letsencrypt - Was muss ich tun

  1. Thema

Neues Thema Ansicht wechseln


  1. Letsencrypt - Was muss ich tun

    Autor: __z 13.12.17 - 10:34

    So ganz steige ich da noch nicht durch...
    Ich verwende letsencrypt und in den details im Zertifikat steht RSA 4096.. Das sollte doch reichen.. oder ist das Problem nicht RSA sondern TLS 1.2?

    Oder was muss ich jetzt ändern damit mein Server nicht mehr betroffen ist.

  2. Re: Letsencrypt - Was muss ich tun

    Autor: crypt0 13.12.17 - 10:48

    Das ganze betrifft "nur" die RSA Verschlüsselung - nicht RSA signaturen.
    Am besten alle cipher suites abschalten in denen RSA aber nicht ECDHE vorkommt. Also bsp: TLS_RSA_WITH_AES_128_CBC_SHA deaktivieren. Dagegen bsp. ECDHE-RSA-CHACHA20-POLY1305- SHA256 darf bleiben.



    2 mal bearbeitet, zuletzt am 13.12.17 10:50 durch crypt0.

  3. Re: Letsencrypt - Was muss ich tun

    Autor: __z 13.12.17 - 11:00

    Super Danke, dann geh ich mal auf die Suche wo ich das ändern muss... Kann ja eigentlich nur im Apache sein...

  4. Re: Letsencrypt - Was muss ich tun

    Autor: Anonymer Nutzer 13.12.17 - 11:51

    SSLCipherSuite "ECDHE-RSA-CHACHA20-POLY1305 DHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA DHE-RSA-AES256-SHA256 DHE-RSA-AES256-SHA ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA"

    es lässt sich über die reihenfolge streiten:

    - 128 bit aes ja/nein
    - gcm vor cbc jedenfalls oder auch kein cbc ganz entfernen (viele etwas ältere clients können kein gcm)
    - chacha vor aes? jedenfalls vor aes 128 bzw vor aes mit cbc.
    - ecdhe vor dhe? es ist schneller und sollte sicher genug sein.

    dazu noch:
    - SSLProtocol All -SSLv2 -SSLv3
    - SSLOpenSSLConfCmd Curves secp384r1
    man kann auch bei SSLProtocol auf TLSv1.2 setzen, allerdings können das doch einige clients noch nicht. kommt auf den anwendungszweck an. die ec kurve kann wohl jeder, der ec kurven kann.

    SSLUseStapling on
    mach auch sehr viel sinn.

  5. Re: Letsencrypt - Was muss ich tun

    Autor: delphi 13.12.17 - 12:11

    Der ROBOT-Angriff hat nur sehr eingeschränkt was mit dem RSA-Schlüsselpaar deines Zertifikats zu tun.

    Beim Aufbau einer SSL-/TLS-Verbindung wird zwischen Client und Server eine sogenannte "Ciphersuite" ausgehandelt - das ist eine Kombination mehrere kryptographischer Verfahren.

    Eine Ciphersuite besteht im Regelfall aus 4 Bausteinen:

    1.) Einem Schlüsselaustauschverfahren (z.B. Diffie-Hellman, Diffie-Hellman mit elliptischen Kurven, oder RSA). Von Diffie-Hellman und Diffie-Hellman mit elliptischen Kurven gibt es jeweils noch eine "ephemeral"-Spielart, bei der für jede Verbindung neue Zufallsdaten verwendet werden - dadurch erhält man dann die sogenannte "Perfect Forward Secrecy".

    2.) Einem Authentifizierungsverfahren, also des Signaturverfahrens, auf dem dein Zertifikat basiert (z.B. RSA oder ECDSA)

    3.) Einem symmetrischen Verschlüsselungsverfahren, mit dem bei der Übertragung die eigentlichen Nutzdaten (also halt die großen Datenmengen, die du halt übertragen willst) verschlüsselt werden. Das kann z.B. AES-CBC, AES-GCM, AES-CTR, CHACHA20-POLY1305, 3DES, oder RC4 sein.

    4.) Einem kryptographischen Hashverfahren, z.B. SHA384, SHA256, SHA-1, oder früher auch noch MD5. Allerdings wird bei manchen symmetrischen Verschlüsselungsverfahren, nämlich jenen, die das Feature "AEAD" (auch als "authenticated encryption" bekannt) bieten, kein Hashverfahren mehr benötigt. Zu letzteren Verschlüsselungsverfahren wäre z.B. AES-GCM oder CHACHA20-POLY1305 zu zählen.


    Beim ROBOT-Angriff geht es nur um Ciphersuites, die als Schlüsselaustauschverfahren RSA benutzen. Solche Ciphersuites sollte man aber auch unabhängig vom ROBOT-Angriff ohnehin nicht benutzen (und am besten serverseitig sperren), weil sie keine Perfect Forward Secrecy bieten. Insbesondere da sich nicht komplett ausschließen lässt, dass vielleicht nicht doch auch OpenSSL oder andere TLS-Implementierungen betroffen sein könnten, ist die saubere und nachhaltige Lösung, alle Ciphersuites, die RSA als Schlüsselaustauschverfahren verwenden, serverseitig abzuschalten.

    Bleibt noch die Frage, weswegen ich eingangs geschrieben hab, dass der ROBOT-Angriff "nur sehr eingeschränkt" etwas mit dem RSA-Schlüsselpaar deines Zertifikats zu tun hat. Die einzige Verbindung ist: RSA ist nur dann als Schlüsselaustauschverfahren verfügbar, wenn auch für die Authentifizierung RSA benutzt wird (d.h. wenn du ein Zertifikat verwendest, das auf einem RSA-Schlüsselpaar basiert).


    Eine Übersicht, welche Ciphersuites überhaupt existieren, gibt es hier:
    https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4

    In der Praxis wird die TLS-Implementierung, die dein Server benutzt, nur eine Teilmenge davon implementieren, und davon unabhängig ist auch nicht jede Ciphersuite bei jeder SSL-/TLS-Protokollversion verfügbar. OpenSSL verwendet übrigens z.T. ein leicht abweichendes Namensschema.

    Den Großteil der Ciphersuites aus der Liste will man nicht benutzen. Auf nem modernen Server würde ich grundsätzlich nur noch Suites konfigurieren, die "ECDHE" (nicht "ECDH"!) als Schlüsselaustauschverfahren benutzen. Das wäre also alles, was mit "TLS_ECDHE_" anfängt.

    Aus dieser Untermenge muss man aber immer noch viel Schrott ausschließen, den man nicht haben möchte - am Ende bleiben je nach OpenSSL-Version nur eine Handvoll wirklich guter Ciphersuites übrig, bei denen wirklich alles stimmt.

    Konkret wären beliebige Kombinationen folgender Bausteine okay:

    1.) Schlüsselaustausch: nur ECDHE. Wenn du die Kurven konfigurieren kannst, nimm folgende Kurven in dieser Reihenfolge: X448, X25519, secp521r1/NIST-P521, secp384r1/NIST-P384, secp256r1/NIST-P256 (X448 ist allerdings glaube ich noch nirgendwo implementiert)

    2.) Authentifizierung: ECDSA (als Kurve möglichst secp384r1 bzw. NIST-P384, notfalls auch secp256r1 / NIST-P256). Ggf. RSA mit 4096 Bit als Fallback. Eventuell kommt hier in absehbarer Zeit auch noch "EdDSA" mit den beiden Kurven "curve25519" und "curve448-Goldilocks" dazu, aber bislang ist der entsprechende RFC-Standard leider noch immer nicht fertig.

    3.) Für die symmetrische Verschlüsselung CHACHA20-POLY1305, AES, ARIA, CAMELLIA (AES, ARIA und CAMELLIA aber jeweils *nicht* im CBC-Modus, sondern *nur* im GCM-, CCM- oder CCM_8-Modus!). In der Praxis relevant sind hier nur AES-GCM und CHACHA20-POLY1305, die anderen Verschlüsselungen/Modi sind kaum verbreitet, und die beiden CCM-Modi sind auch sehr langsam.

    4.) SHA256, SHA384.


    Empfehlung für die Praxis: Konfigurier deinen Server nach dieser Anleitung, und zwar für "Modern compatibility":
    https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility

    Wenn du Clients hast, die damit auch im Jahr 2017 noch immer nicht kompatibel sind, dann sind die Chancen hoch, dass du die Clients entweder updaten, oder wegschmeißen und ersetzen solltest. Ein kleiner Fallstrick: Wenn du nen Printserver (z.B. CUPS) betreibst, der von Rechnern mit Windows 7 oder Server 2008r2 benutzt werden, solltest du auf den Clients nach folgender Anleitung noch nen Registry-Fix ausrollen:
    https://support.microsoft.com/help/3140245

    Ohne diesen Fix kann der Printspooler von Windows nur TLS 1.0 (mit entsprechend gammeligen Ciphersuites) benutzen, selbst wenn z.B. der InternetExplorer problemlos TLS 1.2 mit zeitgemäßen Ciphersuites kann. Grade bei Windows 7/Server 2008r2 ist die Unterstützung für zeitgemäße Ciphersuites übrigens besser, wenn du Serverseitig ECDSA-Zertifikate anstatt RSA-Zertifikate verwendest.

  6. Re: Letsencrypt - Was muss ich tun

    Autor: delphi 13.12.17 - 12:27

    bjs schrieb:
    --------------------------------------------------------------------------------
    > - gcm vor cbc jedenfalls oder auch kein cbc ganz entfernen (viele etwas
    > ältere clients können kein gcm)
    Jein - diese Clients sind dann i.d.R. eh schon uralt und kriegen längst keine Sicherheitsupdates mehr. Bei Windows 7 und Server 2008r2 ist es hilfreich, wenn man statt ECDSA-Zertifikate benutzt, weil diese Windows-Versionen GCM-Ciphersuites nur im Zusammenspiel mit ECDSA-Zertifikaten unterstützen.

    > - chacha vor aes? jedenfalls vor aes 128 bzw vor aes mit cbc.
    AES nach vorne, das hat auf vielen Endgeräten (sowohl Desktop-Rechnern als auch Smartphones) Hardwarebeschleunigung, und ist daher schneller und stromsparender. Allerdings sollte man Chacha20-Poly1305 auf jeden Fall als Backup im Hinterkopf behalten, für den Fall, dass z.B. mal jemand nen Angriff auf GCM in TLS 1.2 hinkriegen sollte. Es gibt zwar noch die CCM- und CCM_8-Suites, aber die sind deutlich langsamer als GCM, und werden obendrein bislang AFAIK auch nur von OpenSSL 1.1 implementiert.

    > - ecdhe vor dhe? es ist schneller und sollte sicher genug sein.
    DHE würde ich komplett weglassen. DHE ist nicht nur langsamer, sondern auch aufwändiger zu konfigurieren, und liefert keinen Mehrwert. Alleine das erzeugen einer DH-Gruppe mit ausreichender "Bitanzahl" dauert ne halbe Ewigkeit - insbesondere, wenn man auf dem Server keine haveged laufen hat, das einem den Entropiepool stetig nachfüllt.

    > - SSLProtocol All -SSLv2 -SSLv3
    > - SSLOpenSSLConfCmd Curves secp384r1
    Besser wäre:
    SSLOpenSSLConfCmd Curves X25519:secp521r1:secp384r1:secp256r1

    Allerdings gibts Unterstützung für X25519 erst ab OpenSSL 1.1. Und irgendwann kommt hoffentlich auch noch X448 dazu.

    > man kann auch bei SSLProtocol auf TLSv1.2 setzen, allerdings können das
    > doch einige clients noch nicht. kommt auf den anwendungszweck an. die ec
    > kurve kann wohl jeder, der ec kurven kann.

    Clients, die kein TLS 1.2 können, kriegen eh seit Jahren keine Sicherheitsupdates mehr - je nach Seite würde ich solche Gammelclients bewusst ausschließen, damit die Leute ihre Systeme/Geräte updaten.

    > SSLUseStapling on
    > mach auch sehr viel sinn.

    Es *kann* auch sinnvoll sein, Zertifikate mit dem "MustStaple"-Flag zu benutzen. Allerdings wird das clientseitig glaube ich bislang nur von Firefox implementiert.

  7. Re: Letsencrypt - Was muss ich tun

    Autor: Anonymer Nutzer 13.12.17 - 12:47

    delphi schrieb:
    --------------------------------------------------------------------------------
    > bjs schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > - gcm vor cbc jedenfalls oder auch kein cbc ganz entfernen (viele etwas
    > > ältere clients können kein gcm)
    > Jein - diese Clients sind dann i.d.R. eh schon uralt und kriegen längst
    > keine Sicherheitsupdates mehr. Bei Windows 7 und Server 2008r2 ist es
    > hilfreich, wenn man statt ECDSA-Zertifikate benutzt, weil diese
    > Windows-Versionen GCM-Ciphersuites nur im Zusammenspiel mit
    > ECDSA-Zertifikaten unterstützen.
    mit windows kenn ich mich nicht aus. kann also dazu nichts sagen. ich weiß nicht, wie weit ecdsa bei clients verbreitet ist. ich denke, rsa kann jeder. allso wäre wohl eine idee, beides am server zu unterstützen. das ist durchaus möglich.

    > > - chacha vor aes? jedenfalls vor aes 128 bzw vor aes mit cbc.
    > AES nach vorne, das hat auf vielen Endgeräten (sowohl Desktop-Rechnern als
    > auch Smartphones) Hardwarebeschleunigung, und ist daher schneller und
    > stromsparender. Allerdings sollte man Chacha20-Poly1305 auf jeden Fall als
    > Backup im Hinterkopf behalten, für den Fall, dass z.B. mal jemand nen
    > Angriff auf GCM in TLS 1.2 hinkriegen sollte. Es gibt zwar noch die CCM-
    > und CCM_8-Suites, aber die sind deutlich langsamer als GCM, und werden
    > obendrein bislang AFAIK auch nur von OpenSSL 1.1 implementiert.
    ich hab irgendwo tests gelesen wegen chacha schneller auf android und weniger strom. diese aes offload dinger sind nicht unbeding superschnell bzw stromsparend. nur sind softwareimplementierung auf arm für aes halt noch langsamer. CCM wird wohl erst ab openssl 1.2 oder unterstützt. 1.1 kann es noch nicht. openssl ciphers liefert es für 1.1 noch nicht.

    > > - ecdhe vor dhe? es ist schneller und sollte sicher genug sein.
    > DHE würde ich komplett weglassen. DHE ist nicht nur langsamer, sondern auch
    > aufwändiger zu konfigurieren, und liefert keinen Mehrwert. Alleine das
    > erzeugen einer DH-Gruppe mit ausreichender "Bitanzahl" dauert ne halbe
    > Ewigkeit - insbesondere, wenn man auf dem Server keine haveged laufen hat,
    > das einem den Entropiepool stetig nachfüllt.
    ich bin nach wie vor nicht zu 100ig von ec überzeugt. aber das basiert nicht auf wissen. die dh parameter müssen ja nicht für jeden server dauernd neu erzeugt werden. erzeugt man das einmal im jahr neu, passt das auch. viele tun es gar nicht. ich finde es auch nicht aufwändig zu konfigurieren... was meinst du da zb? es wird aber wohl auf ecdhe hinauslaufen.

    > > - SSLProtocol All -SSLv2 -SSLv3
    > > - SSLOpenSSLConfCmd Curves secp384r1
    > Besser wäre:
    > SSLOpenSSLConfCmd Curves X25519:secp521r1:secp384r1:secp256r1
    x25519 kann openssl noch nicht, soweit ich weiß. openssl ecparam -list_curves listet es für 1.1 nicht auf. ich denke, das kommt erst mit 1.2. 521r1 ist ok, allerdings wohl aktuell noch overkill. 384 bit reichen aus. 256 halte ich für komplett unnötig, da alle clients, die 256 bit können, auch 384 können. ich würde allerdings maximal eben wirklich die 256 bit bei deinem string entfernen. die restlichen können wohl bleiben.

    > > man kann auch bei SSLProtocol auf TLSv1.2 setzen, allerdings können das
    > > doch einige clients noch nicht. kommt auf den anwendungszweck an. die ec
    > > kurve kann wohl jeder, der ec kurven kann.
    >
    > Clients, die kein TLS 1.2 können, kriegen eh seit Jahren keine
    > Sicherheitsupdates mehr - je nach Seite würde ich solche Gammelclients
    > bewusst ausschließen, damit die Leute ihre Systeme/Geräte updaten.
    mag sein, allerdings ist das nicht unbedingt die aufgabe des servers, das zu prüfen. die obige angabe erlaubt tls für sehr viele clients, obwohl sie sicher ist.

    > Es *kann* auch sinnvoll sein, Zertifikate mit dem "MustStaple"-Flag zu
    > benutzen. Allerdings wird das clientseitig glaube ich bislang nur von
    > Firefox implementiert.
    ich würde sogar behaupten, man muss es verwenden.

  8. Re: Letsencrypt - Was muss ich tun

    Autor: /lib/modules 13.12.17 - 13:28

    Mach den Test mit https://www.ssllabs.com/ssltest/ auf deinen Server.
    Es gibt - sollten Probleme auftreten - auch gleich Vorschläge zur Korrektur...

  9. Re: Letsencrypt - Was muss ich tun

    Autor: delphi 13.12.17 - 21:04

    bjs schrieb:
    --------------------------------------------------------------------------------
    > ich hab irgendwo tests gelesen wegen chacha schneller auf android und
    > weniger strom. diese aes offload dinger sind nicht unbeding superschnell
    > bzw stromsparend. nur sind softwareimplementierung auf arm für aes halt

    Für Chacha20 gibt es AFAIK noch nirgendwo Hardware-Beschleunigung, für AES ist sie dagegen schon sehr weit verbreitet (z.B. bei Intel haben das mehr oder weniger alle CPUs ab Haswell, also grob ab 2013). Chacha20 ist AFAIK auch auf Mobilgeräten nur dann schneller, wenn man es gegen reine Software-Implementierungen von AES antreten lässt.


    > CCM wird wohl erst ab openssl 1.2 oder unterstützt. 1.1
    > kann es noch nicht. openssl ciphers liefert es für 1.1 noch nicht.

    Doch, OpenSSL 1.1 kann die CCM-Suites, aber man muss sie explizit einschalten. Versuch mal:
    openssl ciphers -v ALL | grep CCM


    > ich bin nach wie vor nicht zu 100ig von ec überzeugt. aber das basiert
    > nicht auf wissen. die dh parameter müssen ja nicht für jeden server dauernd
    > neu erzeugt werden. erzeugt man das einmal im jahr neu, passt das auch.
    > viele tun es gar nicht. ich finde es auch nicht aufwändig zu
    > konfigurieren... was meinst du da zb? es wird aber wohl auf ecdhe
    > hinauslaufen.

    *Wenn* secp256r1 oder secp384r1 tatsächlich unsicher sein sollten, dann werden die Ciphersuites und Zertifiikate auf deinem eigenen Server vermutlich dein geringstes Problem sein, und zwar unabhängig vom Schlüsseltyp, der für die Zertifikate verwendet wird. ECDHE ist extrem weit verbreitet, und wird in der Praxis fast ausschließlich mit diesen beiden Kurven verwendet. secp521r1 ist nicht so interessant, weil die Kurve clientseitig ohnehin nur noch bei Mozilla standardmäßig aktiv ist (und selbst die überlegen schon, ob sie die Kurve nicht rausschmeißen sollen, so wie Google das vor ner Weile schon gemacht hat). Unter Windows ist secp521r1 zwar glaube ich in schannel auch implementiert, aber standardmäßig abgeschaltet, und muss erst explizit angeschaltet werden.

    Ansonsten kann ich auch empfehlen, sich die Historie der bislang gefundenen Probleme bei TLS anzuschauen. Bei ECDHE und ECDSA wurde AFAIK noch so gut wie nichts gefunden (liegt aber vielleicht auch daran, dass da noch nicht soviel gesucht wurde). Bei DH/DHE hatten wir Logjam (und der Angriff, der Logjam zugrunde liegt, funktioniert genauso mit größeren DH-Gruppen, nur steigen dann natürlich die Kosten für die zu investierende Rechenleistung. Aber das Grundproblem "man muss die Rechenleistung nur einmal pro DH-Gruppe investieren, und kann danach alle Server damit angreifen" bleibt nach wie vor bestehen. Und ganz ehrlich: Wer macht sich denn die Mühe, alle paar Monate ne neue DH-Gruppe zu erzeugen? Noch dazu, wenn es eh langsamer und trotzdem immer noch unsicherer ist als ECDHE, und alle relevanten Clients eh schon seit Jahren ECDHE können?

    Und bei RSA kommt doch gefühlt alle 1-2 Monate wieder jemand um die Ecke, der *wieder* nen neuen Seitenkanalangriff auf Square and Multiply gefunden hat. Mal ist es differential power analysis, dann kommt wieder mal der Xte Timingangriff auf den CPU-Cache oder die CPU-Pipeline, danach kommt wieder jemand, dem es reicht, mal das Smartphone nen Meter neben den Rechner zu legen und mit dem eingebauten Mikro das Spulenfiepen aufzunehmen, und schließlich verkackt dann mal wieder ein Smartcard-Hersteller den CSPRNG, der doch nicht ganz so CS ist wie man es gehofft hatte. Wird Zeit, das RSA-Geraffel endlich durch curve25519 und curve448-Goldilocks zu ersetzen.

    Für Zertifikate wird es auf absehbare Zeit übrigens sowieso keine anderen Kurven als secp256r1 und secp384r1 geben, weil das die einzigen Kurven sind, die die CAB Baseline Requirements erlauben. Natürlich kannst du dir mit OpenSSL selbstsignierte Zertifikate mit Schlüsselpaaren auf anderen Kurven zusammenfrickeln (z.B. Strongswan kann sogar schon X.509-Zertifikate mit ed25519-Schlüsselpaar erzeugen, OpenSSL ist leider noch nicht mal in seiner aktuellen git-Version so weit), aber von ner CA, die in deinem Browser oder deinem Betriebssystem vorinstalliert ist, wirst du nur Zertifikate mit secp256r1- oder secp384r1-Schlüsselpaar signiert kriegen.


    > x25519 kann openssl noch nicht, soweit ich weiß. openssl ecparam
    > -list_curves listet es für 1.1 nicht auf.

    Doch, die Bibliothek kann X25519, nur das "openssl"-Tool listet die Kurve aus unerfindlichen Gründen nicht auf, (und die Manpage tut es auch nicht). Beachte aber, dass das X groß geschrieben sein muss, sonst funktioniert es nicht.


    > ich denke, das kommt erst mit
    > 1.2. 521r1 ist ok, allerdings wohl aktuell noch overkill. 384 bit reichen
    > aus. 256 halte ich für komplett unnötig, da alle clients, die 256 bit
    > können, auch 384 können. ich würde allerdings maximal eben wirklich die 256
    > bit bei deinem string entfernen. die restlichen können wohl bleiben.

    Nein, du brauchst bei elliptischen Kurven die doppelte Schlüssellänge, um das gleiche Sicherheitsniveau wie eine symmetrische Verschlüsselung zu erreichen. Für AES128 braucht man daher ne 256-Bit-Kurve, für AES192 ne 384-Bit-Kurve (wobei es keine Ciphersuites mit AES192 gibt), und für AES256 bräuchte man theoretisch min. ne 512Bit-Kurve. In der Praxis hat man sich aber wohl gedacht, dass der Flaschenhals die asymmetrische Krypto ist, und dass da das Äquivalent von AES192 Overkill genug ist.

    > mag sein, allerdings ist das nicht unbedingt die aufgabe des servers, das
    > zu prüfen. die obige angabe erlaubt tls für sehr viele clients, obwohl sie
    > sicher ist.

    Hängt davon ab, mit welchem Ziel man seine Internetseite betreibt. Das Problem ist: Leute machen sich erst Gedanken um Updates, wenn Sachen nicht mehr funktionieren. Wenn man also will, dass die Leute Updates einspielen, muss man halt dafür sorgen, dass Dinge mit unsicheren Softwareversionen nicht mehr funktionieren.

    Bei TLS kommt noch hinzu, dass durch die Unterstützung der veralteten Ciphersuites sehr oft Downgrade-Angriffe möglich werden. Und ich sehe halt nicht ein, die Sicherheit der Seitenbesucher, die sich um Updates kümmern, zu reduzieren, um denjenigen Seitenbesuchern, die sich nicht um Updates kümmern, hinterherzulaufen.

    Wir bauen ja auch nicht flächendeckend Fußgängerunterführungen in die Städte um Rücksicht zu nehmen auf Leute die keinen Bock haben, die Bremsen an ihren Autos in Schuss zu halten.


    > ich würde sogar behaupten, man muss es verwenden.

    Vorsicht, die Implementierungen für OCSP-Stapling sind durch die Bank entweder erst gar nicht vorhanden, oder extrem wackelig. Sowohl bei Apache als auch bei nginx fliegt der entsprechende Code beispielsweise schon auf die Fresse, wenn zu dem Zeitpunkt, wo der Webserver gestartet wird, der erste DNS-Lookup für den Hostname des OCSP-Responders der CA fehlschlägt (kommt häufig vor auf Systemen mit systemd-networkd). In so nem Fall zeigt Firefox dir dann nur eine ausgesprochen hässliche und wenig aussagekräftige Fehlermeldung an. Zumindest bei nginx wird darüber hinaus auch die erste Antwort des Servers auf nen HTTPS-Request selbst bei funktionierendem DNS immer ohne OCSP-Response rausgeschickt. Auch das Caching der OCSP-Responses bei beiden Servern hinten und vorne nicht vernünftig (wobei man bei Apache aber wohl immerhin angefangen hat, an einer Lösung zu arbeiten).

    Lies dir dazu auch mal das Blogposting hier von Hanno Böck durch:

    https://blog.hboeck.de/archives/886-The-Problem-with-OCSP-Stapling-and-Must-Staple-and-why-Certificate-Revocation-is-still-broken.html

    Ich hatte damals (als er das Posting geschrieben hat) ebenfalls auf ner gewissen Anzahl an Servern genau dieses Problem, dass die Seiten in Firefox nicht mehr aufrufbar waren, weil bei Let's Encrypt der OCSP-Responder kaputtgegangen war.



    2 mal bearbeitet, zuletzt am 13.12.17 21:14 durch delphi.

  10. Re: Letsencrypt - Was muss ich tun

    Autor: Anonymer Nutzer 14.12.17 - 09:57

    https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ der artikel ist allerdings schon zwei jahre alt und geht nicht auf android devices mit hardware aes ein. allerdings haben die meisten arm systeme eine hardware aes implementierung. aber trotzdem wohl interessant zu lesen. geräte aus dem jahr 2015 sollten allerdings doch noch im einsatz sein.

    die tatsache, dass weder x25519 noch die ccm modi auftauchen lässt mich aber vermuten, dass sich das openssl team nicht sicher ist bei deren einsatz. deshalb bin ich hier einfach noch skeptisch. wenn es zu beiden heißt, "ja, jetzt kann man sie fix einsetzen", dann macht das wohl sinn.

    das gleiche gilt für ec allgemein. es ist neuer als rsa und hat wohl noch nicht die umfassende kryptoanalyse bekommen wie rsa und dhe. ich bin bei so sachen einfach konservativ. es mag grundsätzlich sein, dass viele fehler bei dhe und rsa gefunden wurden.
    hier ein cve, der zwar nur eine curve erwischt hat, allerdings zeigt es, dass ec vor fehlerhafter implementierung nicht automatisch geschützt ist: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-7055

    man muss nur die erzeugung der dh parameter automatisieren. es spricht da nichts dagegen. außerdem muss man es nicht alle monate machen. selbst 2048 bit dhe ist noch für den einsatz für jahre sicher genug. zumindest hab ich nichts anderes gelesen. auf https://weakdh.org/sysadmin.html wird 2048 bit empfohlen. selbst mit 4096 könnte ich keine verzögerung bemerken. es hängt allerdings daovn ab, wie gut die server hardware ist.

    allerdings werden auch bei ec die berechnungen komplizierter. verwendet man 521 ist das wieder last auf den client, die in meinen augen aktuell keinen sicherheitsgewinn gibt. vor allem, wenn man 128 bit aes im einsatz hat. authentifizierung, key exchange und verschlüsselung auf genau die gleiche ebene zu bringen, ist sowieso fast unmöglich, weil es keine so einfache vergleiche gibt.

    "Bei TLS kommt noch hinzu, dass durch die Unterstützung der veralteten Ciphersuites sehr oft Downgrade-Angriffe möglich werden."
    das sollte heutzutage mit https://tools.ietf.org/html/rfc7507 verhindert werden. es ist sehr weit verbreitet. clients, die es nicht unterstützen, unterstützen wohl auch keine guten algorithmen.

    die letsencrypt sache ist mir bekannt. ich denke nicht, dass das je wieder passiert. ein ocsp responder ist im allgemeinen nicht sehr kompliziert und kann auch sehr leicht verteilt betrieben werden. fallen die ocsp responder lange genug aus, gibt es probleme selbst bei den besten implementierungen. eine andere implementierung als jene von apache hilft nur bei ausfällen, die nicht signifikant über die gültigkeitsdauer einer ocsp response gehen. der SSLStaplingCache sollte wohl allerdings mit einer persistenten methode konfiguriert werden.
    alles in allem: ich bleibe bei meiner aussage: must stable ist ein must.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Sahle Baubetreuungsgesellschaft mbH, Greven
  2. Allianz Deutschland AG, Stuttgart
  3. Consors Finanz, München
  4. Wirtschaftsrat der CDU e.V., Berlin

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 7,99€
  2. 0,49€
  3. (-77%) 13,99€
  4. 2,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Watch Dogs Legion angespielt: Eine Seniorin als Ein-Frau-Armee
Watch Dogs Legion angespielt
Eine Seniorin als Ein-Frau-Armee

E3 2019 Elitesoldaten brauchen wir nicht - in Watch Dogs Legion hacken und schießen wir auch als Pensionistin für den Widerstand. Beim Anspielen haben wir sehr über die ebenso klapprige wie kampflustige Oma Gwendoline gelacht.


    Dark Mode: Wann Schwarz-Weiß-Denken weiterhilft
    Dark Mode
    Wann Schwarz-Weiß-Denken weiterhilft

    Viele Nutzer und auch Apple versprechen sich vom Dark Mode eine augenschonendere Darstellung von Bildinhalten. Doch die Funktion bringt andere Vorteile als viele denken - und sogar Nachteile, die bereits bekannte Probleme bei der Arbeit am Bildschirm noch verstärken.
    Von Mike Wobker

    1. Sicherheitsprobleme Schlechte Passwörter bei Ärzten
    2. DrEd Online-Arztpraxis Zava will auch in Deutschland eröffnen
    3. Vivy & Co. Gesundheitsapps kranken an der Sicherheit

    5G-Auktion: Warum der Preis der 5G-Frequenzen so hoch war
    5G-Auktion
    Warum der Preis der 5G-Frequenzen so hoch war

    Dass die Frequenzen für den 5G-Mobilfunk teuer wurden, lasten Telekom, Vodafone und Telefónica dem Newcomer United Internet an. Doch dies ist laut dem Netzplaner Kai Seim nicht so gewesen.
    Eine Analyse von Achim Sawall

    1. Funklöcher Hohe Bußgelder gegen säumige Mobilfunknetzbetreiber
    2. Bundesnetzagentur 5G-Frequenzauktion erreicht 6,5 Milliarden Euro
    3. 5G-Auktion Etablierte wollen Preis für 1&1 Drillisch hochtreiben

    1. Landtag: Niedersachsen beschließt Ausstieg aus DAB+
      Landtag
      Niedersachsen beschließt Ausstieg aus DAB+

      Niedersachsen folgt einem Antrag der FDP und will DAB+ beenden. 5G sei ein besserer Übertragungsweg. Auf die UKW-Abschaltung soll aber verzichtet werden, sagte der Vorsitzende der FDP-Fraktion im Landtag Niedersachsen, Stefan Birkner.

    2. Airseas: Reederei stattet Schiff mit Kite von Airbus-Tochter aus
      Airseas
      Reederei stattet Schiff mit Kite von Airbus-Tochter aus

      Wenn der Wind zieht, soll das Schiff weniger Treibstoff verbrauchen und weniger Schadstoffe emittieren: Die japanische Reederei K-Line testet einen Windhilfsantrieb an einem ihrer Schiffe. Das Segel hat eine Airbus-Ausgründung entworfen.

    3. Pokémon Go mit Harry Potter: Magische Handy-Jagd auf Dementoren
      Pokémon Go mit Harry Potter
      Magische Handy-Jagd auf Dementoren

      Expelliarmus! Mit Smartphone statt Zauberstab kämpfen wir Muggel in der Welt des Harry Potter. Golem.de hat Wizards Unite, hinter dem die Entwickler von Pokémon Go stecken, ausführlich ausprobiert und zeigt echtes Gameplay im Video.


    1. 15:52

    2. 15:41

    3. 15:08

    4. 15:01

    5. 15:00

    6. 13:50

    7. 12:45

    8. 12:20