RFCE016: Crypto for the Masses II – PKI

Mit Clemens Schrimpe arbeiten wir uns im zweiten Teil des Crypto-Ausflugs zum eigentlichen Zielthema durch: Browser-Schlösschen, PKI und Zertifikate.

Nach den Grundlagen in der letzten Sendung, erklärt Clemens Schrimpe im zweiten Teil des Crypto-Ausflugs, wie das Zertifikat sich in ein Crypto-System einfügt. Und da Clemens nicht noch zig-mal erklären möchte, dass https://test.schrimpe.de weder unsicher ist, noch ein abgelaufenes Zertifikat hat, widmen wir uns den Schlösschen in unserem Browsern in gewohnter Sendungslänge. Anna-Lena

Hier Webseiten zum mit klicken
requestforcomments.de
dkb.de
https://1.1.1.1

Shownotes

Podcast unterstützen:

47 Gedanken zu „RFCE016: Crypto for the Masses II – PKI“

  1. Wie immer war auch diese Folge sehr interessant. Obwohl ich seit jetzt 10 Jahren meine eigene kleine private PKI führe und im Studium ein Fachpraktikum Sicherheit im Internet mit Schwerpunkt PKI absolviert habe, konnte ich noch eine Menge neues Zeugs lernen.

    Eine Frage bleibt: Woher bekomme ich einen OCSP-Responder? openssl ocsp ist lt. man nur zum Testen gedacht; außerdem scheint er auf allen Interfaces zu lauschen. Ansonsten hat mein Google nur einen kommerziellen Responder gefunden. Ist der test only disclaimer von openssl nur aus Haftungsgründen da, oder ist der ernstzunehmen? Gibt es irgendeine offene Lösung?

    Antworten ↓

  3. Wieder eine schöne Folge; es würde mich freuen, wenn bald eine neue käme…

    Was inhaltliche Anmerkungen angeht, wurde das meiste schon gesagt bis auf eine Sache: die meisten ungültigen Zertifikate kannst du bei Safari relativ problemlos überbrücken; die einzige Ausnahme (die ich kenne) ist nicht ein abgelaufenes Zertifikat, sondern ein CRL/OCSP widerrufenes Zertifikat – bei einem solchen verweigert Safari konsequent die Verbindung.

    (Das mag sich seit Mai auch geändert haben; aber inzwischen laufen mir immer wieder Blogs über den Weg, die ein abgelaufenes Let’s Encrypt Zertifikat haben wo ich mich dann trotzdem mit verbinde.)

    Antworten ↓

  5. Habe jetzt endlich alle Folgen des Podcasts nachgeholt und freue mich nun auf neue Folgen. Zum neuen Intro/Outro: Ich vermute mal, dass nicht ganz unabsichtlich die Zahlen 791 und 2460 DTMF-kodiert darin versteckt wurden?

    Antworten ↓

  7. Zu den Common Name und Subject Alternative Name ist es mittlerweile (seit 2010) so, dass Clients eigentlich nicht mehr den CN prüfen sollen ausser es gibt kein SAN:

    https://tools.ietf.org/html/rfc2818

    If a subjectAltName extension of type dNSName is present, that MUST
    be used as the identity. Otherwise, the (most specific) Common Name
    field in the Subject field of the certificate MUST be used. Although
    the use of the Common Name is existing practice, it is deprecated and
    Certification Authorities are encouraged to use the dNSName instead.

    Antworten ↓

  10. Und noch ein paar Details zur Einführung mit der Passanalogie:
    – Paesse sind nicht nur in Europa ‘aehnlich’ sondern folgen im ueblichen dem Standard der ICAO (ja, die Luftfahrtmenschen) – da wird also in viel weiterem Rahmen definiert: https://de.wikipedia.org/wiki/Machine_Readable_Travel_Documents
    – Die Nummer mit ‘Du darfst Deine Krypto hier nicht exportieren, jedenfalls nicht ohne Genehmigung’ kann einem auch in .eu gut passieren. Das Schlagwort ist nicht Munition, sondern ‘Dual-Use Good’, sprich: Du koenntest das ja brauchen um die Revolution anzuzetteln. Das Wassenaar Abkommen ist da das Stichwort: https://de.wikipedia.org/wiki/Wassenaar-Abkommen
    – Und die deutschen Kryptoboxen sind in der Tat immer noch Pflicht, aber ein wenig weniger James-Bondig: https://de.wikipedia.org/wiki/Sichere_Inter-Netzwerk_Architektur

    Antworten ↓

  11. Hi, Ihr Lieben,

    wie immer sehr vergnüglich und gewohnt fundiert – für den “Profi” nicht viel Neues, aber immer ein netter Reality-Check, ob man noch auf dem Stand der Technik ist. Das mit den Firmen, die Zertifikate manuell pinnen und trotzdem eines einer “offiziellen” CA verlangen, war mit z.B. dann auch neu. Zum Glück arbeite ich nicht in so einem Umfeld.

    Ein paar Kleinigkeiten hätte ich noch hinzuzufügen.

    1. Das Startdatum der Gültigkeit – das kann einen in einer ganz speziellen Situation beißen: wenn die Uhr des Client-Rechners nach dem Mond geht. Z.B. wenn ein Mac-User einen PRAM-Reset durchgeführt hat und die Kiste denkt, es sei der 1.1.1970 (hab grad nicht auswendig im Kopf, ob Macs da genau wie der Unix-Epoch ticken, aber irgendwas deutlich in der Vergangenheit halt).
    Und dann kommt der Anwender nicht mehr ins mit Enterprise-WPA verwaltete WLAN, also kann sich die Kiste auch nicht per NTP die aktuelle Zeit ziehen …
    Das hatte ich schon mehr als einmal.

    2. Bei den Hotspots im ICE hatte ich das Gefühl, dass Clemens Anna-Lenas Frage nicht 100% verstanden hat. Also so wie ich ihre Eingangsfrage verstanden hatte, ging es darum, wie das Captive-Portal an ein gültiges Zertifikat kommen kann, wenn es doch aus dem Internet nicht erreichbar ist.
    Nun, das Portal verwendet den FQDN login.wifionice.de – die Domain ist offiziell konnektiert und im Internet präsent. Dieser FQDN hat allerdings eine RFC-1918-Adresse als A-Record, aber das ist ja wurst. Es gibt ja Domain-Verification über DNS-Einträge. D.h. auch ohne öffentlich erreichbaren Webserver kann die DB dafür ein Zertifikat bekommen, indem sie einen Record für “Wrzlbrmpft” mit Inhalt “Wrzlbrmft” anlegt, wie Clemens das ja auch so schön erklärt hat.
    Und jetzt kommt der Punkt, auf den ich hinaus will, und den Clemens nicht extra erwähnt hat – das fertige Zertifikat *und* der Private Key sind einfach nur Dateien, die man dann ohne Probleme auf alle Captive-Portals für alle Züge kopieren kann. Oder auf das eine zentrale, das alle Züge versorgt. Es gibt da speziell unter Windows-Admins das Mißverständnis, dass der Private Key und der CSR auf dem Server erzeugt werden müssen, auf dem auch das Zertifikat eingesetzt werden soll. Das ist natürlich kompletter Quatsch, hat aber einen technischen Hintergrund und der hat mit Microsofts Crypto-API zu tun.
    Wenn man beim Generieren eines Private Key auf so einer Windows-Schüssel diesen Key nicht ausdrücklich als “exportierbar” kennzeichnet – nicht exportierbar ist der Default – dann steckt der auf diesem Server im Keystore und kommt da auch nicht wieder raus. Man kann dann genau auf dieser einen Kiste einen CSR generieren und dann das fertige Zertifikat von der CA dazu packen, aber an den Key kommt man nicht mehr.
    Daher habe ich auch immer wieder Kunden-Anfragen der Art “ich möchte mir bei $IRGENDWEM ein Zertifikat kaufen – bitte schicken Sie mir doch einen CSR von dem Webserver, den Sie für mich hosten”. Ich mach die dann immer mit “openssl req -new” auf meinem Mac …

    3. Extended Verification – ich hab einen Kunden, den ich jetzt nicht nennen mag, aber dessen Marketing-Abteilung hat veranlasst, dass das EV-Zertifikat wieder durch ein gewöhnliches ersetzt wird. Grund: die Firma heißt anders als die spezielle Marke, um die es bei der Website geht. Statt “www.blubberlutsch.de” steht da im Browser dann eben schön grün “ABC GmbH” – ohne jeden Verweis auf “Blubberlutsch”. Marketing-Desaster aus der Sicht des Kunden, Rolle rückwärts.
    Ich hätte das ja so gelassen, schließlich steht im Impressum ja auch die “ABC GmbH” und nicht “Blubberlutsch”, aber jeder wie er will ;-)

    Liebe Grüße, weiter so!
    Patrick

    P.S. Die Idee einer “Opa erzählt vom Krieg” Episode finde ich brilliant. Clemens, bis zum heutigen Tag in IOS: ip forward-protocol nd ;-))

    Antworten ↓

  12. Die Pass-Analogie trägt auch noch bei dem Vorgang, dass eine CA jetzt auf einmal “bäh” ist und jemand anders das für Dich als Anwender entscheidet.

    Stellt Euch mal vor wir sind noch in den Neunzigern und jemand kommt mit einem Pass der Deutschen Demokratischen Republik, dessen Ablaufdatum noch in der Zukunft liegt.

    Der Pass ist nicht kaputt – wie Clemens’ StartSSL-Cert. Nur die CA darf jetzt eben nicht mehr mitspielen. Da gibt es sicher Verfahren für – ich kann mir nicht vorstellen, dass man sich darauf verlässt, dass alle Zollbeamten dieser Welt die internationale Politik verfolgen ;-) Dienstanweisung mit Foto eines Passes oder so – wie die Unterschriften im Postamt.

    Oder 1997 beschließt die Republik Zaire, dass sie doch lieber Demokratische Republik Kongo heißen will … kommt gar nicht so selten vor, so was. Zumindest im letzten Jahrhundert.

    Bin beim Hören gerade auf der Zielgeraden (vermute ich), was die politische Seite der CAs angeht – habt Ihr Honest Achmed’s Used Cars and Certificates eingebaut?

    https://bugzilla.mozilla.org/show_bug.cgi?id=647959

    Grüße
    Patrick

    Antworten ↓

  14. Du hast vollkommen Recht damit, daß es natürlich auch gute Gründe geben kann (und gab), mal der einen oder anderen CA (inkl. StartCom) “das Vertrauen zu entziehen”.

    Mir geht es darum, daß in der “öffentlichen Wahrnehmung”, nicht zuletzt durch übereifrige und schlecht erklärte Browser-Meldungen dann auch immer die Nutzer ebendieser CA in Mitleidenschaft gezogen werden: CA böse → Nutzer böse.

    Das ist, was ich anzuprangern versuche.

    Antworten ↓

  15. Noch ein paar kleine Anmerkungen von meiner Seite:

    1. Zum Politischen: Clemens’ Verschwoerungsheorie, nachdem Browserhersteller und CAs unter einer Decke stecken, um Geld zu drucken passt nicht so ganz zur These, dass die boesen Browserhersteller einfach CAs abschalten. Denn es wurde ja nicht nur StartCom/WoSign abgeschaltet, sondern auch Symantec das Vertrauen entzogen, weil sie einfach ihren Job nicht gemacht haben. Auch Mozilla ist dem jeweils gefolgt.

    Geld machen vor allem die CAs und die Wirtschaftspruefer, die die CAs auditieren (zuweil auch erstaunlich mangelhaft, weshalb einige Wirtschaftspruefer bestimmte CAs nicht mehr auditieren duerfen). Browerhersteller haben in erster Linie Arbeit damit, und verdienen AFAIK kein Geld mit ihrem Root-CA-Programm. Vor dem Rauswurf der CAs machte die satirische Bitte von “Honest Achmed” die Runde (https://bugzilla.mozilla.org/show_bug.cgi?id=647959), der die ganze Absurditaet zeigt (CAs machen, was sie wollen). Insofern versuchen die Browserhersteller nun direkt bzw. durch die CAB BRs, die CAs zur Verantwortung zu ziehen.

    Ausserdem herrscht kein Konsens zwischen Browserherstellern und CAs ueber den Sinn von Extended- und Organization-validated Certifiates (EV bzw. OV) und den Mehrwert gegenueber Domain Validated (DV) Certs.

    DV sagt “der Traffic ist verschluesselt”
    EV/OV sagt: “der Traffic ist verschluesselt und die Identitaet des Gegenuebers wurde von der CA geprueft”

    Es ist fragwuerdig, inweiweit die letztere Information ueberhaupt einen Wert besitzt. Denn wie Anna-Lena ist vielen nicht klar, was die veraenderte Darstellung in der Browserleiste bedeutet oder dass es ueberhaupt einen Unterschied gibt. Ausserdem ist sie ueber Browsergrenzen hinweg nicht konsistent und es ist sehr einfach, in einem anderen Land eine 1 Euro-Firma mit gleichem oder aehnlichem Namen zu gruenden (z.B. DKB Ltd.) und sich damit ein EV/OV Cert ausstellen zu lassen. Es braucht allerdings. u.U. etwas Vorbereitung, weil je nach Zertifikatstyp auch Dokumente eingereicht werden muessen, die einen Geschaeftsbetrieb dokumentieren. Doch auch hier gilt: Es braucht nur eine CA beim Ausstellen von EV/OV-Zertifikaten zu schlampen^Wvereinfachen (Wettbewerbsvorteil!), und die ganze Prinzip von EV/OV Zertifikaten ist kompromitiert. Richtig seltsam wird es, wenn Firmen aufgekauft werden, und sie nur noch als Marken mit eigener Webseite fortleben. Dann ist besucht man https://markenbank.de, kriegt auch den Auftritt von “Markenbank”, aber in der Browserleiste steht in gruen “MegaBank, Inc”. Oft kennt aber keiner MegaBank, weil das nur eine Holding ist, die nicht nach aussen auftritt. (das ist in den USA ueblich, leider finde ich den passenden Tweet nicht mehr).

    Ich empfehle https://www.troyhunt.com/on-the-perceived-value-ev-certs-cas-phishing-lets-encrypt/ als Lesestoff.

    (ab hier nur noch technisch \o/)

    2. Die Intermediates Let’s Encrypt Authority X3 und Let’s Encrypt Authority X4 (Backup) haben die Let’s Encrypt Authority X1 und Let’s Encrypt Authority X2 (Backup) ersetzt. Der Grund war, dass die X3 und X4-Zertifikate so gebaut sind, dass sie Windows XP SP3-kompatibel sind, denn XP SP3 kann in der Tat mit SHA-256 umgehen (vgl. https://blogs.technet.microsoft.com/germany/2013/04/15/sha1-sha2-und-windows-xp-windows-server-2003/). Auch die DST Root CA X3 von IdenTrust ist schon im Windows XP Store, nur die von LetsEncrypt (ISRG Root X1) selber nicht. ISRG deshalb, weil die Internet Security Research Group der (gemeinnuetzige Traegerverein von Lets Encrypt ist.

    3. Man kann beide Intermediates (von ISRG Root bzw die DST Root signierten) in die vom Server ausgelieferte Chain werfen. Das ist aber nicht immer mit allen User Agents kompatibel. Fuer bestmoegliche Kompatibilitaet sollte man deshalb vorerst das mit vom DST-Root signierte nehmen. Genauso ist es (unabhaengig) von der CA wichtig, die Intermediates mitzuschicken. Die meisten Browser sind zwar in der Lage, das Intermediate herunterzuladen. Die Erweiterung Authority Information Access (AIA) gibt u.a. Auskunft ueber die Download-Location des Intermediates: CA: http://cert.int-x3.letsencrypt.org/. Generell ist es aber eine schlechte Idee, das Intermediate nicht mitzuliefern: Zum einen unterstuetzen nicht alle Browser und sonstige User Agents (libcurl/curl!) AIA, zum anderen versagt der Mechanismus z.B. dann, wenn nicht voller Zugriff aufs Internet besteht (Hallo WLAN-Portale!).

    4. Beim Prozess des “Ausstellens” und “Unterschreibens” sollte man erwaehnen, dass der private key und die Zertifikatsvorstufe (der sog. Certificate Signing Request) lokal erzeugt werden. Nur der Signing Request (das ist der, wo die CA dann “rummalt” und ihn unterschreibt, wodurch daraus ein Zertifikat wird) wird herausgegeben. Der private key bleibt tunlichst lokal. Es gibt bisweilen Zertifikats-Reseller, die eine Keygenerierung (incl. Backup) auf den eigenen Servern anbieten. Ein gutes Zeichen, dass man von dort keine Zertifikate kaufen will.
    Wer den CSR aufhebt, kann den auch immer wieder neu unterschreiben lassen, also entweder verlaengern, oder aber von mehreren CAs signieren lassen (fuehrt dann zu zwei Zertifikaten fuer den gleichen private key).

    Antworten ↓

    • Meine verschwörungstheoretischen Ausführungen waren mit sehr viel “Geschmunzel” und (hörbaren!) Airquotes versehen …

      Es ist und bleibt auf absehbare Zeit aber ein Geschäft, wo noch durchaus Geld bewegt wird – und wo ein Trog ist … (Ihr kennt das :-)

      Danke für Deine Links – teilw. sehr amüsant!

      Zu 4. & “sollte man erwähnen”: Ich habe es hoffentlich sehr sehr sehr deutlich gemacht, wie mit dem private key umzugehen ist. Wer das jetzt immer noch nicht gerafft hat, verdient, was ihm/ihr bei Nichtbeachtung widerfährt! ;-)

      Antworten ↓

      • Ich hab die Kommentare beim Hören geschrieben. Gegen Ende hast du wirklich hart mit dem Zaunpfahl gewunken, aber da war der obige Kommentar schon geposted :)

        Antworten ↓

        • Vielleicht sollte man RFC-1855 auch auf Podcasts anwenden:

          3.1.3
          “Read all of a discussion in progress (we call this a thread) before posting replies.”

          Antworten ↓

    • “und es ist sehr einfach, in einem anderen Land eine 1 Euro-Firma mit gleichem oder aehnlichem Namen zu gruenden (z.B. DKB Ltd.) und sich damit ein EV/OV Cert ausstellen zu lassen.”
      AFAIK zeigen zumindest Chrome und Safari das jeweilige Land an; und wenn da dann “Berliner Sparkasse (Belize)” steht werde immerhin ich misstrauisch – aber ja, das ganze System ist für den Orthonormalbenutzer nicht sinnvoll.

      Antworten ↓

  17. Guten Morgen Anna-Lena und Clemens,

    wieder eine super Folge. Danke dafür! Ich wollte nur nochmal kurz was zu “Windows und Root-CA Updates” los werden.

    Microsoft verfolgt bzgl. der Trusted Root-CAs einen etwas anderen Ansatz. Während z.B. beim Firefox rund 150 Root-CAs mitgeliefert werden, sind es bei einem frisch installiertem Windows 10 1803 gerade mal ein gutes Dutzend.

    Wenn der Windows CryptoAPI nun ein Zertifikat einer “unbekannten” Root-CA präsentiert wird, prüft die API ob sich dieses Root-CA-Zertifikat auf der Liste des “Microsoft Trusted Root Certificate Program” (http://aka.ms/trustcertpartners) befindet. Falls ja, wird das Root-CA-Zertifikat automatisch im lokalen Certificate Store unter den Trusted Root-CAs abgelegt.

    Dieses “Feature” führt dann natürlich zu dem von Clemens beschriebenen Verhalten: sobald man ein Root-CA-Zertifikat aus dem Store raus kickt und besucht eine Seite, die dieses Root-CA-Zertifikat benötigt, wird es von der CryptoAPI wieder neu hinzugefügt.

    Dieses Verhalten kann auch über eine Gruppenrichtlinie abgeschaltet werden (Administrative Templates\System\Internet Communication Management\Internet Communication\Turn off Automatic Root Certificates Update). Aber dann muss sich der Anwender natürlich selbst drum kümmern, alle Root-CAs in den lokalen Certificate Stroe zu bekommen. Bei nur einem Dutzend vorhandenen dürfte das einiges an Arbeit werden :)

    Daher ist wohl der praktikabelste Weg das Feature nicht zu deaktivieren und stattdessen dem verlinktem Artikel bei Heise aus Pascals erstem Kommentar zu folgen.

    Antworten ↓

  18. Clemens: Dass CAs wie StartCom/Wosign und Symantec aus den Truststores geflogen sind, das haben die sich hart “erarbeitet”, und dafür haben sie mehrfach trotz klarer Warnungen einfach weitergemacht mit ihrem unseriösen Geschäftsgebahren:
    https://wiki.mozilla.org/CA:WoSign_Issues
    https://wiki.mozilla.org/CA:Symantec_Issues

    Beide CAs haben nicht bloß irgendwelche “Stock im Arsch”-Regeln bewusst verletzt wie “Laufzeit darf nicht länger als N Monate sein” oder “Keine SHA1-Zertifikate mehr nach Stichtag X”, sondern haben wiederholt ihre Validierungsmechanismen beim Ausstellen von Zertifikaten nach Strich und Faden verkackt. Ne CA, die offensichtlich nicht willens oder in der Lage ist, sicherzustellen, dass sie keine Zertifikate an unberechtigte Leute ausstellt, hat nichts im Browser verloren, denn sie stellt ein unkalkulierbares Sicherheitsrisiko dar für alle Leute deren Browser/Betriebssysteme ihr vertrauen.

    Bei StartCom/Wosign kommen übrigens noch andere leckere Details dazu:
    – StartCom und Wosign haben teilweise Zertifikate mit doppelten Seriennummer ausgestellt – wie willst du einzelne Zertifikate einer CA zurückrufen, wenn du nicht mal den Seriennummern der Zertifikate trauen kannst? Selbst mit eindeutigen Seriennummern ist das schon schwierig genug (genau deswegen kriegst du bei Let’s Encrypt ja auch nur noch Zertifikate die max. 90 Tage gültig sind).

    – StartCom war eigentlich mal ne israelische Firma, wurde aber “heimlich” an die chinesische CA “Wosign” (gehört nem Typen namens “Richard Wang”) verkauft und auch auf dessen technische Infrastruktur umgezogen. Das wäre erstmal nicht schlimm, wenn man mit diesen Änderungen offen umgegangen wäre. Stattdessen hat man monatelang die eigenen Kunden und die Browserhersteller angelogen und versucht, diese Änderungen zu verheimlichen.

    – Selbst nachdem StartCom/Wosign bei diesen Verstößen erwischt wurden, haben sie monatelang Salamitaktik gespielt, immer nur das zugegeben, was die Browserhersteller ohnehin schon rausgefunden hatten, und nach Strich und Faden versucht, ihre ganzen Verkacker unter den Teppich zu kehren. Als die Google und Mozilla der CA gesagt haben, dass sie den CEO wechseln muss und Richard Wang sich aus dem operativen Geschäft raushalten muss, weil die CA sonst aus den Truststores fliegen wird, hat Wang genau das auch zugesichert, und dann trotzdem weitergemacht.

    Auf der einen Seite beschwerst du dich darüber, dass die Browser/Betriebssysteme ungefragt irgendwelchen CAs trauen die du gar nicht kennst, aber gleichzeitig beschwerst du dich dass die Browser das Geschäftsgebahren dieser CAs prüfen und durchgreifen wenn ne CA nicht nur Mist baut, sondern systematisch und nachweisbar die ganze Zeit rumlügt und vorsätzlich so ziemlich alle denkbaren Regeln verletzt, die für CAs gelten (sollen). Was denn nun?

    Und mal ganz davon abgesehen, haben sowohl Google als auch Firefox sich durchaus Mühe gegeben, den Vertrauensentzug für StartCom/Wosign und Symantec möglichst schmerzfrei zu gestalten. Sie haben u.a. extra Code in ihre TLS-Stacks eingebaut, der bei Zertifikaten dieser CAs nicht abrupt das Vertrauen entzieht, sondern je nach Ausstellungsdatum das Ablaufdatum der Zertifikate vorverlegt – in der Hoffnung, dass die Webseitenbetreiber (und sonstigen Diensteanbieter) ihre Zertifikate austauschen bevor sie von den Browsern abgelehnt werden. Sie hätten durchaus *sehr* viel rabiater vorgehen können, und schlicht die Wurzelzertifikate der CAs “über Nacht” per OneCRL (bei Mozilla/Firefox/Thunderbird) oder CRLsets (bei Google/Chrome) komplett sperren können.

    Zum Thema “Windows installiert ungefragt CA-Zertifikate nach”: Ja, tut es in der Tat noch immer, und das ist leider auch nötig, weil zu viele Deppen Windows-Updates abschalten, und ohne diesen Mechanismus sonst keine Updates für ihren Truststore mehr kriegen würden – wodurch man z.B. kompromittierte CAs (wie Trustwave vor einigen Jahren) nicht mehr sperren könnte. Letztlich ist das ne etwas endanwenderfreundlichere Variante von OneCRL oder CRLsets, weil es dafür sorgt, dass selbst wenn du Windows Updates komplett abschaltest und nie Updates einspielst, du “nie” in die Situation geraten kannst, dass du aus dem HTTPS-Teil des Internets “ausgesperrt” bist, weil alle CAs in deinem Truststore abgelaufen sind, und dein Browser die neuen CAs alle nicht kennt.

    Du kannst natürlich trotzdem CAs das Vertrauen entziehen – aber eben nicht indem du sie aus deinem Truststore löschst, sondern indem du sie auf die Blacklist deines Truststores setzt (bei Firefox und Thunderbird läuft das übrigens genauso):
    https://www.heise.de/security/artikel/Zertifikate-sperren-so-geht-s-3222308.html#nav_windows_1

    Antworten ↓

    • Damit ich nicht nur meckere: Auch wenn der kleine “politische” Teil am Anfang ohne Beißholz schwer erträglich war, war der “unpolitische”/technische Teil des Podcasts echt toll, und auch praktisch durchweg auf dem Stand der Technik.

      Einige unwesentliche Details/Anmerkungen:

      – Bei OCSP-Stapling gibt es mittlerweile auch das Flag “Must-Staple”, das man ins Zertifikat packen kann, und das dem Browser sagt, dass er das Zertifikat ablehnen soll, wenn der Webserver keine gültige OCSP-Antwort von der CA an das Zertifikat drantackert. Das Must-Staple-Flag selber wird dabei allerdings nicht als “critical” markiert, weil sonst die Seite nicht mehr funktionieren würde mit Clients die Must-Staple noch nicht kennen (z.B. “stabile” Linux-Gammeldistros, die uralte Versionen von OpenSSL oder curl ausliefern). Eventuell wäre das aber in ein paar Jahren ne Möglichkeit, Leute dazu zu zwingen, die Gammelsoftware auf ihren Rechnern mal zu updaten… 😈

      – Bei Certificate Transparency gibt es mit dem HTTP-Header “Expect-CT” nen ähnlichen Mechanismus, den aber bislang noch fast kein Browser/Client implementiert, und der leider auch nur für HTTPS und nicht generell für alle TLS-Verbindungen funktioniert. Dazu ist aktuell auch ein RFC in Arbeit: https://tools.ietf.org/html/draft-ietf-httpbis-expect-ct-06

      – Mit “Expect-Staple” gibt es es noch nen HTTP-Header, der eigentlich die gleiche Funktion hat wie “Must-Staple”, aber halt nicht ins Zertifikat eingebaut sein muss und daher besser zum Testen geeignet ist. AFAIK implementiert allerdings nur Google Chrome Expect-Staple.

      – Dass die Zertifikate von Root-CAs von sich selber unterschrieben sind, hat auch die Funktion, dass nicht Dritte nachträglich die Metadaten eines “vertrauten” Root-Zertifikats manipulieren können (z.B. um die Angaben zum CRL Distribution Point oder den OCSP-Servern “verschwinden” zu lassen).

      – CAA-Records werden nur von CAs bei der Ausstellung von CAs berücksichtigt, aber die Browser überprüfen diese Records nicht.

      – HSTS sagt dem Browser nicht, dass er nur bestimmte Zertifikate akzeptieren soll – dafür gibt es HPKP (wofür allerdings grade bei den Browsern der Support wieder rausgeschmissen wird, weil sich wohl zu viele Seitenbetreiber damit in den Fuß geschossen haben, und weil man das für Erpressungsangriffe auf Webseitenbetreiber/Domaininhaber missbrauchen kann). Allerdings sorgt HSTS dafür, dass der Browser für die Seite nur noch gültige Zertifikate einer “richtigen” CA akzeptiert, und keine selbst signierten Zertifikate mehr (Zertifikate von selbst betriebenen CAs, die man in den Truststore gepackt hat, funktionieren damit, aber “snakeoil.pem” funktioniert nicht). Aus demselben Grund ignorieren Browser den HSTS-Header auch, wenn man zum Besuch der Seite irgendwelche Zertifikatsausnahmen einrichten musste.

      Und noch einige Empfehlungen:

      – Man kann bei HSTS auch seine Domain auf eine sog. “HSTS-Preload”-Liste setzen lassen, die fest in alle relevanten Browser (ja, sogar den Internet Explorer) eingebaut und regelmäßig aktualisiert wird, und die erzwingt, dass diese Browser zukünftig bei allen Besuchen auf dieser Domain und auch allen Unterdomains davon HTTPS mit gültigen Zertifikaten erzwingen (und dem Enduser gar keine Option mehr anbieten, ne Ausnahme für ein ungültiges Zertifikat hinzuzufügen). Die Beantragung geht unter https://hstspreload.org/ und dauert i.d.R. wenige Wochen, die Übernahme in die diversen Browser dann üblicherweise wenige Monate. Das ist wunderbar geeignet, wenn man als Admin keinen Bock hat, mit seinem dussligen Management über Sinn oder Unsinn von TLS zu diskutieren, und Fakten schaffen möchte.

      – Ne schöne Übersicht zu diesen ganzen “Zusatzmaßnahmen” gibt’s z.B. in dem Blogpost hier (da sind auch die ganzen RFCs nochmal verlinkt): https://depthsecurity.com/blog/pins-and-staples-enhanced-ssl-security

      – Für E-Mail ist im Moment ein Äquivalent zu HSTS namens “MTA-STS” in Arbeit: https://tools.ietf.org/html/draft-ietf-uta-mta-sts-21
      Es gibt dafür auch schon Tools um den eigenen Mailserver zu testen:
      https://aykevl.nl/apps/mta-sts/
      https://www.hardenize.com/blog/mta-sts

      – Auch für MTA-STS ist eine Art “Preload-Liste” in Arbeit, inkl. konkreter Implementierung für Postfix: https://starttls-everywhere.org/

      – Es gibt sehr schöne Suchmaschinen, mit den man die ganzen TLS-Zertifikate, die an an die diversen Certificate-Transparency-Logs gemeldet wurden, durchsuchen kann – die bekannteste Suchmaschine dürfte wohl https://crt.sh/ sein (wird von der CA “Comodo” betrieben). U.a. weil Google als mit Abstand wichtigster Browserhersteller seit ner Weile CAs zwingt, alle Zertifikate, die sie ausstellen, an eine Mindestanzahl öffentlicher Certificate-Transparency-Logserver zu schicken (unabhängig davon, ob das jeweilige Zertifikate überhaupt für einen Webserver benutzt werden soll), sind da mittlerweile alle Zertifikate von quasi allen relevanten CAs ausgestellt wurden, durchsuchbar. Dadurch werden auch immer wieder Zertifikate gefunden, die nicht hätten ausgestellt werden dürfen, sodass man den CAs jetzt sehr viel besser auf die Finger schauen kann. IIRC meldet Chrome sogar an öffentliche Logserver, wenn es Zertifikate einer CA findet, die keine SCT-“Beglaubigungen” von Certificate-Transparency-Logservern haben – dadurch dürfte es für Geheimdienste zumindest seeeeehr viel schwieriger geworden sein, sich von irgend einer CA “nachgemachte” Zertifikate zu besorgen um damit Verbindungen abzuhören.

      – Wer sich für dafür interessiert, wie Entscheidungen wie “CA X fliegt aus dem Browser” zustande kommen, oder wie das in der Praxis passiert, wenn eine CA den Browserherstellern melden muss, dass sie was verkackt hat, dem kann ich die “MDSP”-Mailingliste (Mozillas dev-security-policy) sehr empfehlen:
      https://lists.mozilla.org/listinfo/dev-security-policy

      – Wer wissen will, wie die sog. “CAB Forum Baseline Requirements” (kurz “BR”), also die gemeinsamen Regeln und Mindeststandards für alle Zertifikate und CAs, zustande kommen, dem kann ich https://cabforum.org/ sehr empfehlen. Da gibt es Mailinglisten, Abstimmungsergebnisse, die Baseline Requirements, Links zu Tools um die TLS-Konfiguration auf dem eigenen Server zu überprüfen. Links zu den Truststore-Regeln der einzelnen Browserhersteller/CAB-Forum-Mitglieder, konkrete Regeln, wie die IT- und Netzwerkinfrastruktur einer CA auszusehen hat und wie da die Sicherheit gewährleistet werden soll, was genau in einem Zertifikat stehen darf (oder eben nicht stehen darf), das von einer CA unterschrieben wird, etc pp.

      – Die Mailingliste der TLS-Working Group der IETF gibt’s hier:
      https://www.ietf.org/mail-archive/web/tls/
      Etwas hübscher: https://mailarchive.ietf.org/arch/browse/tls/
      Ebenfalls sehr empfehlenswert, aber natürlich nochmal etwas “technischer” als MSDP oder das CAB-Forum.

      – Die Diskussionen “Vielleicht doch noch ne Hintertür in TLS 1.3 einbauen?” und die darauf folgenden Reaktionen gibt es u.a. hier:
      https://mailarchive.ietf.org/arch/msg/tls/ix_Pepa3xfZFV5ux0K6Ve4K10uo
      https://mailarchive.ietf.org/arch/msg/tls/E5thH3_A-S4CYZpC9Uf1wLcKteA
      https://mailarchive.ietf.org/arch/msg/tls/zH7IDHlu0RLPTiRjvLUEOuwmSQI

      Und hier das Video davon, als jemand beim IETF-Meeting Ende 2016 in Seoul seinen “TLS visibility”-Vorschlag vorgetragen hat:
      https://www.youtube.com/watch?v=r1_Iz-csDz0&index=65&list=PLC86T-6ZTP5gtLuoSjpTGO_mS5Ly2pfIS&t=55m30s

      Antworten ↓

      • Vielen Dank für die vielen Links und deren Zusammenfassungen!

        Einiges davon kannte ich noch nicht und wusel mich da jetzt mal durch.

        ;-)

        Clemens

        PS: “must-staple” stand auf meiner Liste, habe ich aber, ob der ganzen “Ablenkungen” rechts und links, dann doch vergessen. Danke,

        Antworten ↓

  19. Moin,
    wow, lange Folge. Vielen Dank für eure Arbeit :)
    Konnte wieder eine Menge lernen, ich wusste z.B. auch noch nicht, dass man Zertifikate mehrfach unterschreiben kann. Da schliesse ich mich der Frage meines Vorkommentators Edwin an.

    LG Dennis

    Antworten ↓

    • Nee, “mehrfach unterschreiben” geht nicht – das laßt das Datenformat eines Z nicht zu.

      Aber Du kannst mehrere, von unterschiedlichen CAs unterschriebene, Zs verwenden, indem Du sie auf Deinem Server so hinterlegst als wären sie “Intermediate Certificates” -> schlicht “nebeneinander”. Die meisten Server hauen die einfach zusammen raus und das ist genau das, was Du da auch haben willst.

      Antworten ↓

  20. Klasse! Vielen Dank für den tollen Podcast, dieses Mal war die Durststrecke auch nicht so lang!

    Eine Frage an Clemens:
    Ihr habt gegen Ende über die Möglichkeit gesprochen, einem Server Zertifikate verschiedener Aussteller überzuhelfen.

    Den Spaß kannte ich noch gar nicht, wie geht den das?

    Grüße aus Frankfurt/Umgebung

    Edwin

    Antworten ↓

  21. Guten Tag!

    Als erstes meinen Dank für diesen hervorragenden Podcast. Ich habe alle bisherigen Folgen angehört und festgestellt, dass ich das Internet vorher eigentlich nicht wirklich verstanden hatte. Dass das jetzt wirklich besser geworden ist, daran nagt mein Selbstzweifel. Jedenfalls bleiben Fragen.
    Heute also eine Kinderfrage zu Zertifikaten und wie sie funktionieren:
    Das ganze beruht auf öffentlichen Schlüssel – privatem Schlüssel. Das “Zertifikat” veröffentlicht den öffentlichen Schlüssel, der Domeininhaber behält den privaten Schlüssel für sich.
    Ok, wenn mein Browser also eine Anfrage an einen Server stellt, verschlüsselt er sie mit dem öffentlichen Schlüssel, der Server entschlüsselt mit den privaten Schlüssel den nur er hat und die Verbindung ist sicher.
    Jedoch wie läuft das andersrum? Der Server sendet eine Antwort und verschlüsselt sie – mit dem privaten Schlüssel? Mein Browser entschlüsselt die Antwort dann mit dem öffentlichen Schlüssel und ich kann die Antwort lesen. Aber – kann das nicht jeder? Der öffentliche Schlüssel ist ja bekannt, also könnte nicht jeder der mitschnorchelt die Antwort des Servers entschlüsseln?
    Der Angreifer kennt zwar nicht die Anfragen, aber er kann die Antworten verstehen????
    Was habe ich hier nicht verstanden?

    Danke fürs Lesen.

    Christoph

    Antworten ↓

    • Hi Christoph,
      der Server und dein Client handeln die Keys für die Verschlüsselung aus. Das SSL-Zertifikat dient nicht zum Verschlüsseln der Daten sondern zur Authentifizierung des Servers. Das Key Exchange war in der letzten Folge beschrieben^^

      Grüsse, Dennis

      Antworten ↓

    • Grob vereinfacht: Dein Browser und der Server handeln mittels eines sogenannten “Key Agreement”-Verfahrens ein sog. “Master Secret” aus – das ist mehr oder weniger der Schlüssel, der anschließend benutzt wird, um mit nem symmetrischen Verschlüsselungsverfahren (heute meist AES oder ChaCha20, früher waren auch DES, 3DES und RC4 geläufig) die eigentlich zu übertragenden Nutzdaten zu verschlüsseln.

      Es gibt verschiedene Key-Agreement-Verfahren, die häufigsten sind:
      – RSA (das gleiche RSA, was auch für die Authentifizierung der Zertifikate benutzt wird – allerdings wird es für etwas anderes benutzt)
      – ephemerisches Diffie-Hellman (DHE, bei OpenSSL auch “EDH” genannt)
      – ephemerisches Diffie-Hellman mit Elliptischen Kurven (ECDHE, bei OpenSSL auch “EECDH” genannt)

      RSA ist am ältesten und hat auch am wenigstens Overhead, hat aber große Nachteile:
      – funktioniert nur wenn man auch Zertifikate mit RSA-Schlüsseln benutzt (RSA ist sehr viel langsamer als elliptische Kurven)
      – RSA bietet keine “Forward Secrecy”, d.h. wenn jemand den Server hackt und den Private Key des Serverzertifikats klaut, dann kann er nachträglich verschlüsselte Verbindungen, die er in der Vergangenheit mitgeschnitten hat, entschlüsseln.

      Die beiden Diffie-Hellman-Verfahren sind aufwändiger, haben mehr Overhead, und “normales” Diffie-Hellman (also ohne elliptische Kurven) ist auch *echt* langsam (bzw. verursacht ne hohe CPU-Last auf dem Server – deutlich mehr als ein RSA-Key Agreement). Dafür bieten diese Verfahren “Forward Secrecy”, d.h. auch wenn jemand den Server hackt und den Private Key des Serverzertifikats klaut, kann er nicht nachträglich, sondern nur zukünftige SSL-/TLS-Verbindungen entschlüsseln/angreifen.

      Von den beiden ephemerischen Diffie-Hellman-Spielarten gibt es auch noch “nicht-ephemerische” Varianten (DH und ECDH), allerdings werden die in der Praxis kaum benutzt, weil sie gewissermaßen die Nachteile von RSA mit denen von DHE/ECDHE verbinden) – d.h. sie haben zwar viel Overhead, bieten aber trotzdem keine Forward Secrecy.

      Für RSA kannst du dir das Key Agreement extrem stark vereinfacht etwa so vorstellen:

      1. Client baut ne TCP-Verbindung zum Server auf, fragt nach dem Zertifikat (wenn er, wie heute eigentlich fast alle SSL-/TLS-Clients, SNI benutzt, sagt er dem Server dabei übrigens im Klartext, auf welche Domain er sich verbinden will, damit der Server ihm das passende Zertifikat schicken kann, falls er für mehrere Domains zuständig ist und mehrere Zertifikate hat).

      2. Der Server schickt dem Client das Zertifikat der gewünschten Domain. Das Zertifikat muss natürlich von einer CA unterschrieben sein, der der Client traut. Und weil ein Zertifikat im Wesentlichen ein von einer CA signiertes Bündel von “Public Key” und “Metadaten, z.B. Domainname, Gültigkeitszeitraum, und Angabe der Aussteller-CA” ist, hat der Client jetzt den Public Key des Servers.

      3. Der Client würfelt sich nen zufälligen Schlüssel aus, den er als Master Secret benutzen kann, verschlüsselt dieses Master Secret mit dem Public Key des Servers (den er aus dem Server-Zertifikat hat), und schickt das verschlüsselte Master Secret an den Server.

      4. Der Server entschlüsselt das Ding, und beide Seiten kennen fortan das Master Secret, das sie benutzen, um die eigentliche Nutzdaten vor der Übertragung z.B. mit AES zu verschlüsseln.

      5. Die NSA hat die verschlüsselte Verbindung mitgeschnitten und aufgehoben. Ein halbes Jahr später entdeckt jemand ne Lücke namens “Debian” oder “Heartbleed” oder in OpenSSL, und die NSA zögert nicht lange und nutzt die Lücke aus um sich den Private Key des Servers zu besorgen. Sie kann jetzt in ihren Aufzeichnungen, genau wie vor einem halben Jahr der Server, das verschlüsselte Master Secret mit dem Private Key entschlüsseln, und mit dem so erhaltenen Master Secret dann auch den Rest der Verbindung entschlüsseln.

      Zu Diffie-Hellman gibt es ein seeehr schönes Erklärvideo auf Youtube:
      https://www.youtube.com/watch?v=YEBfamv-_do

      Zu den mathematischen Hintergründen kann ich zwei Vorlesungsvideos von meinem alten Krypto-Prof sehr empfehlen:
      https://www.youtube.com/watch?v=A7Pw9w8wUYI
      https://www.youtube.com/watch?v=nCHTRnVBY2E

      Falls dich das Themengebiet “Kryptologie” interessiert, kannst du dir hier die komplette Vorlesung reinziehen:
      https://www.youtube.com/channel/UCuJu8DOJLMltMt8RcX1tdBw

      Hier gibt’s das Ganze auch auf Englisch, aber das ist ne ältere Version der Vorlesung in niedriger Auflösung:
      https://www.youtube.com/channel/UC1usFRN4LCMcfIV7UjHNuQg/videos

      Da werden so ziemlich alle kryptologischen “Bausteine” aus RFCE015 und RFCE016 erklärt, und auch neueres Zeugs wie elliptische Kurven oder SHA-3.

      Antworten ↓

      • Danke @Pascal

        Den zweiten Schlüsselaustausch, in deinem Kommentar Punkt 3. und 4. hatte ich nicht mitgeschnitten. So macht das ganze Sinn.

        Christoph

        Antworten ↓

  22. Es ist übrigens nicht richtig, dass man einen Personalausweis haben muss. Ein Reisepass alleine reicht auch für die Ausweispflicht und ein Reisepass zusammen mit einer Meldebescheinigung ist äquivalent zu einem Perso, d.h. damit kann man dann auch ein Bankkonto eröffnen, wo die Adresse benötigt wird. Ich hatte auch mehrere Jahre keinen Perso und es war überhaupt kein Problem.

    Viele Leute denken auch, dass es eine Pflicht gibt, den Perso immer dabei zu haben, das muss man aber auch nicht.

    Antworten ↓

    • Wer weder Pass noch Personalausweis besitzt begeht übrigens eine Ordnungswidrigkeit die mit bis zu 5000€ Bußgeld belegt sein kann. Es gibt also doch eine Sanktion.

      Antworten ↓

    • Nun: Wir wissen das.

      Nur möchtegern-Beamte, wie sie bisweilen bei Banken und ähnlichen Institutionen vorkommen, haben ebendieses Memo häufig nicht bekommen.

      #dashabenwirnochniesogemacht
      #dahabenwirschonimmersogemacht

      Antworten ↓

      • Übrigens: In Deutschland werden Bürger über ihren vollständigen Namen, ihr Geburtsdatum und ihr Geburtsort eindeutig “adressiert”. In Spanien ist das der Name und die “DNI” – eine ID die auf jedem Personalausweis steht. Aber eigentlich nichts mit dem Ausweis zu tun hat. Als ich Spanien lebte, habe ich eine NIE (eine ID für Ausländer) bekommen. Die habe ich für alle Verträge, etc (Sogar Zeittickets für die Bahn) gebraucht.
        => Deswegen hat die Rezeptionsdame im spanischen Krankenhaus nach dem Personalausweis gefragt => Sie brauchte irgendeine Nummer für ihr System;)

        Antworten ↓

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert