[nycbug-talk] DC21, SSL all over the place...

[Chris Snyder]

On Thu, Aug 1, 2013 at 1:44 PM, Isaac (.ike) Levy
<ike at blackskyresearch.net>wrote:

>
> Nifty SSL nastiness (http deflate to find fragments of strings in https):
> http://arstechnica.com/**security/2013/08/gone-in-30-**
> seconds-new-attack-plucks-**secrets-from-https-protected-**pages/<http://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages/>


I was trying to figure out (from the article, since the presentation wasn't
available yet, how this works. It seems to rely on being able to inject an
arbitrary string into a page that also includes the secret you're trying to
discover. I keep trying to picture a real world scenario where that's
possible but I'm having a hard time... probably missing something.


Not Defcon, but related:
> "More Encryption Is Not the Solution", PHK, describes some novel attacks
> for cloud/carriers to trivially demolish ssl.
> http://queue.acm.org/detail.**cfm?id=2508864<http://queue.acm.org/detail.cfm?id=2508864>
>
> Pretty interesting reactions to the "encrypt everything" push for the
> interenet in the last few years...
>

Well exactly. SSL protects from spying on the wire, but not from spying in
the datacenter. And if you're a state-level actor, you can coerce your
local Certificate Authority to issue bogus certs for common services and
use proxies to sniff all the traffic.

The overall weakness of the model led to the zero-knowledge service
movement and secure peer-to-peer networks, but a determined attacker could
still compromise one of the endpoints with malware or sneaky code injection
like PHK describes.

The sad fact is, the Internet, and networked computers generally, are not
made for secrets. Hence the need to work in the real world to ensure that
state-level secrets aren't necessary.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20130802/ce3af83b/attachment.htm>