DANE im Browser und DNSSEC vom Hoster wäre schöner...

[Vanger]

Let's encrypt ist auf jeden Fall ein Schritt in die richtige Richtung, das wirkliche Problem der CA-Infrastruktur aber löst es nicht - an Symptomen die die Verbreitung von HTTPS behindern wird so gearbeitet, dass die komplette CA-Infrastruktur aber in sich kaputt und unsicher ist, daran ändert sich nichts.

Da hilft nur DANE-Support in den verbreiteten Browsern und DNSSEC-Unterstützung bei Hostern. Der absolute Großteil von letzteren unterstützt entweder gar kein DNSSEC oder nur über Supportanfragen. Die Lösung ist da, alle Beteiligten weigern sich nur mehr oder minder daran sie auch umzusetzen...

[RipClaw]

Vanger schrieb:
--------------------------------------------------------------------------------

> Da hilft nur DANE-Support in den verbreiteten Browsern und
> DNSSEC-Unterstützung bei Hostern. Der absolute Großteil von letzteren
> unterstützt entweder gar kein DNSSEC oder nur über Supportanfragen. Die
> Lösung ist da, alle Beteiligten weigern sich nur mehr oder minder daran sie
> auch umzusetzen...

Das Problem bei DNSSec ist das mindestens 5 Parteien DNS Sec unterstützen müssen bis so ein Eintrag überhaupt wirksam ist.

Er mal muss die Root Zone signiert werden. Das ist bereits gegeben.
Dann muss die TLD Zone signiert sein, was nicht bei allen TLDs gegeben ist.

Sollte man eine Domain haben deren TLD Zone signiert ist muss man einen Registrar haben der DNSSec unterstützt.

Dann muss der der Nameserver auf dem die Domain liegt auch DNSSec unterstützen und zum Schluss muss auch noch der Client DNSSec unterstützten und den Eintrag verifizieren.

Dazu kommt noch das viele der verwendeten Schlüssel vergleichsweise kurz sind und DNSSec hat noch ein paar andere Probleme z.B. die Anfälligkeit für DNS Amplifikation Attacks. Damit lassen sich prima DDOS Attacken durchführen.

Zudem musst du leider den Stationen die in der Hierarchie vor dir kommen vertrauen.

Die ICANN könnte eine TLD Zone fälschen und darauf aufbauend alle weiteren Einträge selber signieren so das am Schluss ein gültiger Eintrag rauskommt obwohl die Information falsch ist.

Die Verwaltung der TLD könnte den Eintrag der Domain fälschen und wieder würde es niemanden auffallen und der Provider selber könnte die einzelnen Einträge in der Domain fälschen und auch hier wäre alles scheinbar ok.

Im Grunde wird das Vertrauen von den CAs auf die DNS Hierarchie verlagert aber die ist so gesehen auch nicht viel besser.



1 mal bearbeitet, zuletzt am 06.06.15 00:04 durch RipClaw.

[Vanger]

> Im Grunde wird das Vertrauen von den CAs auf die DNS Hierarchie verlagert
> aber die ist so gesehen auch nicht viel besser.
Das ist richtig, irgend eine Stelle die als Vertrauensbasis dient benötigt man aber immer. Zumindest bewerte ich die Schlüssel der Rootzone als deutlich sicherer als eine x-beliebige CA. Nachdem das Handling der Rootzone-Schlüssel öffentlich dokumentiert ist, wissen wir ganz genau, dass die Schlüssel gut geschützt sind. Kriminelle dürften auf diesem Weg überhaupt keine Chance haben das System zu brechen, selbst seitens der Geheimdienste ist es zweifelhaft, ob die da rankommen - und wenn doch dürfte die NSA der einzige sein.

Das ist ein vielfaches mehr an Sicherheit als die aktuelle Situation mit der CA-Infrastruktur. Man muss sich nur vor Augen führen, dass wir per Default öffentlichen Stellen von unzähligen äußerst zweifelhaften Staaten vertrauen - im Vergleich ist die USA ein perfekter Rechtsstaat. Die NSA hat ihre eigene CA. Das System ist einfach kaputt, da muss etwas neues her.

[RipClaw]

Vanger schrieb:
--------------------------------------------------------------------------------
> > Im Grunde wird das Vertrauen von den CAs auf die DNS Hierarchie
> verlagert
> > aber die ist so gesehen auch nicht viel besser.
> Das ist richtig, irgend eine Stelle die als Vertrauensbasis dient benötigt
> man aber immer. Zumindest bewerte ich die Schlüssel der Rootzone als
> deutlich sicherer als eine x-beliebige CA. Nachdem das Handling der
> Rootzone-Schlüssel öffentlich dokumentiert ist, wissen wir ganz genau, dass
> die Schlüssel gut geschützt sind.

Nur ist es nicht alleine die Signatur der Root Zone der man trauen muss.
Man muss auch noch der Signatur von der TLD Verwaltung trauen, der Signatur von deinem Registrar und der von dem Nameserverbetreiber.

An jedem dieser Punkte könnte eine Behörde ansetzen und via Beschluss fordern das die Einträge manipuliert werden damit sie einen Man in the Middle machen können.

> Das ist ein vielfaches mehr an Sicherheit als die aktuelle Situation mit
> der CA-Infrastruktur. Man muss sich nur vor Augen führen, dass wir per
> Default öffentlichen Stellen von unzähligen äußerst zweifelhaften Staaten
> vertrauen - im Vergleich ist die USA ein perfekter Rechtsstaat. Die NSA hat
> ihre eigene CA. Das System ist einfach kaputt, da muss etwas neues her.

Nur hat sich bisher nichts besseres gefunden. Es ist nicht optimal aber mit zusätzlichen Maßnahmen kann man es verbessern.

DANE ist so eine Zusatzmaßnahme aber es kann das CA System nicht ersetzen.

Was auch interessant ist, ist das Certificate Transparency Projekt.

Dabei werden von den CAs in einer Art Öffentliches Log die Zertifikate eingetragen die sie ausstellen und das ganze ist kryptographisch signiert. Eine Nachträgliche Manipulation ist daher kaum möglich.

Man kann daher hergehen und regelmäßig prüfen ob für die eigene Seite Zertifikate ausgestellt wurden die ich nicht kenne und der Browser kann prüfen ob ein Zertifikat dem er begegnet dort eingetragen ist.

Dieses Projekt wird von immer mehr CAs unterstützt.

[ikhaya]

Man spricht von 500 CAs die im Browser sind, da wären Rootzone,TLD,Hoster und Registrar doch eine erhebliche Verbesserung.

Auch kann man den TrustAnchor für das Zertifikat deiner Seite auch einen Level tiefer setzen und es an der Rootzone festmachen.

Was ebenfalls wichtig ist , ist dass man zwar mit viel Aufwand und geklauten Schlüsseln vielleicht die Records austauschen kann, aber es gibt keine Möglichkeit dies nur für einzelne Leute zu tun, das Risiko endeckt zu werden steigt enorm.

[Vanger]

> Man muss auch noch der Signatur von der TLD Verwaltung trauen, der Signatur
> von deinem Registrar und der von dem Nameserverbetreiber.
Das notwendige Vertrauen gegenüber der TLD ist natürlich richtig, das kann man aber selbst beeinflussen - eben durch die Wahl der TLD. Bei der CA-Infrastruktur kann ich überhaupt nichts wählen, jede x-beliebige der mehreren hundert CAs kann gültige Zertifikate für meine Dienste ausstellen. All denen müsste ich vertrauen - und ich weiß, dass es außerordentlich dumm wäre es zu tun. Da sind CAs dabei die von Unrechtsstaaten betrieben werden, einige Geheimdienste haben ihre eigenen CAs und die Vergangenheit hat gezeigt, dass auch Kriminelle problemlos Kontrolle über eine CA erlangen können...

Wieso ich dem Registrar vertrauen muss ist mir nicht klar. Er betreibt keine Nameserver in der Vertrauenskette, seine einzige Aufgabe ist meine Daten korrekt weiterzugeben - und dazu braucht es kein Vertrauen, das DNS ist öffentlich, ich kann ganz einfach kontrollieren ob er sie manipuliert hat oder nicht.

Bleibt noch der Nameserver-Betreiber. Den Master-Server betreibe ich selbst - und das sollte jeder tun. Mir vertraue ich. Wenn ein Angreifer meinen Nameserver manipulieren kann, kann er vermutlich auch direkt meine Dienste manipulieren, also: So what... Die Slave-Server sind unproblematisch, denn die kann ich vollautomatisiert prüfen - denn zur Erinnerung, das DNS ist öffentlich.

>
> An jedem dieser Punkte könnte eine Behörde ansetzen und via Beschluss
> fordern das die Einträge manipuliert werden damit sie einen Man in the
> Middle machen können.
>
> > Das ist ein vielfaches mehr an Sicherheit als die aktuelle Situation mit
> > der CA-Infrastruktur. Man muss sich nur vor Augen führen, dass wir per
> > Default öffentlichen Stellen von unzähligen äußerst zweifelhaften
> Staaten
> > vertrauen - im Vergleich ist die USA ein perfekter Rechtsstaat. Die NSA
> hat
> > ihre eigene CA. Das System ist einfach kaputt, da muss etwas neues her.
>
> Nur hat sich bisher nichts besseres gefunden.
Na, eben doch: DANE. Wie wir alle wissen führt ein besseres System aber nicht zwangsläufig dazu, dass es sich durchsetzt. Da spielt auch viel Politik mit rein - und die hat eher das Interesse, dass wir bei der unsicheren CA-Infrastruktur bleiben.

> DANE ist so eine Zusatzmaßnahme aber es kann das CA System nicht ersetzen.
Das kommt darauf an welchen Teil der CA-Infrastruktur du ersetzen möchtest. Wenn es darum geht was Let's Encrypt tut: Doch, das kann DANE vollkommen ersetzen. Wenn es um EV-Zertifikate geht - deren Zahl sich im Promillebereich aller Zertifikate bewegt - hast du Recht, da ist DANE eher eine Zusatzmaßnahme. Die CA-Infrastruktur soll komplett zusammenbrechen, übrig bleiben die CAs, die auch EV-Zertifikate ausstellen dürfen - das sind nämlich nur ein paar.

[Iruwen]

Bei den CAs hat doch eh schon das Sterben eingesetzt, mindestens VeriSign und Thawte unterstehen direkt Symantec (und der NSA).