3 ms·

I've also tried to post a couple of links discussing these attacks in practice, and comparing the risks from BEAST/Lucky 13 to these... * https://news.ycombina

I've also tried to post a couple of links discussing these attacks in practice, and comparing the risks from BEAST/Lucky 13 to these... * https://news.ycombinator.com/item?id=5367805 https://news.ycombinator.com/item?id=5367805 - links to a very interesting answer on security stackexchange that puts things into pretty good perspective. * https://news.ycombinator.com/item?id=5368610 https://news.ycombinator.com/item?id=5368610 - links to an interesting possible browser workaround to these attacks. (disclaimer: I'm the one who posted both the questions on security stackexchange and HN posts. I'm not trying to be a karma whore, just hoping to get some discussion going on around those... both went under the radar)

tptacek 14y ago
The first article ignores the decrypt-then-verify timing leak in the TLS CBC modes ("Lucky 13") when it suggests you might just switch back to AES-CBC because BEAST is hard to exploit. The second article is based on the assumption that you can reliably pad the headers between the request and the cookie in a browser on every vector an attacker has to coerce a browser into making connections. People seem to be thinking about serverside fixes; this is a clientside problem.
- gingerlime 14y ago
  would be interesting if you can share those thoughts on security stackexchange. Guys like Thomas Pornin seem very knowledgeable and I'd be curious to hear his take on this.