Der Titel "neues Tool" grenzt an absichtliche Irreführung. Das
zugrundeliegende Problem ist völlig offensichtlich, und es gab auch
schon die verschiedensten Vorschläge wie man es "entschärfen" könnte.
z.B. der hier
http://eprint.iacr.org/2006/212.pdf
Mit Renegotiation hat das Problem selbst überhaupt nichts zu tun, und
ein Client, der nur darauf aus ist Server zu quälen, braucht dafür
keine Renegotiation. Am effizientesten funktioniert der Angriff mit
massiv parallelen Client-Zugriffen und einem einzigen, konstanten und
einmalig korrekt per RSA-encrypt mit dem Server-Zertifikat
berechneten ClientKeyExchange. Selbst wenn der client den Handshake
hash und die ClientFinished korrekt erzeugt, zwingt er dem Server mit
der RSA private Key Operation eine gewaltige CPU-Last auf. Und mit
Migration von 1024-bit auf 2048-bit RSA-Schlüssel im
Server-Zertifikat steigt die Last auf dem Server nochmals um ca.
Faktor 3.5.
zugrundeliegende Problem ist völlig offensichtlich, und es gab auch
schon die verschiedensten Vorschläge wie man es "entschärfen" könnte.
z.B. der hier
http://eprint.iacr.org/2006/212.pdf
Mit Renegotiation hat das Problem selbst überhaupt nichts zu tun, und
ein Client, der nur darauf aus ist Server zu quälen, braucht dafür
keine Renegotiation. Am effizientesten funktioniert der Angriff mit
massiv parallelen Client-Zugriffen und einem einzigen, konstanten und
einmalig korrekt per RSA-encrypt mit dem Server-Zertifikat
berechneten ClientKeyExchange. Selbst wenn der client den Handshake
hash und die ClientFinished korrekt erzeugt, zwingt er dem Server mit
der RSA private Key Operation eine gewaltige CPU-Last auf. Und mit
Migration von 1024-bit auf 2048-bit RSA-Schlüssel im
Server-Zertifikat steigt die Last auf dem Server nochmals um ca.
Faktor 3.5.