Posts by .A.

    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.

    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.

    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 hier gezeigte Konfiguration ist korrekt und kann nicht erklären, warum nur der zuletzt aktivierte virtual Host Block berücksichtigt wird. Auch die von Dir am Montag geposteten Listen und NameVirtualHost Direktiven sind korrekt, solange mod_ssl aktiv ist; das ist aber augenscheinlich der Fall.


    Das nächste wäre, in den nicht gezeigten Dateien zu suchen, und dabei insbesondere auf die Include Reihenfolge und doppelt vorkommende Direktiven zu prüfen. Dazu müsstest Du aber den kompletten Inhalt von /etc/apache2 zur Verfügung stellen (als tar, zip o.ä).

    Erstmal ja - oder ist die Migration unter Debian 7 möglich, ohne größere Probleme zu bereiten?

    Dein Problem ist Debian 7. Ab Juni gibt es dafür nicht einmal minimalen Support. Wenn für irgendein genutztes Programm eine Sicherheitslücke veröffentlicht wird, musst die dann wahrscheinlich vorhandenen Patches selbst portieren bzw. die Lücke auch selbst schließen. Wenn Du aktuell keine Zeit für ein Upgrade hast, musst Du Dir jetzt sofort die Zeit nehmen, das Upgrade zu planen, Anfang Juni brauchst Du ein funktionierendes Konzept.

    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.

    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?

    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.

    HSTS-Header dürfen nach RFC 6797 nicht über unverschlüsselte Verbindungen übertragen werden. Statt dessen sollte ein permanent redirect (301) erfolgen.


    Ich gehe inzwischen dazu über, keinen Redirect mehr vorzunehmen. Wenn heute ein Browser unverschlüsselten Content anfordert, dann ist das entweder bewusst so oder ein Fehler des Browsers.

    Nun das scheint so "Standard" zu sein, denn ich hab nie etwas willentlich unterdrückt. Könntest du mir behilflich sein, da dran was zu ändern (link o.ä.) damit mir das nicht wieder passiert.

    Es gibt mehrere Wege:

    1. Wenn Du den Output nicht unterdrückst, schickt cron den Output per Mail.
    2. Du kannst den Output in eine Logdatei schreiben oder durch logger an syslog übergeben.
    3. Du kannst einen watchdog laufen lassen, damit das System bei Problemen sofort neu startet.
    4. Du solltest das System überwachen, damit damit Du bei solchen Situationen künftig sofort Bescheid weißt.

    Nicht alles davon funktioniert bei jeder Fehlerursache. Daher kannst Du diese Maßnahmen gerne auch kombinieren.

    Das letzte was nach syslog passierte, war

    Code
    1. May 16 10:47:01 v22018035818363324 CRON[2562]: (root) CMD (/sbin/fstrim / >/dev/null 2>&1)

    Du wirst aber aufgrund >/dev/null 2>&1 nie herausfinden, ob und wie dies für das Problem verantwortlich ist. Wer schon Fehlermeldungen unterdrückt, sollte wenigstens Fehler ordentlich abfangen.

    In Zukunft gibt es jedoch Schadenersatzanspruch bei DSGVO-Verstößen und das ist ja auch der Anreiz ;)


    Auch Schadenersatz ist nicht neu, nur Ansprüche auf Schmerzensgeld kommen nun hinzu.


    Also hört mit dem Beschweren auf: Wer aktuell gewissenhaft mit personenbezogenen Daten umgeht, wird sich nach dem 25.05. fragen, was dieser Hype eigentlich sollte. "Datenschleudern" hätten ohne GDPR früher oder später Probleme bekommen, nun scheint unzutreffend das Kalenderdatum Panik zu verursachen, statt zutreffend der gefährliche Umgang mit Daten.

    Fast Nichts aus GDPR ist neu. Z.B.

    Ich mein, theoretisch brauchen Firmen jetzt nen double-optin um mir mail zu schicken.

    Brauchst Du heute auch schon.


    Könnte also dazu übergehen sämtliche SPAM mails und email newsletter die ich nach dem 25 bekomme, für dich ich mich aber nie aktiv angemeldet habe, selektiv abzumahnen, ...

    Das geht heute auch schon.

    Auch wenn der Webserver die IP-Adresse nicht in einer Logdatei speichert, verwendet der Webserver während seiner Antwort die IP-Adresse. Das ist nach Art. 3 Nr. 2 GDPR eine Verarbeitung eines personenbezogenen Datums nach Art. 3 Nr. 1 GDPR. Damit besteht auch ohne Speicherung die Pflicht geeignete Maßnahmen zu treffen um die Mitteilungen nach Artt. 12, 15 GDPR zu übermitteln und zu erleichtern. Das macht man üblicherweise in der Datenschutzerklärung.