http://www.golem.de/1408/108393.html
TLS, HSTS, SPDY, Wildcard-Certificates und mehr sind diesmal wieder durchgefallen.
Insbesondere die Attacke auf die Wildcard-Zertifikate machen den Einsatz dieser zu einem absoluten No-Go. Wer also irgendwo und wenn es noch so unbedeutend erscheinen mag ein Wildcard-Zertifikat einsetzt, sollte dieses schnellstmöglich gegen reguläre Zertifikate für jeden einzelnen Host tauschen.
SPDY ist ohnehin ein reines Experimentierprojekt und hat daher grundsätzlich nix auf produktiven Systemen verloren.
HSTS kann man vergessen, die Grundidee ist bereits kaputt und die Implementierung noch kaputter.
Cookie-Clutter ist altbekannt, daher erspare ich mir Worte dazu.
Weitere TLS/SSL-Probleme werden wohl im Laufe der derzeit stattfindenden Black Hat, DefCon und ihren vielen Nebenkonferenzen ans Tageslicht treten.
TLS, HSTS, SPDY, Wildcard-Certificates and more broken
TLS, HSTS, SPDY, Wildcard-Certificates and more broken
PayPal.Me/JoeUser ● FreeBSD Remote Installation
Wings for Life ● Wings for Life World Run
„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
Wings for Life ● Wings for Life World Run
„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
Re: TLS, HSTS, SPDY, Wildcard-Certificates and more broken
Das Problem liegt doch darin, dass SSL ansich (egal ob v3 oder TLS) schon "by design" problematisch sind bzw. viele Anforderungen, die man heute an so einen Protokoll-Zusatz haben dürfte nicht oder nur unzureichend erfüllen. Allein schon die latente Bindung an Layer 3 & 4 ist aus Applikationssicht eine mittelschwere Katastrophe. Leider bekommen mit IPv6 die SSL-Apologeten neues Futter: dann nehmt halt für jeden Dienst eine eigene Ip, macht ja nüscht... Wir werden also vergebens darauf hoffen, dass uns jemand eine gesunde E2E Transportverschlüsselung auf Layer 7 baut...
P. S. Weitere Stichworte wären da noch die Verifizierbarkeit von Zertifikaten (PKI, CA, die sogenannte "Trusted Third Party"), mangelnde PFS (zumindest für einige Cipher Suites), IV Schwächen (ebenfalls bezogen auf einige Cipher Suites) und ein kaputter Handshake. Dazu kommt noch, dass es fast unmöglich ist, SSL fehlerfrei in Code umzusetzen. Colin Percival hat recht:
https://www.bsdcan.org/2010/schedule/at ... pto1hr.pdf
http://cryptome.org/0005/ssl-broken.htm
P. S. Weitere Stichworte wären da noch die Verifizierbarkeit von Zertifikaten (PKI, CA, die sogenannte "Trusted Third Party"), mangelnde PFS (zumindest für einige Cipher Suites), IV Schwächen (ebenfalls bezogen auf einige Cipher Suites) und ein kaputter Handshake. Dazu kommt noch, dass es fast unmöglich ist, SSL fehlerfrei in Code umzusetzen. Colin Percival hat recht:
Hier noch ein bisschen Stoff:
- SSL is a horrible system.
- SSL is far too complex to be implemented securely.
- SSL gives attackers far too many options for where to attack.
- SSL requires that you decide which certificate authorities you want to trust.
Do you trust the Chinese government?- Unfortunately, SSL is often the only option available.
https://www.bsdcan.org/2010/schedule/at ... pto1hr.pdf
http://cryptome.org/0005/ssl-broken.htm
“Some humans would do anything to see if it was possible to do it. If you put a large switch in some cave somewhere, with a sign on it saying 'End-of-the-World Switch. PLEASE DO NOT TOUCH', the paint wouldn't even have time to dry.” — Terry Pratchett, Thief of Time