On Wed, Nov 11, 2009 at 10:57:04AM -0500, Jonathan Katz wrote:
Anyone care to give a layman's explanation of the attack? The
explanations I have seen assume a detailed knowledge of the way TLS/SSL
handle re-negotiation, which is not something that is easy to come by
without reading the RFC.
On Mon, Nov 16, 2009 at 11:30 AM, Bernie Cosell ber...@fantasyfarm.com wrote:
As I understand it, this is only really a vulnerability in situations
where a command to do something *precedes* the authentication to enable
the command. The obvious place where this happens, of course, is with
Jonathan,
Anyone care to give a layman's explanation of the attack? The
I find this paper to be useful:
http://www.g-sec.lu/practicaltls.pdf
Cheers,
Stefan.
--
Stefan Kelm sk...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstrasse 100
Anyone care to give a layman's explanation of the attack? The
explanations I have seen assume a detailed knowledge of the way TLS/SSL
handle re-negotiation, which is not something that is easy to come by
without reading the RFC. (As opposed to the main protocol, where one can
find textbook
At Tue, 10 Nov 2009 20:11:50 -0500,
d...@geer.org wrote:
|
| This is the first attack against TLS that I consider to be
| the real deal. To really fix it is going to require a change to
| all affected clients and servers. Fortunately, Eric Rescorla
| has a protocol extension that
On Wed, Nov 11, 2009 at 10:57:04AM -0500, Jonathan Katz wrote:
Anyone care to give a layman's explanation of the attack? The
explanations I have seen assume a detailed knowledge of the way TLS/SSL
handle re-negotiation,
The re-negotiation handshake does not *commit* both parties in the
new
On 11 Nov 2009 at 10:57, Jonathan Katz wrote:
Anyone care to give a layman's explanation of the attack? The
explanations I have seen assume a detailed knowledge of the way TLS/SSL
handle re-negotiation, which is not something that is easy to come by
without reading the RFC. (As opposed to
On Mon, Nov 9, 2009 at 5:08 PM, Victor Duchovni
victor.ducho...@morganstanley.com wrote:
attack, checking Referrer headers is no longer effective, so anti-CSRF
defenses have to be more sophisticated (they *should* of course be more
Checking the Referer header never was effective. It's not even
|
| This is the first attack against TLS that I consider to be
| the real deal. To really fix it is going to require a change to
| all affected clients and servers. Fortunately, Eric Rescorla
| has a protocol extension that appears to do the job.
|
...silicon...
--dan
On Sun, Nov 08, 2009 at 01:08:54PM -0500, Perry E. Metzger wrote:
I'll point out that in the midst of several current discussions, the
news of the TLS protocol bug has gone almost unnoticed, even though it
is by far the most interesting news of recent months.
Not entirely unnoticed:
Perry E. Metzger wrote:
I'll point out that in the midst of several current discussions, the
news of the TLS protocol bug has gone almost unnoticed, even though it
is by far the most interesting news of recent months.
Perhaps because there have been so many false alarms over the years.
I'll point out that in the midst of several current discussions, the
news of the TLS protocol bug has gone almost unnoticed, even though it
is by far the most interesting news of recent months.
Perry
-
The Cryptography Mailing
12 matches
Mail list logo