Zertifikate per HTTP

S/MIME und Zertifikate sind eine Schlüsseltechnologie für wirklich verschlüsselte Mails. Es muss doch  viel einfacher werden, Zertifikate zu verteilen, damit Signaturen geprüft und Mails verschlüsselt werden können. Vielleicht sogar ohne die Schwachstelle der Zertifizierungsstelle.

Ich habe ein SMIME-Zertifikat, welche ich als CER-Datei zum Download bereitstelle. Warum gibt es keinen Mechanismus, dass sie als Absender sich automatisch dieses Zertifikat holen und Mails an mich verschlüsselt und die Signatur von empfangenen Mails prüfen können?

Muss man das Rad neu erfinden ?

Was war ziemlich genau die Frage, die andere Personen und mich seit vielen Monaten beschäftigt.

  • Natürlich kann ich mein Zertifikat ihnen einfach per Mail senden...
    ...aber dann müsste ich ja vorher schon wissen, dass Sie mir etwas schreiben wollen.
  • Natürlich kann ich mein Zertifikat auf einem Key-Server ablegen ...
    ... aber woher wissen Sie, auf welchem Key-Server der Schlüssel liegt?
    ... und wie stellt der Key-Server sicher, dass es wirklich mein Schlüssel ist?
    ... und wer kommt für die Kosten (Server, Wartung, Bandbreite) den Key-Server auf?
    ... erlaubt ihre Firewall ausgehende Verbindungen auf LDAP-Server oder andere "ungewöhnliche Ports"?
  • Muss denn eine öffentliche CA den Key signieren
    ... meine Webseite nutzt doch SSL. Reicht das nicht als Beweis?

Aktuell scheint es hier keinen automatischen Weg zu geben, mit dem Zertifikate allgemein zugänglich gemacht werden. Ich habe zumindest noch keinen besseren Ansatz im Internet, als RFC o.ä. gefunden.

Kann das die Lösung sein ?

Als habe ich einen Weg gesucht und mir folgendes überlegt.

  • Was spricht eigentlich dagegen, die Zertifikate von Benutzer einer Domäne auf dem Webserver der Domain bereit zu stellen ?
    ... Der Webservice wird von der Firma verwaltet
    ... Die Bezahlung damit auch gesichert
    ... der Domaininhaber hat einen Zugang
    ... per SSL-Zertifikat für die Webseite kann der Gegenüber sicherstellen, beim "richtigen" Server gelandet zu sein
    ... Ein Admin könnte z.B. die Zertifikat aus dem Active Directory automatisch auf die Webseite hochladen
    ... Eine kommerzielle PKI könnte den Service für ihre Kunden betreiben
    ... Ein HTTP-GET zum Download einer DER/CER/P7B/ASC-Datei ist von vielen Clients und Servern möglich.
  • Was spricht dagegen, per DNS-Eintrag einen Hinweis auf diese "Freigabe" zu veröffentlichen ?
    ... SPF nutzt ja auch TXT-Record um die autoritativen Mailserver zu publizieren
    ... Office 365 und CAs nutzen TXT-Records um die Legitimierung einer Domäne zu prüfen
    ... DNS-Anfragen gehören zum Standard.
  • Anker ist die normalisierte Mailadresse
    Als Schlüssel um das passende Zertifikat zu finden nutzt ich die Mailadresse des Empfängers. Um Sonderzeichen etc. zu behandeln, würde ich die einfach als Hashwerte in Hexadezimalschreibweise schreiben.

Auch bei SPF, DomainKey, SenderID und anderen Ansätzen hat es natürlich gedauert, bis so ein Vorschlag dann auch umgesetzt wurde. Es wird zuerst einfach sein, wenn Mail-Relays von Firmen oder große Provider so einen Ansatz fahren. Natürlich müsste die Software dort erst entwickelt werden. Auch die Generierung von Zertifikaten und die Integration der Abfragen in Clients wird sicher nicht morgen umgesetzt. Ich bin ja eh ein Verfechter der pragmatischen Lösung.: Wenn die Gateways sich um die sichere Verschlüsselung von Firmenmails kümmern, dann kann der Anwender nicht falsch machen.

Grundlagen

Auf die Schnelle zur Erinnerung die Randbedingungen:

  • Wer verschlüsseln will
    ...braucht den Public Key der Gegenseite
    ...muss sicher sein dass es der Richtige ist (Meist als Zertifikat bestätigt)Zertifizierungsstellen sind nicht immer vertrauenswürdig und kosten Geld
    ... muss sicher sein, dass er noch gültig ist (durch CRL). Dazu muss der Client aber die CRL prüfen können (http Zugriff)
  • Wer signieren will muss
    ... Selbst einen Private Key haben, dessen Publickey beim Empfänger vorliegt
    ... Der Pubkey muss vom Empfänger verifizierbar sein
  • Faktoren
    ... Das Verteilen und Managen des Schlüsselmaterials ist essentiell
    ... Es muss einfach und plattformübergreifend sein
    ... Kostengünstig und dennoch sicher genug
    ... Primärer „Schlüssel“ ist die SMTP-Adresse

Schlüsseltausch

Es gibt schon verschiedene Ansätze, Schlüsselmaterial auszutauschen, die aber alle mich nicht überzeugen:

  • Zentrale Schlüssel-Server
    Die gibt es zwar aber so richtig durchsetzen konnten Sie sich aus mehreren Gründen nicht
    • Der Betrieb eines Service kostet Geld
      Als Firma für eigene Benutzer ist das noch denkbar – Wer betreibt so was „free“ ?
    • Es gibt viele Server, doch auf welchem finde ich meinen Schlüssel ?
    • Welche Clientsoftware „kann“ heute schon einen Schlüsselserver abfragen ?
      Da gibt es eher Standard um die Titellisten von CDs über CDDB/FreeDB abzufragen
    • Wie finde ich einen Schlüsselserver ?
      Eine „AutoKonfig“ dazu gibt es leider nicht, also kein DNS-Eintrag der zu einem Server verweist.
    • Inkompatibilitäten
      Es gibt noch viele „PGP Schlüsselserver“. Welcher Anwender kennt die Details zu PGP und SMIME ?
    • Inkompatible Ports
      Die meisten Server nutzen entweder LDAP oder den Port 11371. Das verhindert zuverlässig den Zugriff von Clients, wenn sie denn einen Support dazu hätten-
  • Schlüssel im DNS erfordern DNSSEC und Hoheit über die Zone
    • DNSSEC ist noch kaum verbreitet
    • Die Provisionierung der Schlüssels dürfte knifflig werden
      Selbst Administratoren haben oft nur eine WebGUI zum Verwalten aber keinen Automatismus für die Pflege beim Provider
    • Welcher Client kann heute schon DNSSEC abfragen
      Er fragt seinen “normalen“ DNS-Server der dann die Daten hoffentlich verifiziert liefert.
    • DNS als Verteilzentrum für Zertifikate ist auch nicht einfach, da z.B.: große Domänen (GMX.DE) damit viele Änderungen haben .
  • An jeder Mail mit senden
    Jede signierte Mail kann auch den Public Key enthält
    • Ehe man verschlüsselt muss eine signierte Mail gesendet werden
      Erst dann hat die Gegenseite ein Zertifikat. Das funktioniert mit „Erstkontakten“ aber nicht. Nur wer bittet den Gegenüber um eine signierte Mail, wenn er gar nicht weiß, ob die Gegenseite dies kann ?
    • Datenvolumen
      Das Medium Mail wird durch dauernde Anlagen stärker belastet ohne dass es einen Mehrwert gäbe. In der Übersicht kann gar nicht mehr erkannt werden, welche Mails „richtige“ Anlagen enthalten.
    • Lokaler Zertifikatspeicher
      Outlook kann z.B.: empfangene Zertifikate in den Kontakten mit anhängen. Damit ist es aber ein komplett dezentral gepflegter Datenbestand.
    • PKI erforderlich
      Da Mails problemlos gefälscht werden können, kann ein Empfänger einen „SelfSigned-Cert“ nicht vertrauen. Der Versand von Zertifikaten macht nur Sinn, wenn es von einer vertrauenswürdigen PKI ausgestellt wurde.
  • Eigene ROOTCA zum Import anbieten.
    Es gibt wirklich Firmen wie z.B. die Sparkassen Finanz Informatik (http://www.f-i.de/Service/Kontakt/Sichere-E-Mail), die für sichere Mail per SMIME argumentieren aber Zertifikate einer eigenen PKI nutzen und von den Partnern erwarten, dass man dieser PKI vertraut. Dann doch lieber selbst Zertifikate ausstellen.

Überlegungen zu Zertifikate per HTTPS

Wie wäre der folgende Ansatz?

  • Bereitstellung durch WebServer
    Wenn man die Zertifikate einfach als Datei auf den WebSpace hoch lädt, geht das sogar mit „Hosted WebServern“. Mit SSL kann es sogar ein Unterverzeichnis der Homepage sein und komplett losgelöst von der eigenen IT. (Sicherheit) Ohne aktiven Code sind auch die Anforderungen an die Leistung und das Risiko geringer.
    Denkbar wäre aber auch die Bereitstellung durch den Mailserver oder Mailgateway, auf den der MX-Record verweist über ein Custom SMTP-Verb. Allerdings lehnen die meisten Mailserver z.B. Verbindungen von dynamischen IP-Bereichen gerne ab und erlauben daher schon gar keinen Minimalhandshake mit HELO und Custom SMTP-Verben.
  • Die Verteilung von SMIME-Zertifikaten erfolgt einfach als CER-Datei über einen Webserver
    Das ist flexibel und über alle System hinweg transparent nachvollziehbar.
  • Abruf durch Client oder Gateway via HTTPS
    Die freie Verfügbarkeit der CER-Datei von einer per offiziellem SSL-Zertifikat gesicherten Webseite kann per http einfach und problemlos sowohl von Clients als auch von Gateways bezogen werden. Es ist ein bekanntes Protokoll und die Anlagen können automatisch geprüft werden.
  • HTTPS als „Signierung“ und Trust.
    Theoretisch könnten die SMIME-Zertifikate sogar „SelfSigned“ sein und man losgelöst und unabhängig von einer kommerziellen PKI arbeiten ,die ja auch nicht immer sicher sind. Wenn der Client das Zertifikat über eine „gesicherte“ https-Verbindung bekommt, kann er eigentlich die Gültigkeit des Zertifikats annehmen.
  • Client Add-on
    Am Anfang werden wohl kaum Clients diesen Weg unterstützen. Daher wäre es wohl sinnvoll entsprechende AddIns zu bauen, z.B. ein Outlook Add-on für privat.
    Allerdings wäre man wohl schon auf Mithilfe von App angewiesen, wenn es am Endgerät passiert.
    Aber auf dem Gateway wäre es natürlich viel einfacher möglich. Die Frage wäre hier, welche Firmen man einbindet.
  • Adress-Discover per DNS
    Da die Mailadressen eine DNS-Domain enthalten, kann über eine DNS-Abfrage ein passender TXT-Record gefunden werden. Hier sind mehrere Wege zur Ermittlung einer HTTPS-URL denkbar. Wenn man sich hier z.B. an SPF oder DMARC-Einträgen orientiert, dann könnte das wie folgt aussehen
Eintrag in der DNS-Zone

       @ TXT v=1 h=www.firma.de p=/smime/%m.cer e=sha1

v=1 steht für die Version 1 des Stanards
h= Hostname, d.h.
p=Pfad zur URL
%l = Localpart
e= encoding

Das alles ist natürlich erst mal nur eine erste Überlegung.

Bereitstellung

Technisch muss einfach irgendwo ein Webserver stehen, der die Sammlung der "öffentlichen Schlüssel" als CER-Dateien vorhält. Der Server kann ein rein statischer Server sein, der ganz ohne PHP, Perl, CGI o.ä. arbeitet. Er muss nicht mal beim Betreiber der Domäne sein, d.h. der WebServer für die "öffentliche Seite", die meist als www.<firmenname.tld> veröffentlicht ist und auch http://<firmenname.tld> bedient wird gar nicht angefasst, da per DNS (Idealerweise aber nicht notwendigerweise per DNSSEC gesichert). Die Bereitstellung der Zertifikate könnte sogar die ausstellende PKI als "Dienstleister" übernehmen und der Kunde muss nur den DNS-Eintrag dort hin zeigen lassen. Natürlich muss sichergestellt werden, dass die dort hinterlegten Dateien mit dem Schlüsselmaterial "authentisch" ist, d.h. niemand falsche oder fremde Schlüssel untermogelt. Und in der DNS-Zone für die Domain muss natürlich ein entsprechender Hinweis, dass diese Domäne Zertifikate per HTTPS anbietet und wo diese Daten zu finden sind.

Revocation

Zu allererst handelt es sich bei den Dateien des Empfängers um Zertifikate die hoffentlich alle eine CRL haben. Werden diese Zertifikate zurückgezogen und in der CRL veröffentlicht, dann greifen die ganz normalen Prozesse. Der Absender wird das Zertifikat bei der nächsten Verwendung prüfen und von der Verwendung auszuschließen.

Aber auch über die Webseite sollte natürlich das Zertifikat ungültig gekennzeichnet werden. Da gibt es vier Optionen:

  • Datei wird einfach gelöscht
    Bei der nächsten Anfrage bekommt der Sender einen "404 not found". In dem Fall würde ich als Gateway beim Sender die Mail erst einmal zurücklegen und es weiter versuchen. Erst wenn der Fehler sich nicht mehr löst, geht die Mail als Unzustellbar zurück
  • Datei wird durch neues Zertifikat ersetzt
    In dem Fall kann der Sender das neue Zertifikat nutzen und ersetzen
  • Datei mit "REVOKED" als Inhalt
    Wenn ein Mitarbeiter z.B. ausscheidet, könnte über eine neue Zertifikatdatei, in der aber nur dieser Text steht, der Gegenseite die Ungültigkeit signalisiert werden.
  • Kurze Gültigkeit
    Theoretisch könnte das Zertifikat auch einfach wenige Tage oder Wochen gültig sein, z.B. wie die Webserver-Zertifikate bei Let's Encrypt.

Natürlich sollte der Sender damit umgehen können, dass der Verteilserver nicht erreichbar ist. Das kann passieren, wenn der Server selbst nicht online ist aber auch, wenn der Versender gerade offline arbeitet.

Angriffe

Ein Einfachheit der Verteilung von Zertifikaten per HTTP und die Publizierung der Veröffentlichungspunkte per DNS ohne DNSSEC macht es leider nicht 100% unmöglich, dass jemand dieses System stört. So gibt es mehrere Schwächen der Implementierung die im einfachen Fall dem Absender ein Verschlüsseln nicht erlauben oder im schlimmsten Fall die Mail mit einem falschen Key verschlüsselt wird.

  • DNS-Verbergen/Ändern
    Solange die DNS-Abfrage selbst nicht per DNSSEC gesichert ist, kann der Fragende nie sicher sein, ob die überlieferte Startinformation korrekt ist. Ein Angreifer könnte zwei Strategien anwenden:
    • Angreifer blockiert die DNS-Antwort
      Der Absender bekäme dann nicht nicht Information, wo der Empfänger das Zertifikat hinterlegt hat und könnte nicht verschlüsseln. Hier kann der Absender dann überlegen, ob er unverschlüsselt sendet oder noch mal nachfragt.
    • Angreifer verändert die DNS-Antwort
      Schlimmer ist eine Fälschung der DNS-Antwort, damit der Absender ein Zertifikat nutzt, zu dem der der Angreifer einen privaten Schlüssel hat. Der Absender sendet verschlüsselt aber nur der Angreifer kann die Mail lesen. Wenn der Angreifer dann noch an das Postfach käme, könnte er dort sogar die Mail durch eine ersetzen, die der eigentliche Empfänger lesen könnte. Es würde nur auffallen, wenn die Mail nicht signiert ist oder der Angreifer auch den Rückweg und eine Signierung des Absenders vortäuschen kann. Auch dies ist möglich, wenngleich doch sehr viel aufwändiger
  • Angriffe auf den Webserver bzw. Zertifikatsspeicher
    Ein zweiter Angriffspunkt ist die Bereitstellung des Zertifikats. Das ist eigentlich nur ein Webserver aber auch hier gibt es zwei Ansätze für eine Beeinflussung
    • DoS-Überlastung
      Damit könnte verhindert werden, dass eine Anfrage eines legitimen Clients bei dem Server ankommt oder von ihm beantwortet werden kann. Der Absender bekäme das Zertifikat nicht und würde ggfls. unverschlüsselt senden. Hier kann man aber durch die Information aus dem DNS zumindest eine Warnung anzeigen und eine Rückfrage starten.
    • Ausgetauschte Zertifikate
      Auch hier wäre es möglich, dass ein Angreifer den Webserver kapert um die CER-Dateien o.ä. durch eigene Zertifikate zu tauschen. So etwas könnte man z.B. zeitnah erkennen, indem der Besitzer des Zertifikats immer mal wieder selbst sein Zertifikat abruft und vergleicht.
    • Dictionary Angriff
      Ein Angreifer könnte natürlich über viele Anfragen versuchen gültige Mailadressen zu ermitteln. Ein SMTP-Server blockt das nach kurzer Zeit, was aber nicht gegen Bot-Netze hilft. Ein Webserver kann auch zu viele Anfragen vom gleichen Client blockieren. Alternativ könnte eine zeitintensive Hashfunktion auf beim Absender das Risiko minimieren.
  • Absichtlich falscher Inhalt
    Der Prozess zum Anfordern der Zertifikate startet natürlich einen HTTPS-Download einer URL und erwartet dort eine CER-Datei. Es ist durchaus denkbar, dass jemand absichtlich hier eine XXL-Datei mit Schrott ablegt um den Downloader zu stören. Hier muss der Prozess natürlich
  • Angriff auf die Zertifikatskette
    Wenn jemand mir "falsche Zertifikate" unterschieben will, dann muss er meine Anfrage auf einen Webserver umleiten, der dennoch ein gültiges Zertifikat für den Namen hat. Eigentlich sollte das unmöglich sein. Leider zeigen aber Fehler bei den CA-Betreibern immer mal wieder, dass jemand ein Zertifikat für einen fremden Namen bekommt. Meist fällt die Google durch das Zertifikat-Pinning im Chrome-Browser auf. Aber wenn selbst eine RootCA wie Symantec ein Intermediate-Cert an BlueCoat ausstellt (Anfang 2016), dann dürften Geheimdienste und Co sicher auch schon lange eine "Intermediate-CA" haben.

Diese Angriffsmuster sind aber nicht neu, sobald ein KeyServer eingesetzt wird oder irgendwelche "Autodiscover"-Ansätze vorgesehen sind. Sie können sogar auftreten, wenn ein Angreifer eine Mail an den Absender mit gefälschter "From"-Adresse sendet und dabei ein Zertifikat anhängt. Der Empfänger eines Zertifikats sollte immer sicherstellen, dass das Zertifikat vertrauenswürdig ist. Leider ist ein "trusted Issuer" da auf Dauer wohl auch kein 100%-Schutz.

Hosted Zertifikat by IssuingCA

Warum sollten Sie als Anwender oder Firma die Zertifikate bereitstellen? Speziell wenn Sie öffentliche Zertifikate bei einer Zertifizierungsstelle für eine Mailadresse gegen Geld kaufen, dann bekommen Sie als Käufer heute einen signierten Public-Key zur Weitergabe und die CA stellt bei Bedarf über die CRL eine RückrufMöglichkeit bereit. Mehr aber noch nicht. Es wäre für eine CA sehr leicht, parallel auch noch die Zertifikate bereit zustellen.

Nur weiß natürlich ein potentieller Absender nicht, ob und bei welcher CA sich der Empfänger einen Public-Key ausgestellt hat. Genau dazu dienen dann wieder die DNS-Einträge des Empfängers, die natürlich auf jede gültige PKI verweisen können.

Aus Datenschutzüberlegungen ist hier aber kritisch, dass die CA über die HTTP-Zugriffe natürlich ermitteln könnte, welche IP-Adresse ein Zertifikat für einen Zieladresse ermittelt. Auch diese Information ist in Verbindung mit einer Zuordnung einer IP-Adresse zu einer Person für Ermittlungsbehörden interessant. Könnte man so doch zumindest vermuten, dass eine Mail an diese Adresse gesendet wurde, auch wenn auf dem Absender-Computer dazu keine Spuren mehr vorlägen.

Umsetzung

Es wird sicher einige Zeit dauern, bis Provider und Produkte solch einen Zertifikatsservice nutzen. Ob die "großen" Provider wie Oulook.com, Office365, Google-Mail, Yahoo und andere die auch serverseitig implementieren, steht eh auf einem anderen Blatt. Dennoch gibt es einige Ansätze so einen Zertifikatsservice zu nutzen.

  • Auf dem Client
    Für eine echte Ende-zu-Ende-Verschlüsselung muss der Absender natürlich selbst lokal verschlüsseln und benötigt dazu den PublicKey des Empfängers. Für die Anfangszeit wird man wohl ein Add-on für die bekannten Mailclients entwickeln müssen und bis sich ein Standard etabliert hat und von den Herstellen in die SmartPhone-Versionen oder Web-Clients integriert wurde, wird einiges an Zeit vergehen.
  • Auf dem MailServer
    Für kleine Firmen wäre die Funktion als Bestandteil des Mailservers interessant, damit man keine zusätzlichen Services nutzen muss. Aber auch hier ist an dann sehr produktabhängig. Wenn ich alleine sehe, welche Exchange Versionen parallel bei Kunden im Einsatz sind, wird es viele Jahre dauern, wenn kein Dritthersteller ein Add-on baut.
  • Auf dem Gateway
    Ich sehe aber auch, dass immer mehr Firmen zwischen Internet und Mailserver ein Gateway wie NoSpamProxy setzen, welche auch SMIME und PGP unterstützt. Hier erwarte ich, dass diese Produkte sehr schnell einen halbwegs gefestigten Standard umsetzen.

Dennoch wird es sicher noch einige Zeit dauern, denn neben einer Festlegung eines Standards müssen nicht nur die Mailsysteme ertüchtigt werden, sondern eben auch möglichst viele Firmen und Anwender ihr Schlüsselmaterial veröffentlichen. Dennoch ist es die Überlegungen wert.

RFC

Sollte noch niemand sonst auf die Idee gekommen sein und gibt es nicht vielleicht doch schon eine RFC dazu?.

Im Sep 2016 habe ich erstmals von einem Entwurf auf Basis von OpenPGP etwas gefunden.

Weitere Links