Timingangriffe pure Theorie

[Horcrux7]

Also in der Realität, wo der Angreifer nicht bereits im Server ist, spielt das alles keine Rolle. Wir reden hier von Nanosekunden Laufzeitunterschied zu Millisekunden Responsezeit bei einem Webzugriff. Das sind 6 Größenordnungen. Und überall in der Kette gibt es variable Laufzeiten. Schwankende Lastzustände. etc.

Einfach mal ein paar Pings machen und sehen wie es hier bereits schwankt.

Aber selbst wenn es theoretisch möglich wäre mit Millionen Zugriffen, dann ist viel größere Problem das man die überhaupt zulässt.

[gelegenheitsposter]

Hier die Praxis:

"Our experiments show that we can extract private keys from an OpenSSL-based web server running on a machine in the local network. […] The attacking machine and the server were in different buildings with three routers and multiple switches between them. With this setup we were able to extract the SSL private key from common SSL applications such as a web server (Apache + mod_SSL) and a SSL-tunnel." -- Quelle: www-sciencedirect-com/science/article/abs/pii/S1389128605000125 (ich darf noch keine unkaputten Links posten…)

Es reicht also jetzt schon, nur einen Rechner in der Netz-Nachbarschaft zu kontrollieren. Der Weg zu "komplett von draußen" ist von diesem Stand aus nicht offensichtlich unmöglich.

[Horcrux7]

Bei dem Link stehen leider keine Details. Zum Beispiel welche Schutzmaßnahmen des Servers aktiv waren. Welche Zusätzlichen Operationen im Webserver, teilweise Random ausgeführt wurden. Wieviele Zugriffe notwendig waren, um den Private Key zu ermitteln. Dort wird nur gezeigt, das es theoretisch möglich ist. Das habe ich ja auch nicht bestritten.

Aber schauen wir uns doch mal reale Systeme an.
* Da werden diese massenweise Zugriffen durch einen DOS Filter erst verlangsamt und dann ganz geblockt.
* Ein veränderliche Inhalt, Cookie, Uhrzeit wird gezippt, was unterschiedliche Laufzeiten erzeugt.
* Zugriffscounter werden nach jedem X ten Zugriff geflasht
* Caches werden unkalkulierbar aktualisiert
* Bei GC Sprachen im Server kommen noch Random Garbage Collections hinzu
* Eventuell JIT Effekte
* RAM Cache Effekte
* Synchronized Aufrufe von komplett unabhängigen Aufrufen haben Effekte auf alle Threads
* Wenn mehr konkurrierende Requests als Cores da sind, gibt es Random Thread Wechsel, und damit Verzögerungen

Das sind nur ein paar Punkte. Jeden dieser Zufallsfaktoren kann man natürlich durch sehr viel mehr Requests und entsprechender Statistik rausrechnen. Das sind aber Milliarden Requests. Und warum sollte der Webserver das zulassen?

Und so ein Key ist nur 3 Monate gültig, dann gibt es einen neuen. Und man muss von vorne anfangen.