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
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
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstrasse 100 Tel: +49
On Mon, Nov 16, 2009 at 11:30 AM, Bernie Cosell 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
> HTTPS where the comma
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 oppose
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
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 t
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 appears to do the job.
> |
>
> ...s
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 de
|
| 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 Mon, Nov 9, 2009 at 5:08 PM, Victor Duchovni
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
guaranteed to be present, let
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.
Usually
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:
ht
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 L
13 matches
Mail list logo