Subject: [TLS] Rizzo claims implementation attach, should be interesting

From: Tim Dierks <[email-masked]>
Date: Sat, 10 Sep 2011 12:41:11 -0400

Does anyone have any ideas what Rizzo may be announcing @ ekoparty?

http://www.ekoparty.org/2011/juliano-rizzo.php

BEAST: Surprising crypto attack against HTTPS

We present a new fast block-wise chosen-plaintext attack against SSL/TLS. We
also describe one application of the attack that allows an adversary to
efficiently decrypt and obtain authentication tokens and cookies from HTTPS
requests. Our exploit abuses a vulnerability present in the SSL/TLS
implementation of major Web browsers at the time of writing.

 - Tim

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 11 Sep 2011 05:11:31 +1200

>Does anyone have any ideas what Rizzo may be announcing @ ekoparty?

I don't know about this one, but his previous work has been on CBC padding
oracle attacks, and was pretty impressive stuff, so it may be something on
those lines.

Peter.

---

From: Martin Rex <[email-masked]>
Date: Mon, 19 Sep 2011 20:57:44 +0200 (MEST)

> BEAST: Surprising crypto attack against HTTPS

The first details seem to be leaking:

http://threatpost.com/en_us/blogs/new-attack-breaks-confidentiality-model-ssl-allows-theft-encrypted-cookies-091611

It seems to be a Man-in-the-Browser attack on SSLv3/TLSv1.0 confidentiality
of ciphers suites with a block cipher in CBC-mode, similar to the original
attack here:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5887&rep=rep1&type=pdf

The original SSL&TLS protocol was never designed to protect data that
is multiplexed onto a single TLS connection to be protected from each other,
because the traffic-keys are created once per connection.

SSL VPNs, which are an abuse of the SSL&TLS technology clearly beyond
its original design scope, are likely much more difficult to fix than
Web Browsers.  The explicit IVs introduced by TLSv1.1 for block ciphers
with CBC-mode might be an acceptable mitigation, but it is not a clean
solution (because it does not address the underlying design, where the
same symmetric crypto key is reused for data controlled by the attacker.
 
A Web-Browser with a reasonable design of security zones could try to
ensure that requests originating from different security domains
never re-use network sockets from other domains.  Resuming TLS sessions
from other domains is not a problem, because traffic encryption and
mac keys are regenerated for each connection, so you don't need more
TLS handshakes, only more sockets whose scope for reuse/multiplex
is limited.

TLS cipher suites with stream ciphers (like rc4-128) or with block ciphers
abused as stream ciphers (AES GCM or CCM, i.e. the AEAD cipher suites)
are probably not as much affected, because they do not exactly
"reuse" the exact same secret keys for data of the victim and data
of the attacker, I assume.

-Martin

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Mon, 19 Sep 2011 17:42:17 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Martin Rex
> 
> Tim Dierks wrote:
> >
> http://threatpost.com/en_us/blogs/new-attack-breaks-confidentiality-
> model-ssl-allows-theft-encrypted-cookies-091611

More "details" here:

http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/

Or at least more confirming quotes from the researchers about how quickly the can perform the attack.

---

From: Martin Rex <[email-masked]>
Date: Tue, 20 Sep 2011 02:53:05 +0200 (MEST)

Steingruebl, Andy wrote:
> Martin Rex wrote:

It seem to be a huge hype an exxageration of the problem.
There is *no* problem in SSLv3 or TLSv1.0.  This particular attack
is a very clear "Man-in-the-Browser" attack enabled solely by the
entirely braindead (lack-of) security in common Web Browsers.

Since the attack happens entirely at the browser, it should IMHO
the browser's duty to fix this.

Potential server-side mitigation of the problem:

  - disable HTTP request pipelining (aka Connect: keep-alive)

  - avoid CBC-based cipher suites (at least when SSLv3 or TLSv1.0
    is negotiated), and use RC4-128 instead.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Mon, 19 Sep 2011 21:31:18 -0500

> the browser's duty to fix this.

Last I checked, the TLS RFC stated explicitly that the protocol defended 
explicitly against man-in-the-middle attacks. It did not say it defended 
against "blockwise-adaptive chosen-plaintext" attacks.

But why split hairs over it? It breaks a basic security properties of 
the system even if the application designer has done everything 
according to the recommendations in the spec. Since when did "trusted 
script only" in the application become a requirement for transport layer 
security?

>    - disable HTTP request pipelining (aka Connect: keep-alive)

Expensive.

>      is negotiated), and use RC4-128 instead.

Does TLS's use of RC4 still take the first bytes after initialization 
with the key? Or does it discard the proper amount?

I believe there was a mitigation put in place by OpenSSL: sending an 
empty (just padding) message before each app data message. The document 
at eprint.iacr.org/2006/136 suggests that this could be a server-side 
only change. I don't see how that would work since the session cookie 
recovery attack is clearly happening on the client->server channel.

I read somewhere that this mitigation was off by default in OpenSSL 
because it some software (an old MSIE IIRC).

Does anyone believe there would be support for a TLS 1.0 Hello extension 
that could compatibly negotiate the use of empty messages in each 
direction as a mitigation for this attack?

I've not been told the details of Duong and Rizzo's attack and haven't 
seen "the BEAST" in action yet, so I'm not sure if that would be 
sufficient to fix CBC in TLS 1.0. I am slightly annoyed at these guys 
for dribbling out the information one hint at a time like this.

- Marsh

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Sep 2011 20:49:27 -0700

On Mon, Sep 19, 2011 at 7:31 PM, Marsh Ray <[email-masked]> wrote:
> that could compatibly negotiate the use of empty messages in each direction
> as a mitigation for this attack?

The difference between TLS 1.0 and TLS 1.1 is so slight that if TLS
1.1 is indeed
immune it would probably be easier to just have servers upgrade to 1.1.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Sep 2011 20:50:28 -0700

> immune it would probably be easier to just have servers upgrade to 1.1.

s/servers/clients and servers/

Best,
-Ekr

---

From: Yoav Nir <[email-masked]>
Date: Tue, 20 Sep 2011 07:12:23 +0300

> because it some software (an old MSIE IIRC).

Yes, Internet Explorer 6 has that problem. Also SSL-using services running under XP.

> direction as a mitigation for this attack?

If you're going to upgrade to a browser that supports the extension, might as well upgrade to IE7. It can deal with the empty fragment.

> for dribbling out the information one hint at a time like this.

A time like what?

---

From: Marsh Ray <[email-masked]>
Date: Mon, 19 Sep 2011 23:19:52 -0500

On 09/19/2011 11:12 PM, Yoav Nir wrote:
>> I am slightly annoyed at
>> these guys for dribbling out the information one hint at a time
>> like this.
>
> A time like what?

(one hint at a time) like this
    not
one hint (at a time like this)

Sorry for the parsing ambiguity. :-)

- Marsh

---

From: Yoav Nir <[email-masked]>
Date: Tue, 20 Sep 2011 08:24:55 +0300

> Sorry for the parsing ambiguity. :-)

Sorry. Reading it again, it's obvious. Guess we should switch all IETF mailing lists to lojban.

---

From: Martin Rex <[email-masked]>
Date: Tue, 20 Sep 2011 16:45:56 +0200 (MEST)

Eric Rescorla wrote:
> 1.1 is indeed immune it would probably be easier to just have servers
> upgrade to 1.1.

Using the TLSv1.1 explicit random IVs for TLS cipher suites with
block ciphers in CBC-mode would be my preferred solution -- provided
that a significant majority believes this to be a sufficient mitigation.
(Personally, I think that it is not a clean solution, but may be OK
 as a mitigation that makes this attack sufficiently "expensive").

I don't see why adding and enabling TLSv1.1 on Servers should cause
interop problems, but I'm completely lacking experience in that area
to make any assessments. 

A client that announces TLSv1.1 (and no application level reconnect
fallback) is much more likely to run into interop problems, similar
to a client that includes a TLS extension in ClientHello.  Newer
Browsers (those that are affected by this Man-in-the-Browser attack)
usually have a reconnect fallback capability and should be able
to cope with this.

But really, the underlying problem is letting an attacker reuse
the very same symmetric key for his own data (adaptive chosen plaintext).
Knowing the IV ahead of time can significantly improve an adequate choice
of plaintexts, which is why the problem is worse in SSLv3 and TLSv1.0.

But it should really be possible for browsers to seperate the TLS sockets
that evil code can use and the sockets that victim code can use safely.
Sharing cached TLS sessions is not a problem, each connection will
derive their own traffic encryption and mac keys.  If Browsers can not
seperate those network traffics, then there will be much more serious
problems in the browser architecture to worry about than an attack
that requires a cooperating network sniffer and malware running in
your browser and a significant amount of network traffic between
them.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Tue, 20 Sep 2011 10:13:09 -0500

> that evil code can use and the sockets that victim code can use safely.

If only applications would set the 'evil bit' it would make a lot of 
things simpler!

But we can't add that as a new requirement for the existing protocols.

> your browser and a significant amount of network traffic between

People keep thinking of this in terms of a compromised endpoint attack. 
Bard 2004 even talks about requiring a "trojan horse plug in" to be 
practical. Bard 2006 reduces that to a malicious Java applet.

But I'm not convinced. Basic HTTP and browser behavior still leaves a 
lot of room for creativity. When the corresponding flaw was identified 
in IPsec it was not so easily dismissed on the basis that it required a 
compromised endpoint. From what I hear, TLS is used for VPN trunking too.

What about SMTP/POP/IMAP over TLS? They have similar amounts of known 
plaintext as HTTP, and an attacker may have the ability to control a 
large volume of messages, perhaps even in both directions.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Tue, 20 Sep 2011 17:21:27 +0200 (MEST)

> for dribbling out the information one hint at a time like this.

The "ekoparty conference" is 21-23 Sep., and usually if you get a
paper accepted for a conference, you're not supposed to publish
before the conference...

> against "blockwise-adaptive chosen-plaintext" attacks.

It does defend against man-in-the-middle attacks.

> according to the recommendations in the spec.

Wrong.  I do not believe that it breaks any of the security properties.
It does break some flawed assumptions.

SSL was NEVER designed with a promise that you could multiplex
data from an evil attack with data from a victim over the very same
SSL connection and be secure against adaptive chose plaintext
attacks trying to recover data from the victim.

>From the SSL design it is quite clear that for CBC encryption, the
encryption key is static for a single connection (=reused for every
cipher block), so mupliplexing data from evil and victim like it
is done in SSL-VPNs or allegedly here by "BEAST" by subverting the
browser security model, that is a clear abuse of the SSL protocol
beyond it's design limitations.

You see it in every episode of Star Trek -- whenever the captain decides
to operate the engines significantly beyond the design limits, the engine
suffers significant damages.  That's not "ficition", it applies similarily
to NASA spacecraft, to aircrafts, vehicles on the road and other products
of technical design.

>
> Since when did "trusted script only" in the application become a
> requirement for transport layer security?

Do NOT run trusted and untrusted data over the very same SSL connection,
because there are no properties in the SSL design to avoid this impairing
the resulting confidentiality.  SSL is no panacea or silver bullet
(never was) and using a technology beyond its design limits is
always a bad idea.

> >    - disable HTTP request pipelining (aka Connect: keep-alive)

Not for those braindead "secure checkout" or "secure payment" pages
in an otherwise completely unprotected online shop -- which includes
Paypal.

> with the key? Or does it discard the proper amount?

How significant is the RC4 initialization bias for a brief communication
with an SSL-secured checkout / payment ?

(The suggestion was meant to be a mitigation, not a solution)

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Sep 2011 08:27:34 -0700

> paper accepted for a conference, you're not supposed to publish

For what it's worth, that's not the convention in most academic security
conferences I've been involved with (e.g., USENIX Security, ISOC NDSS,
IEEE Oakland). Indeed, it's common to see papers submitted (i.e.,
not even accepted!) that have already been distributed on the author's
web sites. I don't know what the rules for ekoparty are, however.

-Ekr

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 20 Sep 2011 16:04:23 -0400

> attacks trying to recover data from the victim.

SSL came before Javascript and even before cookies. So this is certainly
outside the model.

Adding AES in CBC mode probably came after the model had been changed
though.

If we want to avoid this type of attack we should probably change the
encryption mode. I don't like stream ciphers in general, but SSL was
designed round one and has been extensively verified when a stream cipher is
used.

>From a design point of view, re-use of the same key to encrypt each block is
bad news and turning a block cipher into a stream cipher is bad news. Anyone
know why CBC is so popular vs PCBC?

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

---

From: Nico Williams <[email-masked]>
Date: Tue, 20 Sep 2011 16:04:25 -0500

>> attacks trying to recover data from the victim.

I wasn't there.  I don't know what it was designed for.  But here's
the thing: why shouldn't the designers have assumed that some of the
data sent over SSL might be untrusted?  On what grounds would it have
been OK to say "no untrusted data, please"?  And where was this
restriction documented?

But let's grant that restriction.  That would have meant that we
should never have allowed IMAP over SSL, for example, and taking the
argument to extremes, we should never have allowed HTTP POST over SSL
either.

This is really Marsh's point, I think, and I agree with it.

> Adding AES in CBC mode probably came after the model had been changed

Yeah, sure, but I think it's fairer to say that the subject probably
didn't come up, not that SSL was not intended for this.

> know why CBC is so popular vs PCBC?

Block ciphers in counter mode are as broken in the face of key&IV
reuse as any stream cipher, and for the same sorts of reasons.  This
is not a reason to not use counter modes.  It's a reason to use them
with care.

For example, in a situation like Kerberos' PDUs counter modes are
dangerous because there's no "connection" context for most of those
PDUs, thus no way to prevent key&IV reuse.  But for TLS, and even
DTLS, there's no such issue.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 20 Sep 2011 23:31:51 +0200 (MEST)

> been OK to say "no untrusted data, please"?  And where was this

It is a design limit that should be obvious to the conscious reader
with background knowledge about cryptography.

> This is really Marsh's point, I think, and I agree with it.

No, you're entirely confusing things.

Independent TLS connection states (even for the same cached TLS session)
do not share traffic encryption and mac keys, so these are protected
from each other.

But when you start multiplexing adaptively chosen plaintext from
an attacker with data from a victim, then you're creating an oracle.
For TLS cipher suites using block ciphers in CBC mode, there is
a fixed encryption key for all blocks of data.  Now if the
block of data for which the attacker wants to recover the exact
plaintext is sufficiently short (e.g. DES-based = 64-bit), and this
block of contains a small amount of unknown entropy, and the attacker
is permitted sufficient guesses at the original plaintext, the attacker
may perform a guessing attempt at that unknown victim data.

> didn't come up, not that SSL was not intended for this.

It was not a design requirement at that time, so that property does
not exist in the original SSLv3 (and TLS) design.  When cipher suites
with stream ciphers are not affected, then this is a lucky coincidence,
not a result of a conscious design (based on a requirement).

> is not a reason to not use counter modes.  It's a reason to use them

For every block with a known IV and known plaintext, the attacker learns
equal to the blocksize IV+plaintext pairs for a static key. (flip the
same bit in IV and plaintext and you get the same ciphertext).
For CBC, the IV is the ciphertext on the wire from the previous block
(except for the first IV on the first record in all version of TLS).

> DTLS, there's no such issue.

I actually feel more uncomfortable with cryptographic protocols that
are used in automated online scenarios and do not employ replay protection
(which probably means that communication with the Kerberos KDC is
 theoretically vulnerable, and what's missing is only attractive attacks
 that exploit this.)

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Tue, 20 Sep 2011 16:47:53 -0500

> an attacker with data from a victim, then you're creating an oracle.

It's only an oracle if there is information revealed to the attacker. If 
that's the case, it should be considered a cryptographic weakness.

> may perform a guessing attempt at that unknown victim data.

Yeah CBC sucks, especially with predictable IVs.

It's a weakness.

> not a result of a conscious design (based on a requirement).

Well where does that reasoning end?

If a defect were found in TLS which could be exploited using long 
strings of the letter 'A', would you say that the protocol was never 
"designed to resist long strings of the letter 'A' attacks"?

This protocol is something called "IETF Transport Layer Security". It's 
not "Security for Data That M. Rex Feels Web Browsers Should Be Able to 
Transport Securely". :-)

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Tue, 20 Sep 2011 23:53:18 +0200 (MEST)

> may perform a guessing attempt at that unknown victim data.

What I forgot: if the attacker knows the IV ahead of time (the IV that will
be used to CBC-encrypt the attackers chosen plaintext) or if the attacker can
force the IV value that will be used, then the guessing will become
extremely effective for low-entropy unknowns (provided that the attacker
knows the IV that was used for the unknown, but for CBC that is well known
whenever that IV is either explicit or when CBC is used and the unknown
io in a later block.

-Martin

---

From: Geoffrey Keating <[email-masked]>
Date: 20 Sep 2011 15:35:32 -0700

> attacks trying to recover data from the victim.

This would imply that you should not use SSL for downloading e-mail
using POP or IMAP, because that's multiplexing evil data (mail sent to
you by the attacker) with trusted data (credentials and non-evil
mail).

---

From: Martin Rex <[email-masked]>
Date: Wed, 21 Sep 2011 00:58:52 +0200 (MEST)

> Yeah CBC sucks, especially with predictable IVs.

It is a well known design characteristic of CBC-Mode.

It only becomes a weakness when CBC-Mode is used inappropriately,
like when the same key is used to protect data that ought to be
seperate.  Or when it is used in a fashion that gives attackers
an easy "adaptive chosen plaintext attack capability" for free.
(Applied Cryptography 2nd Ed., page 6 (4.)  -- such as a Web-Browser
that not only runs arbitrary active content as a courtesy to the
attacker, but also lets this malicious code re-use an established
SSL connection through which supposedly confidential data was
transmitted to mount an adaptive chosen plaintext attack.

On my sorecard, that is a Browser shooting itself in the foot.

> "designed to resist long strings of the letter 'A' attacks"?

That would be a weakness in the chosen cipher and the particular
operating mode that was used for the particular affected cipher suite.

Of course, the TLS protocol will inherit any weaknesses from underlying
crypto protocols.

The TLS renegotiation problem was not a protocol defect of TLS,
it was a flawed assumption of consumers of TLS about a security
property that never existed.  And obviously, noone who relied on
TLS renegotiation to be secure ever cared to look at the protocol
specification and check whether it really provided such a
security property.  Anyone who had _seriously_ looked at TLS
would have realized that no secure renegotiation property existed
in the original SSLv3 specification.

> not "Security for Data That M. Rex Feels Web Browsers Should Be Able to 

I know that it is called "IETF Transport Layer Security".
But lots of folks seem to confuse TLS with "magic pixie dust" or "snake oil",
a panacea that cures everything, known and unknown -- and completely
fail to recognize that _every_ design has limits and ignoring any
such limits will regularly have dire consequences.

If random pads are reused and that results in recovery of both messages
that were protected with that random pad through cryptoanalysis of
the XORed plaintexts, then this is not a "totally unexpected weakness of
the random pad encryption scheme", but instead a known design limit
and a complete failure of the users who goofed the management of
the cryptographic keys (the random pad).

I haven't yet seen a detailed description of the BEAST attack, but
what has been leaked so far (and that TLSv1.1 is allegedly not
susceptible to this particular attack) suggests that they're
exploiting a definite design flaw in the web browser that exhibits an
obvious and serious negligence in the management of TLS connection states
therefore providing a free "chosen adaptive plaintext attack" facility
as a courtesy to the attacker besides the courtesy to run arbitrary
attacker-supplied active content.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 21 Sep 2011 01:14:27 +0200 (MEST)

> you by the attacker) with trusted data (credentials and non-evil
 
You are quite correct in recognizing that you might be helping
the attacker in a known-plaintext or chosen-plaintext attack (and when
you have an automatically polling IMAP client, maybe even an adaptive
chosen-plaintext attack).  So it would be sensible to limit the number
of guesses for the attacker, and to not re-use the same crypto keys
on subsequent accesses to the same IMAP server (TLS does the latter for
you when you create a new TLS connection state for each subsequent access,
i.e. TLS session resume or full handshake, both will do).

-Martin

---

From: Nico Williams <[email-masked]>
Date: Tue, 20 Sep 2011 18:33:17 -0500

> with background knowledge about cryptography.

It's been roughly two decades, and only now did this get noticed.  And
there are many experts who've worked on TLS and apps that use it.

Undocumented design limitations are not obvious, even if in retrospect
they should have been.

> do not share traffic encryption and mac keys, so these are protected

I said nothing about sharing of keys across connections.  I did not
even imply it.

> an attacker with data from a victim, then you're creating an oracle.

Multiplexing?  Just mixing will do.  IMAP lets you... read emails from
untrusted sources (e.g., spam), as well as ones from trusted sources.
Oops.  This is silly.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 21 Sep 2011 02:10:24 +0200 (MEST)

Nico Williams wrote:
> 
> Martin Rex wrote:
> > > data sent over SSL might be untrusted? Â On what grounds would it have
> > > been OK to say "no untrusted data, please"? Â And where was this
> > > restriction documented?
> >

You seem to be approaching the issue from the wrong end.

Rely only on those design properties that have been explicitly specified
_and_ independently verified.  NEVER assume capabilities / properties
that are neither specified nor independently verified.

Of course, taking short cuts is much easier and cheaper, but don't
complain later if you get burnt.

> untrusted sources (e.g., spam), as well as ones from trusted sources.

No, this isn't silly.  Welcome to the real world.

Your 2^112 bits symmetric crypto strength for 3DES-EDE-CBC
and 2^128 bits symmetric crypto strength for AES128-CBC can be
significantly reduced by your usage scenarios.  In a highly automated
online world up to the point of non-existence, as in Rizzo's last
years demonstration for ASP.NET:

http://www.schneier.com/blog/archives/2010/09/new_attack_agai_1.html

Such flaws are _not_ limited to propriatary misuse of crypto.
There is more to come later this year.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 21 Sep 2011 03:19:50 +0200 (MEST)

> been OK to say "no untrusted data, please"?  And where was this

Btw. in my reading, it is documented in TLS v1.0 (rfc2246)

http://tools.ietf.org/html/rfc2246#section-6

                     Any protocol designed for use over TLS must be
   carefully designed to deal with all possible attacks against it.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 21 Sep 2011 03:42:22 +0200 (MEST)

> i.e. TLS session resume or full handshake, both will do).

Ooops -- what I forgot:

Your IMAP cleartext logon password travels  Client->Server and the
attackers EMail on download travels Server->Client.  Since TLS uses
distinct traffic encryption and mac keys for both directions,
there is no chosen plaintext or adaptive chosen plaintext attack
for the particular situation of IMAP Email download, I believe.

But that would also suggest that BEAST is not attacking the
Cookie from the Server response, but instead the cookie from a
client request.  (If the browser automatically inserts the cookie into
arbitrary requests issued by the attackers malware, then this would 
mean that a serious Cross-Site-Request-Forgery problem in the browser
is a prerequisite for the BEAST attack to succeed.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Tue, 20 Sep 2011 21:26:12 -0500

> You seem to be approaching the issue from the wrong end.

As if I was at fault.  Or as if saying any of this could undo what happened.

Did SSLv2, v3, TLS 1.0, say anything that would have caused others to
realize that it was not a good choice of technology for IMAP, or to
notice that JavaScript in browsers was a recipe for disaster?  RFC2246
doesn't say anything about this: section F outlines the threat model
and says nothing about carrying untrusted content, but that's hardly
dispositive.

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Tue, 20 Sep 2011 21:33:29 -0500

> is a prerequisite for the BEAST attack to succeed.

But such an attack would only need the cookie sent once 
client-to-server. A GET request which sends the secret cookie would work 
just fine. If there happened to be additional request(s) over that 
channel transmit the adaptive plaintext (constructed from the ciphertext 
block containing secret cookie data), would it actually be a requirement 
that they re-send the cookie then?

Even if there were CSRF restrictions on cookies, would they apply to GET 
and POST equally? If cookie restrictions applied to GET, how would 
https://google-analytics.com/ work?

Sorry if I sound nonsensically hypothetical. I'm still trying to figure 
out what I've promised not to say vs. what I already knew. :-)

- Marsh

---

From: Nico Williams <[email-masked]>
Date: Tue, 20 Sep 2011 21:41:09 -0500

> is a prerequisite for the BEAST attack to succeed.

It's almost certainly the case that BEAST works by adding an IMG
element to a page where one of its scripts can run, with the IMG
referring to a resource on the service that the attacker wants to
steal cookies to, with the script and the eavesdropper working to
attack the GET of the IMG src to extract any cookies from the GET
request.  At least that's how I imagine it to work.  So, yes, that
would be the client request that's getting attacked.

We'll find out soon enough.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 21 Sep 2011 05:01:45 +0200 (MEST)

Marsh Ray wrote:
> channel transmit the adaptive plaintext

That is a vital prerequisite.  The Javascript of the BEAST trojan
would have to be dribbling out SSL records based on the very same
TLS Connection status (and watch that encrypted network traffic
to learn the last Cipherblock in the SSL record that will be used
as IV to the next SSL record in SSLv3&TLSv1.0 in order to fabricate
the next guess for the plaintext (->adaptively chosen plaintext).

But in order for the attack to succeed so fast in guessing
(10 minutes for the PayPal cookie) I would expect that there needs
to be a small block size (3DES-EDE-CBC) plus a fairly low entropy
in that Cookie.   A sensible cookie would be base64-encoded and
contain at least 128-bit strong random (meaning up to 48 bits of
entropy per cipher block and 2-3 blocks to recover).  Much less guessing
if it uses an unsafe low-entropy cookie or a very inefficient encoding
(but more blocks to guess).

> (constructed from the ciphertext 

No, one cookie is sufficient if the connection does not abort during
the attack.  But spreading the attack over multiple successive or
parallel requests (one for each cipher block, each request with its own
encryption keys and encrypted cookie) and combinding the results should work.

> and POST equally?

Since the client needs to send a significant number of small SSL records
with stuff that will look like junk to the Server.  The server might be
more patiently with a (dribbling) POST than a GET in this respect.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 29 Sep 2011 15:44:31 +0200 (MEST)

> because it some software (an old MSIE IIRC).

Why using a EMPTY (just padding) SSL record?  That looks like an
obvious untested border case.

How about using an initial SSL record with one byte of real data
for SSLv3 and TLSv1.0 SSL with CBC cipher suites?

Since the (H)MAC is using a secret MAC key and directly following the
data (the CBC padding is at the end), there will be significant
unknown distortion in the resulting plaintext to make the BEAST
attack impractical, I assume.  And it could be done immediately
on the browser side, without having to wait for the Servers
to implement TLSv1.1.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 29 Sep 2011 15:51:13 +0200 (MEST)

> on the browser side, without having to wait for the Servers

But this fragmentation should be done ONLY on protected application
data SSL records.  Fragmenting SSL records with handshake messages
(e.g. on TLS renegotiation) is likely to cause significant interop
problems in the installed base. (Yes, I'm aware that fragmenting
handshake records is allowed by the spec, but a significant
number of implementations will break if you do).

-Martin

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Thu, 29 Sep 2011 15:55:49 +0200

> for SSLv3 and TLSv1.0 SSL with CBC cipher suites?

According to my testing, this breaks about as many websites,  
unfortunately, approximately 0.15% of tested websites.

There is some uncertainty in the numbers, as I have observed sites that  
has been reported as breaking still work with the patched versions, whil  
others doesn't work. At present I do not why this is happening.

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Martin Rex <[email-masked]>
Date: Thu, 29 Sep 2011 16:13:03 +0200 (MEST)

Yngve N. Pettersen wrote:
> > > empty (just padding) message before each app data message.
> > >
> > > because it [breaks] some software (an old MSIE IIRC).
> >

What exactly did you do?  did you fragment the client's
finished handshake message as well (which is the first protected
message on a TLS connnection) ?  As previously mentioned, I would
expect this to cause interop problems, whereas I have a slight
hope that fragmenting only application data might work.

-Martin

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Thu, 29 Sep 2011 16:34:29 +0200

> hope that fragmenting only application data might work.

The test only used a split record for application data, and was only  
performed if the server supported on of the CBC ciphersuites supported by  
the prober, and a successful HTTP request for / without split record had  
been sent earlier in the test.

Determining failure required detecting two successive failures that either  
did not return a response at all, or a 400+ error code that was not the  
same as was received in the baseline request. (200/300 was considered a  
success regardless )

Five different split policies were tested (0, 1, 2, blocksize-1, blocksize  
-2 bytes), each with or without having the blocks in the same TCP record.  
The above number was with the two records in the same TCP record (as that  
had a significantly lower failure rate).

The above numbers is the combined failure rate for servers that support  
AES, or only support 3DES. (AES is presumed to be selected by these  
servers).

I have previously seen HTTPS servers mishandle two HTTP requests in the  
same record (the second was ignored); my guess is that this is the same  
thing: An assumption that a single SSL/TLS Application record contain just  
a single, complete HTTPS request. My guess is that the responsible servers  
are front-ends, firewalls or similar, not servers like Apache with modSSL  
or IIS.

At least one server return "ET is not a recognized HTTP method",  
apparently having dropped the record with the "G" part of the request.

BTW: 0.045% failed all 5 of the tests, so I consider it likely that there  
is no split policy that will work for all servers.

-- 
Sincerely,
Yngve N. Pettersen

---

From: Martin Rex <[email-masked]>
Date: Thu, 29 Sep 2011 16:42:46 +0200 (MEST)

Thank you for the detailed and very helpful information!

I also believe that fragmenting application data is likely to break
brittle application design that silently assumes application data boundaries
(network read&writes, respectively SSL_read()&SSL_write()) will
be preserved.

So _not_ upsetting the peers TLS stack might not be a sufficient
precondition to make a mitigation work.  :-(

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Thu, 29 Sep 2011 21:09:45 +0300

> for SSLv3 and TLSv1.0 SSL with CBC cipher suites?

Interesting idea.
http://src.chromium.org/viewvc/chrome?view=rev&revision=97269