Re:SSL broken. (TLS 1.0 cryptographic attack that works. ...
by redthrowaway on Monday September 19, 2011 @07:41PM
(#3015656)
How would they jump sandboxes? Wouldn't that require a browser-specific attack? For example, how would some injected code on HN jump over to my secure banking tab, in another chrome process?
[ Parent
| on HN ]
Re:SSL broken. (TLS 1.0 cryptographic attack that works. ...
by caf on Monday September 19, 2011 @07:56PM
(#3015702)
Presumably the injected code creates specially crafted requests to the SSL site being attacked - it can't read the results of those requests, but that doesn't matter: its only purpose is to create some adaptively-chosen known plaintext for the sniffer.
Re:SSL broken. (TLS 1.0 cryptographic attack that works. ...
by kijin on Monday September 19, 2011 @08:45PM
(#3015798)
Wouldn't that be blocked by cross-site AJAX restrictions? Or are we talking about injecting <img> and <script> tags into the document?
Re:SSL broken. (TLS 1.0 cryptographic attack that works. ...
by caf on Monday September 19, 2011 @09:24PM
(#3015878)
The latter, or maybe iframes.
Re:SSL broken. (TLS 1.0 cryptographic attack that works. ...
by scotth on Tuesday September 20, 2011 @09:23AM
(#3017411)
No, it wouldn't. With AJAX, the request always goes out, and is received and processed by the server if they choose to (most never check the request origin).
Then, the server can decide whether or not to attach cross origin resource sharing headers to the response. If those headers exist, the response is exposed to JavaScript. If not, they are swallowed by the browser.
Re:SSL broken. (TLS 1.0 cryptographic attack that works. ...
by redthrowaway on Tuesday September 20, 2011 @12:51AM
(#3016336)
In the case of Chrome (and other browsers are moving in the same direction), you should be able to check the pid of the instance you're dealing with. At least, I assume that's the case if they're offering native c++ support.