1. Foren
  2. Kommentare
  3. Security-Forum
  4. Alle Kommentare zum Artikel
  5. › Let's Encrypt: Immer mehr…

Seit wann bescheinigt ein Zertifikat vertrauenswürdigkeit?

  1. Thema

Neues Thema


  1. Seit wann bescheinigt ein Zertifikat vertrauenswürdigkeit?

    Autor: nille02 28.03.17 - 18:40

    Nur weil eine Website eine Zertifikat benutzt, ist sie noch lange nicht vertrauenswürdig. Ich habe bisher auch noch keinen User vor mir gehabt der anhand eines Zertifikats einer Website mehr Vertrauen entgegengebracht hat als einer ohne.

  2. Re: Seit wann bescheinigt ein Zertifikat vertrauenswürdigkeit?

    Autor: Richtig Steller 28.03.17 - 20:17

    Genau das war *eine* der drei ursprüngliche Aufgabe die TLS erbringen sollte:

    - Integrität
    - Authentizität
    - Vertraulichkeit

    Dieses Säulensystem begann zu bröckeln als Google sich eine SubCA gekauft hat und für ihre zig tausend Server eigene Zertifikate generiert und Nutzung von CertPatrol und Co. damit quasi unmöglich wurde. Heute ist Google damit aber nicht mehr alleine. Und spätestens seit der Einführung von kurzlebigen Zertifikaten ist es damit endgültig vorbei:

    Der normale Nutzer wird schon vor 5 Jahren nicht nach Fingerprints gefragt haben. Der an Sicherheit interessierte Nutzer konnte das aber (und im Zweifel hat es schon gereicht Zertifikate zu beobachten). Heute hat selbst der an Sicherheit interessierte Nutzer keine Möglichkeit mehr. Er kann schlichtweg nicht wissen ob my-dirty-secrets.invalid nun das Zertifikat ausgetauscht hat oder gerade ein MITM-Angriff erfolgt. CAA Records können hier teilweise helfen, wenn das Zertifikat bei einem Einbruch kopiert wurde helfen sie aber auch nicht. Hier würde dann wieder OCSP helfen, aber das hat Google ja aus Performancen-Gründen entfernt (sie setzen lieber auf Pre-loaded CRLs die natürlich ähnlich effektiv sind wie Pre-loaded Phishing Datenbanken...).

    Verschwörungstheorie:
    Google, ein Sponsor von Let's Encrypt, ist seit dem sie selber von der NSA abgeschnorchelt wurden, augenscheinlich sehr an Verschlüsselung interessiert. Doch was ist, wenn das alles nur eine schöne Theateraufführung ist und man durch Massenverschlüsselung das System eigentlich nur schwächt (nie war es leichter als heute zu phishen oder MITM zu sein) bzw. kaschiert, dass hinter dem Endpunkt nicht Schluss ist? ;)

  3. Re: Seit wann bescheinigt ein Zertifikat vertrauenswürdigkeit?

    Autor: Anonymer Nutzer 28.03.17 - 21:36

    Richtig Steller schrieb:
    --------------------------------------------------------------------------------
    > Genau das war *eine* der drei ursprüngliche Aufgabe die TLS erbringen
    > sollte:
    >
    > - Integrität
    > - Authentizität
    > - Vertraulichkeit

    Für extended Validation und vll. noch Organization Validation mag das gelten. Aber es hat noch niemals und wird auch niemals für eine Domain Validation Certificates gelten.

  4. Re: Seit wann bescheinigt ein Zertifikat vertrauenswürdigkeit?

    Autor: uschatko 29.03.17 - 00:06

    RichardEb schrieb:
    --------------------------------------------------------------------------------
    > Richtig Steller schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Genau das war *eine* der drei ursprüngliche Aufgabe die TLS erbringen
    > > sollte:
    > >
    > > - Integrität
    > > - Authentizität
    > > - Vertraulichkeit
    >
    > Für extended Validation und vll. noch Organization Validation mag das
    > gelten. Aber es hat noch niemals und wird auch niemals für eine Domain
    > Validation Certificates gelten.

    Die DV Zertifikate kamen doch erst auf als Start-SSL den Markt aufgerollt hat und dann die Andern nachzogen. Und als leichtfertig die oben genannten Punkte dem Gott https geopfert wurden.

  5. Re: Seit wann bescheinigt ein Zertifikat vertrauenswürdigkeit?

    Autor: Anonymer Nutzer 29.03.17 - 07:00

    Was hat das mit den DV Zertifikaten zu tun? Da musste noch nie der Antragsteller überprüft werden.

    u0schatko schrieb:
    --------------------------------------------------------------------------------
    > RichardEb schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Richtig Steller schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Genau das war *eine* der drei ursprüngliche Aufgabe die TLS erbringen
    > > > sollte:
    > > >
    > > > - Integrität
    > > > - Authentizität
    > > > - Vertraulichkeit
    > >
    > > Für extended Validation und vll. noch Organization Validation mag das
    > > gelten. Aber es hat noch niemals und wird auch niemals für eine Domain
    > > Validation Certificates gelten.
    >
    > Die DV Zertifikate kamen doch erst auf als Start-SSL den Markt aufgerollt
    > hat und dann die Andern nachzogen. Und als leichtfertig die oben genannten
    > Punkte dem Gott https geopfert wurden.

  6. Re: Seit wann bescheinigt ein Zertifikat vertrauenswürdigkeit?

    Autor: fogel666 29.03.17 - 10:40

    Richtig Steller schrieb:
    --------------------------------------------------------------------------------
    > Genau das war *eine* der drei ursprüngliche Aufgabe die TLS erbringen
    > sollte:
    >
    > - Integrität
    > - Authentizität
    > - Vertraulichkeit

    Genau das ist doch was TLS auch macht, TLS hat NICHT die Aufgabe sicherzustellen, dass die Gegenstelle dich nicht abzockt. TLS hat die Aufgabe den Transportweg abzusichern, nicht mehr und nicht weniger. Vertraulichkeit bedeutet hier, dass niemand mitlesen kann, nicht mehr und nicht weniger.

  7. Re: Seit wann bescheinigt ein Zertifikat vertrauenswürdigkeit?

    Autor: Richtig Steller 29.03.17 - 11:52

    Die Bewertung eines Angebots (Abzocke) soll und kann natürlich nicht durch ein Zertifikat erfolgen.

    Vertraulichkeit bezieht sich hier auf die Verschlüsselung, d.h. kann eine dritte Person die Kommunikation einsehen? Dies ist durch TLS prinzipiell sichergestellt (kann nur durch unautorisierte Schlüsselkopien, anfällige Cipher etc. unterwandert werden).

    Die Integrität ist Dank MAC auch gegeben. D.h. sollte es jemand in den Datenstrom schaffen (also die Vertraulichkeit brechen) ist davon auszugehen, dass er nicht unbemerkt die übermittelten Daten verändern kann.

    Es geht um Authentizität. Diese fehlt. Was bringt es mir mich gegen das Abhören und die Manipulation durch Dritte etc. zu schützen wenn ich gar nicht weiß ob ich stattdessen nicht direkt mit diesen kommuniziere? Hierzu muss ich in der Lage sein zu überprüfen ob mein Endpunkt auch wirklich der Endpunkt ist, den ich erwarte. Hierzu müssen mir die Merkmale mit denen ich den Endpunkt eindeutig identifizieren kann vor Verbindungsaufbau bekannt sein. Und das ist ein Problem wenn sich diese Merkmale auf Grund kurzlebiger Zertifikate ständig ändern können. Irgendwann werde ich es verpassen rechtzeitig über eine gesicherte Verbindung die Informationen bzgl. des neuen Zertifikats im Vorfeld zu beziehen. Ab diesem Moment bin ich für MITM stärker verwundbar als je zuvor. Ich bräuchte jetzt einen ganz anderen Kanal um diese Information sicher einzuholen. Den gibt es aber in der Regel nicht...

  8. Re: Seit wann bescheinigt ein Zertifikat vertrauenswürdigkeit?

    Autor: Xar 29.03.17 - 13:04

    Richtig Steller schrieb:
    --------------------------------------------------------------------------------
    > Es geht um Authentizität. Diese fehlt. Was bringt es mir mich gegen das
    > Abhören und die Manipulation durch Dritte etc. zu schützen wenn ich gar
    > nicht weiß ob ich stattdessen nicht direkt mit diesen kommuniziere? Hierzu
    > muss ich in der Lage sein zu überprüfen ob mein Endpunkt auch wirklich der
    > Endpunkt ist, den ich erwarte. Hierzu müssen mir die Merkmale mit denen ich
    > den Endpunkt eindeutig identifizieren kann vor Verbindungsaufbau bekannt
    > sein. Und das ist ein Problem wenn sich diese Merkmale auf Grund
    > kurzlebiger Zertifikate ständig ändern können. Irgendwann werde ich es
    > verpassen rechtzeitig über eine gesicherte Verbindung die Informationen
    > bzgl. des neuen Zertifikats im Vorfeld zu beziehen. Ab diesem Moment bin
    > ich für MITM stärker verwundbar als je zuvor. Ich bräuchte jetzt einen ganz
    > anderen Kanal um diese Information sicher einzuholen. Den gibt es aber in
    > der Regel nicht...

    Das funktioniert aber mit langlebigen Zertifikaten genauso wenig. Denn niemand kann garantieren, dass der Fingerprint von vor 5 Jahren nicht inzwischen zu einem Zertifikat gehört, dass durch Schlamperei des Serverinhabers von dritten kopiert wurde?

    Da muss man an einem anderen Punkt ansetzen (Preloaded Keys, Key/CA-Pinning)

  9. Re: Seit wann bescheinigt ein Zertifikat vertrauenswürdigkeit?

    Autor: Richtig Steller 29.03.17 - 19:48

    Xar schrieb:
    --------------------------------------------------------------------------------
    > Das funktioniert aber mit langlebigen Zertifikaten genauso wenig. Denn
    > niemand kann garantieren, dass der Fingerprint von vor 5 Jahren nicht
    > inzwischen zu einem Zertifikat gehört, dass durch Schlamperei des
    > Serverinhabers von dritten kopiert wurde?

    Leider nicht korrekt.

    Davon abgesehen, dass man sich *immer* mehr als *ein* Merkmal notieren sollte, ist es unmöglich, dass sich Fingerprints gleichen:

    Dieser wird über den Private Key (Modulus), die Zertifikatsmerkmale, Key der CA, Zeit der CA, Random der CA gebildet.

    Selbst wenn es dir gelingt diese Informationen nachzustellen hättest du nur eine 100% Kopie. Wenn du diese Möglichkeit hättest würdest du aber keine MITM-Angriffe fahren sondern den Verkehr direkt am Endpunkt abgreifen, schließlich hast du ja den Private Key..

    Ein anderer Endpunkt wird nie ein Zertifikat mit dem gleichen Fingerprint zeigen können. Und wenn doch, dann ist dieses ungültig, weil bspw. das Merkmal "CN" nicht zu dem Endpunkt passt zu den du verbinden willst.


    > Da muss man an einem anderen Punkt ansetzen (Preloaded Keys,
    > Key/CA-Pinning)

    Preloading skaliert nicht. Du könntest *jetzt* mit deinem ACME Client dein Zertifikat austauschen. Wann glaubst du, kommt das Update via Chrome und Co. beim Nutzer an?

    Außerdem verschiebt das die Trust. Ich mag dir vertrauen, aber noch lange nicht Google die mir erzählen wollen, du nutzt nun Zertifikat X statt Y. Und wie verifiziere ich, dass Google mich nicht belügt (könnte ja sein dass Google einen NSL bekommen hat der sie anweist nur an mich eine andere Liste auszuliefern). Du willst also nach Möglichkeit selber in der Lage sein zu verifizieren.

    CAA Records im DNS sind auch keine Option und würde erst einmal DNSSEC voraussetzen. Am Ende verlagert man auch hier nur das Vertrauen.

    Nein, die Leute müssen begreifen, dass man Vertrauen *nicht* automatisieren kann.

    Das ist so als wenn dein Lieblingsladen sich ständig komplett verändert: Neue Fassade, neues Logo, neuer Name, neue Inneneinrichtung, neue Servicekräfte und neue Namen für die Speisen hat (Beschreibung mag gleich geblieben sein). Ob es wirklich noch DEIN Laden ist weißt du erst, wenn du bestellt und probiert hast. Doch dann kann es schon zu spät sein...

  10. Re: Seit wann bescheinigt ein Zertifikat vertrauenswürdigkeit?

    Autor: pankraf 29.03.17 - 20:44

    Ich beschäftige mich erst seit heute ein bisschen intensiver mit dem Thema und hatte den Eindruck, dass die kurzen Intervalle der Zertifikatneuerstellung durch Let's encrypt mehr Sicherheit bieten.

    Das scheint dann doch nicht so zu sein. Wenn ich die Diskussion hier lese, stellt sich die Frage: Macht es denn überhaupt noch Sinn, HTTPS für eine eher kleine Webpräsenz (z.B. für einen Handwerker) einzurichten ? Und wie soll man den Otto-Normal-Webpräsenz-Inhabern das Für und Wider erklären ? Wahrscheinlich schrecken die meisten dann doch wegen der Mehrkosten davor zurück, eine Verschlüsselung einzurichten bzw. ein Zertifikat zu erwerben...

  11. Re: Seit wann bescheinigt ein Zertifikat vertrauenswürdigkeit?

    Autor: Xar 29.03.17 - 23:47

    Richtig Steller schrieb:
    --------------------------------------------------------------------------------
    > Xar schrieb:
    > ---------------------------------------------------------------------------
    > > Da muss man an einem anderen Punkt ansetzen (Preloaded Keys,
    > > Key/CA-Pinning)
    >
    > Preloading skaliert nicht. Du könntest *jetzt* mit deinem ACME Client dein
    > Zertifikat austauschen. Wann glaubst du, kommt das Update via Chrome und
    > Co. beim Nutzer an?
    >
    > Außerdem verschiebt das die Trust. Ich mag dir vertrauen, aber noch lange
    > nicht Google die mir erzählen wollen, du nutzt nun Zertifikat X statt Y.
    > Und wie verifiziere ich, dass Google mich nicht belügt (könnte ja sein dass
    > Google einen NSL bekommen hat der sie anweist nur an mich eine andere Liste
    > auszuliefern). Du willst also nach Möglichkeit selber in der Lage sein zu
    > verifizieren.

    Zudem sind die statischen listen recht lahm. ABer ja, es verschiebt immer den Punkt wo man Vertrauen muss, aber ein hpkp, der "falsch" führt normalerweise zu einem nicht ignorierenbarem Fehler im Browser und damit wäre so ein ein "versehen" von Google ziemlich schnell öffentlich bekannt.

    Was auch helfen kann ist CT, vorausgesetzt es gibt genug stellen, die die Listen überwachen.

  12. Re: Seit wann bescheinigt ein Zertifikat vertrauenswürdigkeit?

    Autor: Xar 30.03.17 - 00:11

    pankraf schrieb:
    --------------------------------------------------------------------------------
    > Ich beschäftige mich erst seit heute ein bisschen intensiver mit dem Thema
    > und hatte den Eindruck, dass die kurzen Intervalle der
    > Zertifikatneuerstellung durch Let's encrypt mehr Sicherheit bieten.
    >
    > Das scheint dann doch nicht so zu sein. Wenn ich die Diskussion hier lese,
    > stellt sich die Frage: Macht es denn überhaupt noch Sinn, HTTPS für eine
    > eher kleine Webpräsenz (z.B. für einen Handwerker) einzurichten ? Und wie
    > soll man den Otto-Normal-Webpräsenz-Inhabern das Für und Wider erklären ?
    > Wahrscheinlich schrecken die meisten dann doch wegen der Mehrkosten davor
    > zurück, eine Verschlüsselung einzurichten bzw. ein Zertifikat zu
    > erwerben...

    ohne https: Man braucht kein downgrade durchzuführen oder ein Zertifikat fälschen oder Zertifikat ersetzen um den Inhalt des gesendeten zu verändern oder auch nur zu kopieren und zu speichern.

    mit https kannst du erstmal nichts verändern, da durch die Verschlüsselung da wohl kaum was sinnvolles bei rumkommen könnte und das was kopiert wurde nützt dir ohne den Key für die Verschlüsselung bzw einer enormen Rechenpower (mehr Power als die NSA haben dürfte, wenn richtig umgesetzt) auch nicht.

    https kostet aber Zeit & Strom:
    Zeit zumindest fürs einrichten wenn ein Lets encrypt Client genutzt wird. Sonst auch fürs manuelle erneuern. Strom mindestens auf dem Client für den längeren Handshake und das Aushandeln des Schlüssels. Auf dem Server sollte es aber keine Nennenswerten Anstieg der CPU-Last geben.

  13. Re: Seit wann bescheinigt ein Zertifikat vertrauenswürdigkeit?

    Autor: Richtig Steller 31.03.17 - 11:27

    Xar schrieb:
    --------------------------------------------------------------------------------
    > https kostet aber Zeit & Strom:
    > Zeit zumindest fürs einrichten wenn ein Lets encrypt Client genutzt wird.
    > Sonst auch fürs manuelle erneuern. Strom mindestens auf dem Client für den
    > längeren Handshake und das Aushandeln des Schlüssels. Auf dem Server sollte
    > es aber keine Nennenswerten Anstieg der CPU-Last geben.

    SSL kostet auch auf Serverseite. Untersuchungen von MaxCDN und anderen haben aber gezeigt, dass der Aufwand deutlich <5% liegt. Hier kommt es auch auf die Cipher-Wahl an: Kommt ein CPU mit AES-NI Unterstützung zum Einsatz, welche auch von der verwendeten SSL-Bibliothek genutzt werden kann und einigen sich Client und Server dann auf einen AES-Cipher ist das natürlich eine perfekte Kombination. Etwas anders sieht es mobil aus: Während vor allem iOS-Devices so etwas wie AES-NI haben, fehlt dies bei Android-Geräten komplett. Gerade hier ziehen AES-Cipher Performance (welche aber in empfohlenen Konfigurationen ganz vorne in der Cipher-Liste stehen, siehe https://wiki.mozilla.org/Security/Server_Side_TLS). Google hat hierfür aber ChaCha/Poly sehr früh in Android's SSL-Bibliothek integriert (https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/). Können sich Server und Client auf ChaCha/Poly einigen gibt es nirgendwo erwähnenswerte Einbußen. Einziges Problem: Für ChaCha/Poly muss man eine sehr aktuelle SSL-Bibliothek verwenden oder selber patchen. Das ist also nicht sehr verbreitet.

    Zur Frage ob man verschlüsseln sollten: JA! Definitiv. Ich plädiere lediglich dafür das man aufhört SSL als "sicher" zu bezeichnen. Denn sicher gehört definiert. Und die Aussage von früher, "Willst du sicher sein, dass du mit deiner Bank sprichst, dann achte auf das grüne Schloss". sind heute nicht mehr gültig. D.h. die Daten zwischen dir und deinem Endpunkt können zwar für Dritte nicht einsehbar und oder veränderbar sein, du kannst dir aber nicht mehr ohne weiteres sicher sein mit demjenigen zu sprechen, mit dem du sprechen wolltest.

  14. Re: Seit wann bescheinigt ein Zertifikat vertrauenswürdigkeit?

    Autor: Richtig Steller 31.03.17 - 11:57

    Xar schrieb:
    --------------------------------------------------------------------------------
    > Zudem sind die statischen listen recht lahm. ABer ja, es verschiebt immer
    > den Punkt wo man Vertrauen muss, aber ein hpkp, der "falsch" führt
    > normalerweise zu einem nicht ignorierenbarem Fehler im Browser und damit
    > wäre so ein ein "versehen" von Google ziemlich schnell öffentlich bekannt.

    Du übersiehst an der Stelle etwas: Um an die HPKP-Informationen zu kommen, muss ich bereits zu einem Endpunkt verbinden. Wenn ich diesen Endpunkt aber vorher nicht verifizieren konnte, dann sind die HPKP-Informationen nichts wert.

    Wo es hilft: Wenn du https://dein-privater.service betreibst und hier HPKP mit Key-Pinning aktiviert hast und *deine* Browser vorher über eine sichere Verbindung mit diesem Service hast verbinden lassen. Nur dann ist bis zum Ablauf der Header-Informationen (du setzt ja eine max-age-Angabe) sichergestellt, dass diese Browser einen MITM erkennen. Browser die zuvor noch nie mit deinem Dienst verbunden haben sind aber weiterhin angreifbar.

    Es gibt aber eine Einschränkung: Schau' dir doch einmal an wie das HPKP-Preloading von Chrome funktioniert. So gibt es auch nachvollziehbaren Gründen die Möglichkeit HPKP-Informationen zu löschen. Und ja, das kann Google via Update der Liste triggern. Mit anderen Worten: Ein Preloading, was eigentlich die Sicherheit steigern soll indem sichergestellt wird das von Beginn hat per HTTPS zu einem Dienst verbunden wird kann dazu missbraucht werden um gezielt zu schwächen.


    > Was auch helfen kann ist CT, vorausgesetzt es gibt genug stellen, die die
    > Listen überwachen.

    Nein. CT ist nichts anderes wie OCSP. Was hat Google mit OCSP gemacht? Richtig, entfernt. Warum? Weil es laut Google ein Performance-Fresser ist: Neben dem Verbindungsaufbau zur eigentlichen Seite musste man ja auch immer zum OCSP-Server verbinden und nachfragen. Nichts anderes müsste man bei einem CT-Server machen.

    Beachte aber auch, wofür CT steht: Transparenz. D.h. du kannst allenfalls sehen, dass CA X Zertifikat Y irgendwann einmal tatsächlich ausgestellt hat. Ob legitim oder nicht, siehst du nicht. Auch findest du teilweise, wenn du nach CN's suchst, mehrere noch gültige Zertifikate. Du bist nicht in der Lage nur an Hand des CT-Logs zu verifizieren "OK, Zertifikat Z1 war das alte Zertifikat was Mitte April abläuft. Z2 wurde daher offenbar vor Ablauf von Z1 generiert. Oh warte, was ist mit Z3 was nach Z2 erstellt wurde? War Z2 jetzt evtl. ein Fehler weswegen Z3 erstellt wurde oder wurde Z3 unautorisierter Weise erstellt?

    Die Transparenz ist durch den Umstand, dass LE den Markt dominiert, deutlich eingeschränkt: Früher konntest du dir dann noch merken "Die Seite hat bislang CA X genutzt. Ich hätte sicherlich mitbekommen, wenn der Betreiber die CA gewechselt hätte..." Wenn jetzt aber alle bei LE sind wird's schwer.

    Und die Gefahr ist eben real: Es ist schon heute sehr einfach WordPress und Co. zu kompromittieren. Während ich bislang bei DV-Zertifikaten auch noch bestimmte Mailadressen (postmaster@, ssladmin@ etc.) als Angreifer kontrollieren musste reicht es heute wenn ich kurz meine ACME-Challenge hochlade (was wenn ich eine Webanwendung kompromittiert habe meistens kein Problem darstellt) und schon habe ich mir ein neues Zertifikat für die Domain geholt. Du als Betreiber bekommst davon nur Wind, wenn du regelmäßig das CT-Log nach deinem CN durchsuchst. Aber was machst du denn, wenn du dann ein fremdes Zertifikat entdeckst? Du bist nicht in der Lage dieses zu widerrufen. Somit kann dann jemand für mind. 90 Tage deinen Dienst bzw. die Nutzer deines Dienstes angreifen. Wüssten diese, dass du ein Zertifikat mit dem Fingerprint 123 verwendest... so haben sie jetzt keine Chance: Gleiche CA, gleiche Attribute, gültig...



    2 mal bearbeitet, zuletzt am 31.03.17 12:02 durch Richtig Steller.

  15. Re: Seit wann bescheinigt ein Zertifikat vertrauenswürdigkeit?

    Autor: Xar 31.03.17 - 17:02

    Richtig Steller schrieb:
    --------------------------------------------------------------------------------
    > Xar schrieb:
    > > Was auch helfen kann ist CT, vorausgesetzt es gibt genug stellen, die
    > die
    > > Listen überwachen.
    > Nein. CT ist nichts anderes wie OCSP. Was hat Google mit OCSP gemacht?
    > Richtig, entfernt. Warum? Weil es laut Google ein Performance-Fresser ist:
    > Neben dem Verbindungsaufbau zur eigentlichen Seite musste man ja auch immer
    > zum OCSP-Server verbinden und nachfragen. Nichts anderes müsste man bei
    > einem CT-Server machen.

    Chrome kann immer noch OCSP Stapling, was technisch OCSP nur über eine andere Route ist (stark vereinfacht)


    > Beachte aber auch, wofür CT steht: Transparenz. D.h. du kannst allenfalls
    > sehen, dass CA X Zertifikat Y irgendwann einmal tatsächlich ausgestellt
    > hat. Ob legitim oder nicht, siehst du nicht. Auch findest du teilweise,
    > wenn du nach CN's suchst, mehrere noch gültige Zertifikate. Du bist nicht
    > in der Lage nur an Hand des CT-Logs zu verifizieren "OK, Zertifikat Z1 war
    > das alte Zertifikat was Mitte April abläuft. Z2 wurde daher offenbar vor
    > Ablauf von Z1 generiert. Oh warte, was ist mit Z3 was nach Z2 erstellt
    > wurde? War Z2 jetzt evtl. ein Fehler weswegen Z3 erstellt wurde oder wurde
    > Z3 unautorisierter Weise erstellt?

    Wenn Z2 noch gültig ist, läuft irgendwas falsch und wenn es die Arbeitsweise des Admin ist.

    > Und die Gefahr ist eben real: Es ist schon heute sehr einfach WordPress und
    > Co. zu kompromittieren. Während ich bislang bei DV-Zertifikaten auch noch
    > bestimmte Mailadressen (postmaster@, ssladmin@ etc.) als Angreifer
    > kontrollieren musste reicht es heute wenn ich kurz meine ACME-Challenge
    > hochlade (was wenn ich eine Webanwendung kompromittiert habe meistens kein
    > Problem darstellt) und schon habe ich mir ein neues Zertifikat für die
    > Domain geholt. Du als Betreiber bekommst davon nur Wind, wenn du regelmäßig
    > das CT-Log nach deinem CN durchsuchst. Aber was machst du denn, wenn du
    > dann ein fremdes Zertifikat entdeckst? Du bist nicht in der Lage dieses zu
    > widerrufen. Somit kann dann jemand für mind. 90 Tage deinen Dienst bzw. die
    > Nutzer deines Dienstes angreifen. Wüssten diese, dass du ein Zertifikat mit
    > dem Fingerprint 123 verwendest... so haben sie jetzt keine Chance: Gleiche
    > CA, gleiche Attribute, gültig...


    Ja, einfach falsches Zertifikat ist genau das, worum ich mir Gedanken mache, wenn jemand unerlaubt auf meinen Server kommt...

  16. Re: Seit wann bescheinigt ein Zertifikat vertrauenswürdigkeit?

    Autor: Richtig Steller 01.04.17 - 11:58

    Xar schrieb:
    --------------------------------------------------------------------------------
    > Richtig Steller schrieb:
    > ---------------------------------------------------------------------------
    > Chrome kann immer noch OCSP Stapling, was technisch OCSP nur über eine
    > andere Route ist (stark vereinfacht)

    OCSP-Stapling kann keine Lösung sein: Zum einen unterstützt die breite Masse an Hostern kein OCSP-Stapling. Man kann zwar überall nun ein LE-Zertifikat per Klick holen, aber OCSP können sie nicht.

    Und auch hier haben wir wieder ein Henne-Ei-Problem: Ich erhalte den OCSP-Status erst nachdem ich mich mit dem Server verbunden habe. Es ist zwar nicht ganz so dramatisch, weil der OCSP-Status ja von der CA signiert wurde. D.h. ein Angreifer wird ihn nicht fälschen, aber wozu auch:

    Mein größtes Problem mit OCSP ist, dass dieses Protokoll schon vor Jahren durch die Praxis verschiedener CAs massiv geschwächt wurde: OCSP-Antworten werden vorgeneriert. Teilweise mit einer Gültigkeit von 7 Tagen.

    Selbst die ganzen Phishing-Filter schaffen es nach am 4. Tag einer Phishing-Kampagne vor dieser flächendeckend zu warnen (viel zu spät, da hier die ersten 24 Stunden zählen, aber das ist ein anderes Thema). Von Seiten HTTPS her hat ein Angreifer nun aber 7 Tage lang eine gültige TLS-Konfiguration die *nicht* auffällt.

    Ganz davon abgesehen, dass OCSP eben nicht gegen das ursprüngliche Angriffsszenario hilft: OCSP würde nur das gerade eingesetzte Zertifikat "schützen". Aber ich kritisiere ja gerade, dass der Nutzer nicht weiß welches Zertifikat vom Betreiber verwendet wird. Also kann der Nutzer nicht wissen ob jetzt das echte Zertifikat "gültig" ist oder doch nur das Zertifikat des Angreifers...


    > Wenn Z2 noch gültig ist, läuft irgendwas falsch und wenn es die
    > Arbeitsweise des Admin ist.

    Die aktuellen Statistiken von/über Let's Encrypt zeigen ganz deutlich, dass offenbar niemand ein Zertifikat widerruft. D.h. die breite Masse geht 30 Tage vor Ablauf hin und holt sich ein neues. Das alte Zertifikat ist dann aber noch 30 Tage gültig...

    Selbst CloudFlare mit ihrem UniversalSSL widerrufen das vorherige Zertifikat nicht, wenn sie zu einem Zertifikat was bereits 48 SANs abdeckt einen weiteren hinzufügen.

    Und es gibt ja auch durchaus valide Gründe, weswegen der CN in mehreren Zertifikaten gleichzeitig geführt wird: Bspw. weil man seine Dienste trennt. Ein Zertifikat für den Webserver, eines für FTP, eines für den Mailserver... gerade wenn man nicht alles auf einem System laufen lässt alles andere als unüblich.

  1. Thema

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Senior Systemingenieur*in für Electronic Warfare (w/m/d)
    Hensoldt, Ulm
  2. Anwendungsbetreuer*in Campus Management System (m/w/d)
    Humboldt-Universität zu Berlin, Berlin
  3. Anwendungsbetreuerin / Anwendungsbetreuer (w/m/d) SAP-Benutzer- und Zugriffsverwaltung
    Berliner Stadtreinigungsbetriebe (BSR), Berlin
  4. IT System Engineer für Softwareinstallationen und Systembetreuung (m/w/d)
    PSI Automotive & Industry GmbH, Berlin

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (bis 17.01.2024)


Haben wir etwas übersehen?

E-Mail an news@golem.de