Subject: [OAUTH-WG] CRIME II alleged at Black Hat

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 2 Jul 2013 17:53:26 +0300

FYI: http://www.darkreading.com/vulnerability/https-side-channel-attack-a-tool-for-enc/240157583

From the abstract: 
"
A new side channel vulnerability in HTTPS traffic could make it possible for targeted attackers to dig up secrets like session identifiers, CSRF tokens, OAuth tokens, and ViewState hidden fields without users ever being the wiser, say researchers who will explain how the attack could work at this year's Black Hat.
"

Unfortunately, I wasn't able to find a lot of details about this attack yet. 
Maybe some of you has more details.

Ciao
Hannes

---

From: Bill Mills <[email-masked]>
Date: Tue, 2 Jul 2013 08:05:34 -0700 (PDT)

Are you familiar with the basic CRIME vulnerability?

________________________________
 From: Hannes Tschofenig <[email-masked]>
To: "[email-masked] WG" <[email-masked]> 
Sent: Tuesday, July 2, 2013 7:53 AM
Subject: [OAUTH-WG] CRIME II alleged at Black Hat

From the abstract: 
"

Ciao
Hannes

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 2 Jul 2013 18:22:37 +0300

The CRIME attack is already a bit older. I hope (for the presenters) that this is somewhat different; not just rehashing the old attack.  

Ciao
Hannes

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Jul 2013 11:24:53 -0400

Calling the attack CRIME II may be an unwarranted assumption on my part. At
this point all I have to go on is the abstract. Given the nature of
breaches it is hard to see how someone could be mistaken about their
exploit code having worked but it is certainly possible. It is also
possible that it hangs off some non standard shortcut as Hannes suggests.

I am not at all happy with the idea of header compression. I think we
should stop that effort dead in its tracks. Compact header representations
that replace headers with predefined codes from a static dictionary are OK.
Any scheme which gives the attacker an opportunity to manipulate the
dictionary is a bad idea at the best of times. It is a terrible idea when
the attacker can put active code in the browser and affect headers.

We should be changing the way that we design security systems. Instead of
saying 'is this safe' we should ask 'how many things have to break before
the system is broken'.

At the moment we are hanging Internet security off a peg that is vulnerable
to a single point of failure.

An authentication scheme should be secure even if there is a compromise in
other layers.

On Tue, Jul 2, 2013 at 11:05 AM, Bill Mills <[email-masked]> wrote:

>   ------------------------------
>  *From:* Hannes Tschofenig <[email-masked]>
> *To:* "[email-masked] WG" <[email-masked]>
> *Sent:* Tuesday, July 2, 2013 7:53 AM
> *Subject:* [OAUTH-WG] CRIME II alleged at Black Hat
>
> FYI:
> http://www.darkreading.com/vulnerability/https-side-channel-attack-a-tool-for-enc/240157583
>
> From the abstract:
> "
> A new side channel vulnerability in HTTPS traffic could make it possible
> for targeted attackers to dig up secrets like session identifiers, CSRF
> tokens, OAuth tokens, and ViewState hidden fields without users ever being
> the wiser, say researchers who will explain how the attack could work at
> this year's Black Hat.
> "
>

-- 
Website: http://hallambaker.com/