DNS-Record als zweiten Faktor?

[adorfer]

In Zeiten in denen DNS auch irgendwie per API gesteuert werden, wäre zumindest (optional) kein Problem, über den CAA-record zu sagen "nur 2factor Zertifikatsausstellung" und dann den certbot zusätzlich zur HTTP-Response auch noch eine Response per DNS veröffentlichen zu lassen, die dann validiert wird.
(Ob man jetzt zusätzlich noch DNSSEC drüberbaut: wäre dann das i-Tüpfelchen)

[Poe's Law]

Ich benutz nur DNS-01. Weil das ermöglicht es mir Zertifikate für Domains resp. sub-Domains zu holen, die von aussen nicht erreichbar sind.

[robinx999]

Kleinere Webhoster stellen aber leider oft keine API für das DNS zur Verfügung, dass kann die Sache dann wider erschweren.

[Chrigiboy]

Wollte ich auch erwähnen. Domains ohne DNSSec können noch viel einfacher manipuliert werden. Die sollten damit aufhören Domains zu signieren ohne DNSSec. ;-)

[MadCat_me]

Wildcard-Zertifikate lassen sich sogar nur über die DNS Challenge erzeugen. Ohne API ist's halt eher lästig. Acme.sh unterstützen an die 100 verschiedene DNS-Anbieter, aber wie schon gesagt wurde, gerade kleinere Dienste bieten keine API.

[Poe's Law]

acme.sh <3

[RipClaw]

MadCat_me schrieb:
--------------------------------------------------------------------------------
> Wildcard-Zertifikate lassen sich sogar nur über die DNS Challenge erzeugen.
> Ohne API ist's halt eher lästig. Acme.sh unterstützen an die 100
> verschiedene DNS-Anbieter, aber wie schon gesagt wurde, gerade kleinere
> Dienste bieten keine API.

Es gibt einen Weg außen rum. Nennt sich acme-dns und ist ein in Go geschriebener DNS Server der die Authentifizierung übernimmt. Man muss nur einen CNAME Eintrag in der Domain vornehmen der die Authentifizierungsanfrage an acme-dns weiterleitet.

In acme.sh gibt es auch ein entsprechendes Modul das dann mit acme-dns kommuniziert.

[ritzmann]

Den Webserver auf die DNS-Zone zugreifen lassen, ist halt auch ein Security Problem. Sowas sollte man eher nicht tun. Man muss nicht immer alles miteinander verbinden, nur weil mans kann.

Twitter: @RitzmannMarkus

[RipClaw]

ritzmann schrieb:
--------------------------------------------------------------------------------
> Den Webserver auf die DNS-Zone zugreifen lassen, ist halt auch ein Security
> Problem. Sowas sollte man eher nicht tun. Man muss nicht immer alles
> miteinander verbinden, nur weil mans kann.

Man muss nicht den Webserver auf den DNS Server zugreifen lassen. Tatsächlich könnte man das Zertifikate auch von einem dritten Server aus anfordern. Dieser Server kommuniziert mit den Let's Encrypt Server und dem DNS Server bzw. der API des Anbieters und spielt dann das Zertifikat auf den Webserver.

Ich nutze z.B. ein einem Fall getssl als AMCE Client der von extern die Validierung und das einbinden der Zertifikat macht weil das von dem Zielsystem aus nicht möglich ist.



1 mal bearbeitet, zuletzt am 20.02.20 18:36 durch RipClaw.

[MadCat_me]

RipClaw schrieb:
--------------------------------------------------------------------------------
> MadCat_me schrieb:
> ---------------------------------------------------------------------------
> -----
> > Wildcard-Zertifikate lassen sich sogar nur über die DNS Challenge
> erzeugen.
> > Ohne API ist's halt eher lästig. Acme.sh unterstützen an die 100
> > verschiedene DNS-Anbieter, aber wie schon gesagt wurde, gerade kleinere
> > Dienste bieten keine API.
>
> Es gibt einen Weg außen rum. Nennt sich acme-dns und ist ein in Go
> geschriebener DNS Server der die Authentifizierung übernimmt. Man muss nur
> einen CNAME Eintrag in der Domain vornehmen der die
> Authentifizierungsanfrage an acme-dns weiterleitet.
>
> In acme.sh gibt es auch ein entsprechendes Modul das dann mit acme-dns
> kommuniziert.

Cool, Danke. Das kannte ich nicht.

[adorfer]

Daher sage ich ja auch DNS als ZWEITEN Faktor. Also http UND dns.
Und nur weil einige eben keine ordentliche Api haben bei ihrem Masendomainhoster heisst das ja nicht, dass man nicht
1) Leute die das können sichere Zertifikate geben könnte (unter ankündigung eines solchen per CCA-Record)
2) die Massendomainhoster endlich dazu zu motivieren bringen, eine Api für DNS auch den 1€99-Kunden bereitzustellen.
3) und ja DNSSec ist sinnvoll und selbst bei den Großen irgendwie erschreckend wenig verbreitet.

[adorfer]

Dass Acme auch dns-validierung beherrscht ist doch unstreitig.
Nur bei der Angreifbarkeit von DNS ist jedoch noch gefährlicher als HTTP-Validierung.

Und darum geht's doch in der Golem-Meldung: Zertifikatsausstellung sicherer machen, nicht unsicherer.
Meiner Meinung nach sollte die Validierung per "DNS allein" komplett gekickt werden, zumindest wenn nicht DNSsec aktiv ist für die Domain.

[chefin]

Mir scheint keiner weis was ein BGP überhaupt ist. Ich sage einem Router einfach das die IP 5.5.5.5 nicht am Port 1 sondern Port 2 zu finden ist. Dort lege ich einen Server mit 5.5.5.5 an. Nun gibt es diesen 2x, IP-Collission, aber merkt keiner, weil der Router den ersten auf Port 1 garnicht ansteuert aktuell.

DNSSec könnte es merken. Aber man kann nicht permanent vor jedem Zugriff erstmal validieren. Ich stelle die Anfrage, der Zertifikat-Server prüft ob die Domain existiert, hat nun die Daten in seinem DNS-Resolver cached. Erst JETZT manipuliere ich das BGP wovon keiner etwas bemerkt.

Beim nächsten Zugriff wird das Zertifikat nicht nochmal geprüft, weil es vor 2 sekunden ja noch gepasst hat. Hacker sind ja keine Beamten die zwischen jedem Arbeitsschritt 15 Minuten Kaffeepause machen. Wir reden von Scripten die ungefähr so schnell agieren wie die Pingzeiten sind. Vermutlich dauert der ganze Vorgang 1-2 sekunden. Selbst wenn ich meinen Resolver auf 30sec cache stelle, reicht das völlig. Allerdings steigt dann der Overhead derart an, das ich mir die Verbindungsbandbreite zerschiesse.

[wupme]

adorfer schrieb:
--------------------------------------------------------------------------------
> Dass Acme auch dns-validierung beherrscht ist doch unstreitig.
> Nur bei der Angreifbarkeit von DNS ist jedoch noch gefährlicher als
> HTTP-Validierung.

Dir ist schon klar dass auch bei der HTTP Validierung der DNS im Spiel ist?
Irgendwer muss ja den Namen auflösen, und schon hast du hier zwei Angriffspunkte.
Der Webserver UND der DNS.
Somit ist das automatisch unsicherer als gar nur über den DNS zu gehen

[tsp]

chefin schrieb:
--------------------------------------------------------------------------------
> Mir scheint keiner weis was ein BGP überhaupt ist. Ich sage einem Router
> einfach das die IP 5.5.5.5 nicht am Port 1 sondern Port 2 zu finden ist.
> Dort lege ich einen Server mit 5.5.5.5 an. Nun gibt es diesen 2x,
> IP-Collission, aber merkt keiner, weil der Router den ersten auf Port 1
> garnicht ansteuert aktuell.

Ist an sich keine Kollision sondern absolut vorgesehenes Verhalten - der Router wählt in so einem Fall einfach immer die Route mit kürzerer topologischer Distanz zum Ziel aus (damit werden ja im Endeffekt auch redundante Pfade zwischen Netzen erst möglich - wobei Router immer die "günstigste" Route nutzen; wenn die Ausfällt kommt die nächstteure, etc. - dieses Verhalten ist ja ein Kernbestandteil der Ausfallssicherheit des Netzes)

>
> DNSSec könnte es merken. Aber man kann nicht permanent vor jedem Zugriff
> erstmal validieren. Ich stelle die Anfrage, der Zertifikat-Server prüft ob
> die Domain existiert, hat nun die Daten in seinem DNS-Resolver cached. Erst
> JETZT manipuliere ich das BGP wovon keiner etwas bemerkt.
>
> Beim nächsten Zugriff wird das Zertifikat nicht nochmal geprüft, weil es
> vor 2 sekunden ja noch gepasst hat. Hacker sind ja keine Beamten die
> zwischen jedem Arbeitsschritt 15 Minuten Kaffeepause machen. Wir reden von
> Scripten die ungefähr so schnell agieren wie die Pingzeiten sind.
> Vermutlich dauert der ganze Vorgang 1-2 sekunden. Selbst wenn ich meinen
> Resolver auf 30sec cache stelle, reicht das völlig. Allerdings steigt dann
> der Overhead derart an, das ich mir die Verbindungsbandbreite zerschiesse.

Es muss sogar jedes Mal wenn man Daten transferiert validiert werden. Wenn ich einen DNS Eintrag anfrage dann wird der vom DNS Server geladen. Dann der zugehörige DNSSEC Eintrag. Klar - dazwischen kann manipuliert werden aber da der DNSSEC Eintrag eine Signatur ist, ist der Transportweg schon wieder egal. Entweder der passt zum entsprechenden ersten DNS record oder nicht, gecached wird nur wenn die Signatur auch korrekt war (bzw. wird im Fall, dass die Signatur nicht korrekt war gecached, dass kein Eintrag existier). Wenn er nicht passt wurde entweder der Eintrag oder der Transportweg manipuliert, eine Umlenkung des Traffic hilft da absolut nicht; Sofern die übergeordneten Zonen bis hin zur Root Zone sicher (im Sinne von korrekt signiert und die Schlüssel nicht bekannt) sind ist dann defacto keine Manipulation mehr am DNS Record möglich, egal zu welchem Zeitpunkt man den Traffic umlenkt.

An sich würde DNSSEC schon funktionieren, der Verbreitungsgrad ist allerdings leider nicht gerade hoch (auch wenns absolut unkompliziert einzusetzen ist) ...

Bei SSL/TLS ist's ja dann genauso - man macht sich ja prinzipiell eine verschlüsselte Session mit zufälligem Key aus und zertifiziert dann mit Hilfe von Signaturen, dass diese Verbindung korrekt ist. Dabei kommen dann im Normalfall Verfahren zum Einsatz bei denen der zufällige Schlüssel nur den beiden Endstellen bekannt ist - wenn dann eine Identität für diese Session bestätigt ist und ich dann den Transfer umlenke bringt das an sich nichts, weil ich den Session Key nicht kenne und damit wieder von Vorne anfangen müsste (neue Keys aushandeln, neue Identität bestätigen) bzw. einmal die bestehende TLS Verbindung abreißt ... die Zertifikatsprüfung selbst muss dabei definitiv bei jedem neuen Aufbau einer SSL Verbindung erfolgen, das was nicht unbedingt passieren muss ist eine neue Abfrage z.B. via OCSP ob das Zertifikat zurückgezogen wurde / auf die revocation lists / etc. (das kann dann ja je nach Policy erfolgen). Aber eine Signatur das die neue Verbindung ebenfalls wieder zur selben Identität gehört muss definitiv bei jedem Verbindungsaufbau passieren.

[phade]

chefin schrieb:
--------------------------------------------------------------------------------
> Mir scheint keiner weis was ein BGP überhaupt ist. Ich sage einem Router
> einfach das die IP 5.5.5.5 nicht am Port 1 sondern Port 2 zu finden ist.
> Dort lege ich einen Server mit 5.5.5.5 an. Nun gibt es diesen 2x,
> IP-Collission, aber merkt keiner, weil der Router den ersten auf Port 1
> garnicht ansteuert aktuell.

Bei diesen Szenarien frag ich mich, ob die Hacker was ganz Tolles können, was ich einfach nur nicht schnalle oder ob es AS-admins gibt, die einfach unglaublich dämlich sind.

Also ich kenne keinen Routing-Spezi, der es erlauben würde, dass man seinem Router von irgendwo her eine BGP-Route einhilft. Die meisten nutzen auf den Upstreams entsprechende Filter (entweder weltweite Verzeichnisse oder haben manuelle Listen von ihren Partnern. Die Routen des internen/eigenen AS sind oft sogar händisch verdrahtet).

Für ARP-Tables gilt das gleiche.



1 mal bearbeitet, zuletzt am 21.02.20 13:21 durch phade.

[tsp]

phade schrieb:
--------------------------------------------------------------------------------
> chefin schrieb:
> ---------------------------------------------------------------------------
> -----
> > Mir scheint keiner weis was ein BGP überhaupt ist. Ich sage einem Router
> > einfach das die IP 5.5.5.5 nicht am Port 1 sondern Port 2 zu finden ist.
> > Dort lege ich einen Server mit 5.5.5.5 an. Nun gibt es diesen 2x,
> > IP-Collission, aber merkt keiner, weil der Router den ersten auf Port 1
> > garnicht ansteuert aktuell.
>
> Bei diesen Szenarien frag ich mich, ob die Hacker was ganz Tolles können,
> was ich einfach nur nicht schnalle oder ob es AS-admins gibt, die einfach
> unglaublich dämlich sind.
>
> Also ich kenne keinen Routing-Spezi, der es erlauben würde, dass man seinem
> Router von irgendwo her eine BGP-Route einhilft. Die meisten nutzen auf den
> Upstreams entsprechende Filter (entweder weltweite Verzeichnisse oder haben
> manuelle Listen von ihren Partnern. Die Routen des internen/eigenen AS sind
> oft sogar händisch verdrahtet).
>
> Für ARP-Tables gilt das gleiche.

Und selbst wenn es so wäre - es dürfte ja einfach nix ausmachen (abgesehen von DoS) ...

[phade]

tsp schrieb:
--------------------------------------------------------------------------------
> phade schrieb:
> ---------------------------------------------------------------------------
> > Also ich kenne keinen Routing-Spezi, der es erlauben würde, dass man
> seinem
> > Router von irgendwo her eine BGP-Route einhilft. Die meisten nutzen auf
> den
> > Upstreams entsprechende Filter (entweder weltweite Verzeichnisse oder
> haben
> > manuelle Listen von ihren Partnern. Die Routen des internen/eigenen AS
> sind
> > oft sogar händisch verdrahtet).
> >
> > Für ARP-Tables gilt das gleiche.
>
> Und selbst wenn es so wäre - es dürfte ja einfach nix ausmachen (abgesehen
> von DoS) ...

Exakt. Ergo empfinde ich alle Sicherheitsmethoden ala DNSsec, Zweifaktor-Authorisierung zur Verifizierung für SSL-Zertifikate und Man-in-the-middle-Attacken eher als kompletten Blödsinn.

Klar kann man z.B. nicht garantieren, dass sich ein Kunde irgendwo in der Welt einloggt und dann z.B. sich auf seiner Webseite, die bei uns gehostet ist einloggt und dann der dortige Internetprovider gehackt ist und absichtlich irgendetwas modifiziert, damit er den Traffic re-routen und mitlesen kann, aber: wie wahrscheinlich ist das denn ?

Hacks fanden hier in den letzten 30 Jahre ausschliesslich anders statt. Zuerst einmal gehen regelmässig beim Kunden oder dessen Agenturen Passworte verloren, durch Trojaner auf alten Systemen abgegriffen oder Nutzung von Laptops in öffentlichen WLANs. Das schätze ich auf 80%. Dann sind es schlecht gepflegte CMS-Systeme, zumeist mit Cross-Site-Scripting oder MySQL-Injection oder plumpen Logins, bei denen man sich plötzlich ohne Passworte einloggen kann, vielleicht so 15% zusammen. Der Rest sind eher schlechte programmierte Scripte der Kunden, zumeist Upload-Scripte ohne sinnvolle Parameterprüfungen. Oder noch dümmere Sachen ...

BGP-Attacken ? DNS-Veränderungen ? Man-in-middle ? Nie gesehen. Sowas wäre für den Hacker auch viel zu aufwändig und geziehlt und pro "Ziel" zu speziell.

[tsp]

phade schrieb:
--------------------------------------------------------------------------------
> tsp schrieb:
> ---------------------------------------------------------------------------
> -----
> > phade schrieb:
> >
> ---------------------------------------------------------------------------
>
> > > Also ich kenne keinen Routing-Spezi, der es erlauben würde, dass man
> > seinem
> > > Router von irgendwo her eine BGP-Route einhilft. Die meisten nutzen
> auf
> > den
> > > Upstreams entsprechende Filter (entweder weltweite Verzeichnisse oder
> > haben
> > > manuelle Listen von ihren Partnern. Die Routen des internen/eigenen AS
> > sind
> > > oft sogar händisch verdrahtet).
> > >
> > > Für ARP-Tables gilt das gleiche.
> >
> > Und selbst wenn es so wäre - es dürfte ja einfach nix ausmachen
> (abgesehen
> > von DoS) ...
>
> Exakt. Ergo empfinde ich alle Sicherheitsmethoden ala DNSsec,
> Zweifaktor-Authorisierung zur Verifizierung für SSL-Zertifikate und
> Man-in-the-middle-Attacken eher als kompletten Blödsinn.

Naja genau DNSSEC & SSL ist ja prinzipiell da um das grundlegend unsichere Netz zu kompensieren - und das tun sie auch entsprechend gut. Ja, die Verifizierung von SSL Zertifikaten hat mit der CA Infrastruktur einige Schwächen (könnte man im Endeffekt aber nur über manuelle Verifikation lösen, so lagert man halt das "Vertrauen" an eine große Anzahl an Zertifizierungsstellen aus)

Mit 2FA hat's wieder was komplett anderes auf sich - da geht's ja dann um Risikominierung (2FA über SMS ist natürlich Schwachsinn, 2FA über z.B. Ident hat ja wie man historisch gesehen hat ebenfalls nicht wirklich sinnvoll funktioniert weil man dem Netz nicht trauen kann).

Im Prinzip brauchts am Application Layer saubere Verschlüsselung und saubere Authentifizierung. Dann ist (bis auf Metadatensammlung) eigentlich egal was am Netz dahinter passiert.

>
> Klar kann man z.B. nicht garantieren, dass sich ein Kunde irgendwo in der
> Welt einloggt und dann z.B. sich auf seiner Webseite, die bei uns gehostet
> ist einloggt und dann der dortige Internetprovider gehackt ist und
> absichtlich irgendetwas modifiziert, damit er den Traffic re-routen und
> mitlesen kann, aber: wie wahrscheinlich ist das denn ?

Nicht ganz so unwahrscheinlich. Es fängt bei seinem eigenen Privaten Netz an und geht bei irgendeinem der vielen Netze durch die der Traffic potentiell wandert weiter. Es ist natürlich nicht ganz so simpel für einen 0815 Nutzer IP Traffic für ein spezifische Ziel zu sich umzulenken wie's z.B. bei Anrufen oder SMS der Fall ist - aber man muss IMHO immer davon ausgehen, dass das Netz selbst komplett unsicher ist.

>
> Hacks fanden hier in den letzten 30 Jahre ausschliesslich anders statt.

Nein. Definitiv nein. Es gab ja auch groß angelegte BGP Poisioning attacken, es gibt in größeren Netzwerken regelmäßig Leute, die MITM Angriffe versuchen oder sich einfach mal nur "herumspielen", etc.

> Zuerst einmal gehen regelmässig beim Kunden oder dessen Agenturen Passworte
> verloren, durch Trojaner auf alten Systemen abgegriffen oder Nutzung von
> Laptops in öffentlichen WLANs. Das schätze ich auf 80%. Dann sind es

Ich persönlich sehe ein öffentliches WLAN bereits als ein Segment des Internets. Ist genauso vertrauenswürdig wie alle Netze dahinter auch. Immerhin ist ein ISP nix anderes als halt ein Netzsegment das Traffic annimmt und weiterreicht, das Netz dann einfach nur der Verbund davon. Was in den Netzen passiert kann man schlichtweg nicht mit Sicherheit wissen.

> schlecht gepflegte CMS-Systeme, zumeist mit Cross-Site-Scripting oder
> MySQL-Injection oder plumpen Logins, bei denen man sich plötzlich ohne
> Passworte einloggen kann, vielleicht so 15% zusammen. Der Rest sind eher
> schlechte programmierte Scripte der Kunden, zumeist Upload-Scripte ohne
> sinnvolle Parameterprüfungen. Oder noch dümmere Sachen ...

Ja, das ist natürlich ein riesen Problem und macht viel der Alltagslast aus bei denen Daten von Kunden im massiven Ausmaß abgegriffen werden ... primär allerdings deshalb weil's schlicht um vieles einfacher ist sowas auszunutzen wenn man sich ein paar Minuten mit den typischen Exploit Toolkits auseinandersetzt oder gerade die Grundlagen gelernt hat ...
Kommt auch daher, dass bei der Entwicklung immer auf billig und schnell geachtet wird oder Leute entwickeln die leider nicht all zu viel Ahnung davon haben (wenn ich mir Regelmäßig den Unterricht an entsprechenden Schulen ansehe wo unterrichtet wird, dass man Parameter die man vom User empfängt direkt in ein SQL Statement einsetzt ... naja ... wenig Hoffnung, dass sich das bald ändert ...)

>
> BGP-Attacken ? DNS-Veränderungen ? Man-in-middle ? Nie gesehen. Sowas wäre
> für den Hacker auch viel zu aufwändig und geziehlt und pro "Ziel" zu
> speziell.

Ich hoffe jetzt einmal, dass das Ironie war - sowas passiert am laufenden Band ...

Meistens die BGP attacken halt aus Staatlicher Sicht aber es wird definitiv herummanipuliert und falsche Routen annonciert ...