Frage zu SSL bzw. https

  • ich hab leider noch das alte wcp, nicht das plesk onyx. und bei meinem wcp gibt es die genannte option nicht. (webhosting expert m, hosting117XX)


    danke auch für alle anderen antworten

  • Public Key Pinning ist auch bei Angriffen auf die Verbindung ein Problem. Ohne Aufnahme in die mit Browsern ausgelieferten Dateien kann niemand prüfen, dass der richtige Key gepinnt wird.

  • Public Key Pinning ist auch bei Angriffen auf die Verbindung ein Problem. Ohne Aufnahme in die mit Browsern ausgelieferten Dateien kann niemand prüfen, dass der richtige Key gepinnt wird.

    hier sollte DANE Abhilfe schaffen, welches sich aber mangels DNSSEC-Verbreitung noch länger nicht durchsetzen wird ...

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • mainziman: Das Problem für den rechtmäßigen Betreiber ist aber, daß er ein kompromittertes Zertifikat nicht tauschen kann, ohne dass die Seite über Monate nicht mehr erreichbar ist. Also nutzt man das kompromitterte Zertifikat weiter?

  • mainziman: Das Problem für den rechtmäßigen Betreiber ist aber, daß er ein kompromittertes Zertifikat nicht tauschen kann, ohne dass die Seite über Monate nicht mehr erreichbar ist. Also nutzt man das kompromitterte Zertifikat weiter?

    Kannst Du das genauer ausführen warum dem so sein sollte?

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Weil der Webbrowser beim Enduser den Fingerprint vom Zertifikat speichert und für deine Domain nur den lokalen Fingerprint akzeptiert. Vorgeschlagen wurde hier eine Dauer von 2 bis 3 Monaten.


    Erst wenn der lokale Fingerprint zu dem vom Server ausgelieferten Zertifikat passt, wird die Verbindung aufgebaut. Dann kann auch erst ein Update vom lokalen Fingerprint stattfinden. Dennoch würde hier ein z.B. ein Fingerprint mit Laufzeit 3 Monaten bestehen bleiben.


    Der Workaround im Standard war, immer 2 Fingerprints auszuliefern. Das hilft in der Praxis aber auch, weil du hier immer 2 Zertifikate mit sich überschneidender Laufzeit vorhalten musst.


    Das richtig schöne Problem tritt dann erst auf, wenn du Enduser hast, welche nur sporadisch deine Webseite besuchen. Die haben dann einen alten Fingerprint, aber du hast dann schon auf deiner Webseite auf ein neues Zertifikat gewechselt. Die Leute sperrst du aus.

    Denk dir als Beispiel einfach die günstigen CAs die dir Zertifikate mit Laufzeit 1 Jahr austellen. Die kannst du dann in der Praxis nur 9 Monate nutzen.

    "Security is like an onion - the more you dig in the more you want to cry"

  • Der Workaround funktioniert aber ohnehin nur, wenn zu jedem Zeitpunkt zwei Zertifikate gültig sind und Du zu jedem Zeitpunkt sicherstellen kannst, dass nur eines der beiden kompromittert wird.

  • das sieht mich hier eher konstruiert, und korrekt nebenbei auch nicht ...


    korrekte Vorgehensweise:


    wenn man das implementiert, dann liefert man 2 Pins, einen vom aktiv konfigurierten Zertifikat und einen als Backup, welcher nur vom private Key ist;

    damit ist Dein Punkt 1 und Punkt 3 falsch;


    Browser speichern beide Pins, und auch einen Timestamp; die Speicherung ist nicht ewig;

    so lange es keine Komprimitierung gibt, passiert auch nichts;


    ab dem Zeitpunkt an dem ein Browser diese beiden Fingerprints (= Pins) bekommt akzeptiert er f. die mitgegebene Dauer nur dann eine Verbindung, wenn das Zertifikat zu einem dieser beiden passt;

    wurde der Key komprimitiert, dann installiert man ein neues Zertifikat (dazu hat man einen private Key als Backup);

    bei den Fingerprints (= Pins) wird der vom komprimitierten Key durch einen vom neuen Backup Key ersetzt;


    Dein Punkt 4 ist damit ebenfalls widerlegt;


    auch wenn Du User hast, die nur sporadisch dort "ankommen",

    dann haben diese immer noch deinen alten Backup Pin gespeichert,

    und gelangen so problemlos auf die Site, und aktualisieren deren Pins;


    wurde der Server hingegen in dieser Zeit 2mal oder öfter kompromitiert,

    dann haben diese sporadischen User eben die Erkenntnis,

    daß der Server nicht vertrauenswürdig ist, und sind zu Recht ausgesperrt;


    darum stelle ich Dir als Serverbetreiber die Frage im umgekehrten Sinn:

    wie vertrauenswürdig ist Dein Server, wenn dieser regelmäßig kompromitiert wird?


    falsch implementiert ist HPKP ein Problem, aber korrekt implementiert und angewendet eine feine Sache;


    es geht schließlich nicht darum die Verbindung auf jeden Fall zu bekommen,

    sondern nur wenn diese als sicher und vertrauenswürdig gilt;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Was Du aber nicht berücksichtigst, ist, dass ein Zertifikat bereits dann als kompromittiert anzusehen ist, wenn die Vertrauenswürdigkeit in Frage steht. Der Server selbst braucht nicht kompromittiert sein, es reicht z.B. die personelle Umstrukturierung in einem den Web-Auftritt erstellenden DevOps-Team. Ja, man kann dies auch durch HSM und Shamir's Secret Sharing in den Griff bekommen, nur habe ich dies in der Praxis abgesehen hiervon noch nicht gesehen.

  • die Probleme die man damit hat, sind dem Umstand geschuldet, daß CAs wie LE meist die Verursacher dieser Misere auf Grund der nur 90 tägigen Gültigkeit von SSL Zertitikaten sind;

    Ich zitiere dazu Wikipedia. Du kannst auch das LE-Zertifikat pinnen, dann sind alle von LE ausgestellten Zertifikate gültig. Nicht immer die Probleme von fehlender Automatisierung auf LE schieben.. Alternativ zu HPKP würde ich einen CAA-Record im DNS empfehlen, erfüllt meines Wissens nach den gleichen Zweck, Limitierung der gültigen Zertifikate auf bestimmte CAs.

    Die Liste gültiger Zertifikate kann dabei jedes Zertifikat der Schlüsselhierarchie enthalten. Es ist somit möglich, sowohl End-Zertifikate für die spezifische Domains als auch Zertifikate von Zertifizierungsstellen als gültig zu definieren. Durch letzteres wird jedes von dieser Zertifizierungsstelle signierte Zertifikat akzeptiert

  • Alternativ zu HPKP würde ich einen CAA-Record im DNS empfehlen, erfüllt meines Wissens nach den gleichen Zweck...

    Du meinst TLSA?


    CAA limitiert, welche CAs Zertifikate ausstellen sollen, nicht welche Zertifikate gültig sind.

  • CAA limitiert, welche CAs Zertifikate ausstellen sollen, nicht welche Zertifikate gültig sind.

    Nein, ich meinte CAA ;) Aufgrund der kurzen Gültigkeiten von LE Zertifikaten hatte ich weiter oben ja schon vorgeschlagen, nur auf einzelne CAs, und nicht auf spezifische Zertifikate zu limitieren. Diese Limitierung lässt sich dann sowohl mittels HPKP als auch über einen CAA-Record realisieren.

  • CAA wird nicht vom Browser ausgewertet, vgl. z.B.:

    CAA wird also nicht von Nutzern von Zertifikaten ausgewertet, sondern ausschließlich von Zertifizierungsstellen exakt zum Zeitpunkt der Ausstellung des Zertifikats. Eine Auswertung durch Nutzer zum Zweck der Zertifikatvalidierung ist im RFC explizit ausgeschlossen.

    "Security is like an onion - the more you dig in the more you want to cry"

  • Ich zitiere dazu Wikipedia. Du kannst auch das LE-Zertifikat pinnen, dann sind alle von LE ausgestellten Zertifikate gültig. Nicht immer die Probleme von fehlender Automatisierung auf LE schieben..


    Alternativ zu HPKP würde ich einen CAA-Record im DNS empfehlen, erfüllt meines Wissens nach den gleichen Zweck, Limitierung der gültigen Zertifikate auf bestimmte CAs.

    Punkt 2 wurde darüber schon "beantwortet"


    zu Punkt 1: man pinnt keine CA-Zertifikate - weil wie darüber bereits erwähnt, damit nicht gesehen werden kann, welche Zertifikate gültig sind ...


    auf LE schiebe ich nichts, sondern auf die 0815-Implementierungen; da diese jedesmal - alle 90 Tage - einen neuen private Key generieren; irgendwie zu Recht, irgendwie aber auch nicht;


    ich selbst habe mit LE Zertifikaten HPKP implementiert, ich lasse dabei immer den selben CSR signieren - dies geht nur bei halbautomatischen Lösungen;

    die 31536000 Sekunden sind 365 Tage (1 Jahr);

    Code
    Header always set Strict-Transport-Security 'max-age=31536000; preload'Header always set Public-Key-Pins: 'max-age=31536000; pin-sha256="..."; pin-sha256="..."; report-uri="..."'

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • das sieht mich hier eher konstruiert, und korrekt nebenbei auch nicht ...


    falsch implementiert ist HPKP ein Problem, aber korrekt implementiert und angewendet eine feine Sache;


    Es ist aber nicht alltagstauglich.

    "Security is like an onion - the more you dig in the more you want to cry"

  • auf LE schiebe ich nichts, sondern auf die 0815-Implementierungen; da diese jedesmal - alle 90 Tage - einen neuen private Key generieren; irgendwie zu Recht, irgendwie aber auch nicht;

    Welche sollen das sein? Hast du konkrete Beispiele? LetsEncrypt ist das sicherlich nicht.


    Ausserdem geht es sicherlich nicht um die 08/15 Webseite beim privaten Blogger noch um irgendwelche Spezial-High-Security Webseiten die sicher als jede Bank sein müssen. Sicherheit bringt nur etwas, wenn viele bzw. alle mitmachen.

    "Security is like an onion - the more you dig in the more you want to cry"

  • janxb CAA will Verantwortung der CAs auf Admins verlagern: Wir hätten das Zertifikat niemals ausgestellt, hättest Du den CAA entsprechend gesetzt. Du hast kein CAA? Dann selbst Schuld.

    Ein Client kann CAA nicht prüfen, sondern muss sich darauf verlassen, dass alle CAs sich daran halten. In der Vergangenheit hat dies bei anderen Prüfpflichten der CAs nicht funktioniert...


    Mit TLSA kannst Du für den Client prüfbar die CA limitieren. Dazu setzt Du das Certificate Usages Feld auf 0 oder 2.

  • vmk: alltagstauglich ist relativ; ich betrachte certbot¹ alles andere als das ...


    ¹ auf produktiven Webservern hat alleine nur das notwendige f. die Darstellung der Website etwas verloren;

    (keine Compiler, ...)

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)