Leserreporter: Wer schöne Verschwörungslinks für mich hat: ab an felix-bloginput (at) fefe.de!
[zurück][ältere Posting][neuere Posting] Mittwoch, 09 Dezember 2020 | Blog: 8 | No: 46244
Apple und Cloudflare haben sich gerade zusammengetan, um ein tolles neues DNS-Ersatzprotokoll zu basteln.
Ich habe mich ja schon über die früheren Versuche von Cloudflare öffentlich geärgert, und aus meiner Sicht ist alles, was irgendwo in der Infrastruktur ein Cloudflare beinhaltet, direkt abzulehnen.
Aber ich hab mir das RFC mal angeguckt. Stellt sich raus: Die machen da Onion Routing. Also so ein bisschen. Eine Zwiebel mit nur einer Schicht. Ist wie Tor, nur schlechter.
Nehmen wir mal an, ich will was im DNS nach gucken. Dann hole ich mir aus dem DNS (das RFC liegt bisher nur als Draft vor, und es sagt: ich soll dem nur trauen, wenn es per DNSSEC kam!1!!) den public key von dem Cloudflare-Service. Dann gehe ich zu einem der drei Proxy-Server, der für Europa steht bei Surfnet (in den Niederlanden). Dem drücke ich eine Anfrage in die Hand, über https, aber die Anfrage ist auch nochmal verschlüsselt mit dem pubkey von Cloudflare. Surfnet geht damit zu Cloudflare und Cloudflare hat dazu den private key und kann das entschlüsseln.
Die Idee ist, dass Cloudflare dann nur die IP von Surfnet sieht, nicht von mir.
Cloudflare verschlüsselt dann die Antwort an meinen pubkey, den ich in dem Paket mitgeschickt habe.
Da können wir direkt aufhören, über das Protokoll zu reden. Da steht dann zwar nicht meine IP dran, aber mein pubkey. Das ist genau so eindeutig. Was für Spezialexperten denken sich denn bitte solche Protokolle aus!?
Nun würde man denken, dass im RFC steht: du musst pro Anfrage nen anderen Key nehmen. Steht da aber nicht.
Jetzt stellt sich auch die Frage, wieso da überhaupt ein public key drinsteht. Wir haben ja das Protokoll so entworfen, dass nur Cloudflare die Anfrage entschlüsseln kann. Da hätte ich also auch einfach direkt einen zufälligen AES-Key reintun können und mit dem kommt dann die Antwort verschlüsselt. Der Proxy sieht dann die verschlüsselte Antwort aber sah den Key vorher nicht. Public Key Krypto ist langsam und teuer!
Ich fühle mal wieder alle meine Vorurteile vollumfänglich bestätigt.
Seufz.
Mit so einem gemeinsamen Key kann man übrigens auch "signieren". Machst du ein SHA-256 von den Nutzdaten plus dem Key, den du aber nicht in der Antwort wieder mit rausschickst. Fertig. Sparst du dir auch noch die Signier-Pubkey-Operation.
[zurück]
[ältere Posting][neuere Posting]
[zurück][ältere Posting][neuere Posting] Mittwoch, 09 Dezember 2020 | Blog: 8 | No: 46244
ich soll dem nur trauen, wenn es per DNSSEC kam!1!!
RFC liegt bisher nur als Draft vor
Ich habe mich ja schon über die früheren Versuche von Cloudflare öffentlich geärgert, und aus meiner Sicht ist alles, was irgendwo in der Infrastruktur ein Cloudflare beinhaltet, direkt abzulehnen.
Aber ich hab mir das RFC mal angeguckt. Stellt sich raus: Die machen da Onion Routing. Also so ein bisschen. Eine Zwiebel mit nur einer Schicht. Ist wie Tor, nur schlechter.
Nehmen wir mal an, ich will was im DNS nach gucken. Dann hole ich mir aus dem DNS (das RFC liegt bisher nur als Draft vor, und es sagt: ich soll dem nur trauen, wenn es per DNSSEC kam!1!!) den public key von dem Cloudflare-Service. Dann gehe ich zu einem der drei Proxy-Server, der für Europa steht bei Surfnet (in den Niederlanden). Dem drücke ich eine Anfrage in die Hand, über https, aber die Anfrage ist auch nochmal verschlüsselt mit dem pubkey von Cloudflare. Surfnet geht damit zu Cloudflare und Cloudflare hat dazu den private key und kann das entschlüsseln.
Die Idee ist, dass Cloudflare dann nur die IP von Surfnet sieht, nicht von mir.
Cloudflare verschlüsselt dann die Antwort an meinen pubkey, den ich in dem Paket mitgeschickt habe.
Da können wir direkt aufhören, über das Protokoll zu reden. Da steht dann zwar nicht meine IP dran, aber mein pubkey. Das ist genau so eindeutig. Was für Spezialexperten denken sich denn bitte solche Protokolle aus!?
Nun würde man denken, dass im RFC steht: du musst pro Anfrage nen anderen Key nehmen. Steht da aber nicht.
Jetzt stellt sich auch die Frage, wieso da überhaupt ein public key drinsteht. Wir haben ja das Protokoll so entworfen, dass nur Cloudflare die Anfrage entschlüsseln kann. Da hätte ich also auch einfach direkt einen zufälligen AES-Key reintun können und mit dem kommt dann die Antwort verschlüsselt. Der Proxy sieht dann die verschlüsselte Antwort aber sah den Key vorher nicht. Public Key Krypto ist langsam und teuer!
Ich fühle mal wieder alle meine Vorurteile vollumfänglich bestätigt.
Seufz.
Mit so einem gemeinsamen Key kann man übrigens auch "signieren". Machst du ein SHA-256 von den Nutzdaten plus dem Key, den du aber nicht in der Antwort wieder mit rausschickst. Fertig. Sparst du dir auch noch die Signier-Pubkey-Operation.
Twiter-Ticker
Fefes Latest Youtube Video Links
Der Betrieb der KraftZeitung kostet Geld. Da wir auch weiterhin unabhängig, überparteilich und ohne kommerzieller Werbung für Sie da sein wollen, sind wir auf Ihre Spende angewiesen. Vielen Dank.
