Leserreporter: Wer schöne Verschwörungslinks für mich hat: ab an felix-bloginput (at) fefe.de!
[zurück][ältere Posting][neuere Posting] Dienstag, 05 September 2017 | Blog: 8 | No: 39248
Ihr werdet vielleicht gesehen haben, dass Linux 4.13 jetzt "TLS im Kernel" hat. Und die Hände über dem Kopf zusammengeschlagen haben. Denn auf den ersten Blick ist das eine ganz furchtbare Idee.
Jetzt muss man den Kernel updaten, wenn es mal wieder ein TLS-Update gibt!? Ein Bug im TLS-Code liefert jetzt Kernel-Privilegien?! Der Kernel macht X.509 und ASN.1?! Womit so ziemlich jeder andere auf die Fresse geflogen ist, der das probiert hat?!?
Daher dachte ich mir, ich gebe mal zu Protokoll, dass ich das für eine tolle Idee halte. Und zwar ist nicht das Handshake im Kernel (das ist der komplexe Teil am Anfang, der mit den ganzen Protokollunwägbarkeiten), sondern der Kernel übernimmt lediglich die Transportverschlüsselung, nachdem der Schlüssel ausgetauscht ist. Ein bisschen Einkapseln, symmetrische Krypto drüberlaufen lassen, fertig. Da kann man immer noch was falsch machen, klar, aber das ist, von der Angriffsoberfläche her, sowas wie 1% von TLS. Da mache ich mir wenig Sorgen.
Und auf der anderen Seite steht der Vorteil. Wenn man im Moment einen Client hat, der irgendwas verkackt, dann kann man da mit beim System beliegenden Tools wie strace die System Calls tracen lassen. Da steht dann sowas wie:
Wenn ich den Zugriff habe, den strace benötigt, kann ich natürlich auch die unverschlüsselten Daten abgreifen. Das ist also kein Schutz gegen jemanden mit diesem Level an Zugriff. Aber es macht Debugging und Tracing halt sehr schwierig. Mit TLS im Kernel würde man wieder den Klartext in read und write sehen.
ALLEINE DAFÜR ist das schon eine Sache, die ich haben will.
Es gibt noch einen weiteren Vorteil, der ist mir aber nicht so wichtig. Der Webserver kann dann wieder zero-copy TCP mit sendfile() machen. Das ist dann nicht wirklich zero copy, weil der Kernel ja verschlüsselt. Der kann also nicht einfach DMA aus dem Buffer Cache machen. Aber immerhin, eine Kopie weniger. Das war auch der Grund, wieso dieser Patch überhaupt gemacht wurde.
Und der andere Vorteil ist, dass man mit Debugging-Zugriff im System dann auch die Daten im Transit verändern kann. Das ist wichtig für Pentesting, aber auch für automatisiertes Testing kann das nützlich sein. Im Moment muss man dann einen Proxy aufsetzen und im System dessen Zertifikat als Trusted eintragen und so weiter.
Diese Eingriffe gehen wohlgemerkt auch jetzt schon alle mit Debugging-Rechten. Sie sind nur viel anstrengender umzusetzen.
[zurück]
[ältere Posting][neuere Posting]
[zurück][ältere Posting][neuere Posting] Dienstag, 05 September 2017 | Blog: 8 | No: 39248
Ein Bug im TLS-Code liefert jetzt Kernel-Privilegien?
Jetzt muss man den Kernel updaten, wenn es mal wieder ein TLS-Update gibt!? Ein Bug im TLS-Code liefert jetzt Kernel-Privilegien?! Der Kernel macht X.509 und ASN.1?! Womit so ziemlich jeder andere auf die Fresse geflogen ist, der das probiert hat?!?
Daher dachte ich mir, ich gebe mal zu Protokoll, dass ich das für eine tolle Idee halte. Und zwar ist nicht das Handshake im Kernel (das ist der komplexe Teil am Anfang, der mit den ganzen Protokollunwägbarkeiten), sondern der Kernel übernimmt lediglich die Transportverschlüsselung, nachdem der Schlüssel ausgetauscht ist. Ein bisschen Einkapseln, symmetrische Krypto drüberlaufen lassen, fertig. Da kann man immer noch was falsch machen, klar, aber das ist, von der Angriffsoberfläche her, sowas wie 1% von TLS. Da mache ich mir wenig Sorgen.
Und auf der anderen Seite steht der Vorteil. Wenn man im Moment einen Client hat, der irgendwas verkackt, dann kann man da mit beim System beliegenden Tools wie strace die System Calls tracen lassen. Da steht dann sowas wie:
write(3,"GET /foo.txt HTTP/1.1Da kann man sehen, was der Client zu tun versucht hat. Und man kann die Antwort des Servers sehen. Wenn der Client TLS benutzt, dann sieht man bei strace nur noch die verschlüsselten Daten.
Host: example.com:80
",47)
Wenn ich den Zugriff habe, den strace benötigt, kann ich natürlich auch die unverschlüsselten Daten abgreifen. Das ist also kein Schutz gegen jemanden mit diesem Level an Zugriff. Aber es macht Debugging und Tracing halt sehr schwierig. Mit TLS im Kernel würde man wieder den Klartext in read und write sehen.
ALLEINE DAFÜR ist das schon eine Sache, die ich haben will.
Es gibt noch einen weiteren Vorteil, der ist mir aber nicht so wichtig. Der Webserver kann dann wieder zero-copy TCP mit sendfile() machen. Das ist dann nicht wirklich zero copy, weil der Kernel ja verschlüsselt. Der kann also nicht einfach DMA aus dem Buffer Cache machen. Aber immerhin, eine Kopie weniger. Das war auch der Grund, wieso dieser Patch überhaupt gemacht wurde.
Und der andere Vorteil ist, dass man mit Debugging-Zugriff im System dann auch die Daten im Transit verändern kann. Das ist wichtig für Pentesting, aber auch für automatisiertes Testing kann das nützlich sein. Im Moment muss man dann einen Proxy aufsetzen und im System dessen Zertifikat als Trusted eintragen und so weiter.
Diese Eingriffe gehen wohlgemerkt auch jetzt schon alle mit Debugging-Rechten. Sie sind nur viel anstrengender umzusetzen.
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.
