Tim Dierks | 10 Sep 18:41 2011

Rizzo claims implementation attach, should be interesting

Does anyone have any ideas what Rizzo may be announcing <at> 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
_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Peter Gutmann | 10 Sep 19:11 2011
Picon
Picon
Picon

Re: Rizzo claims implementation attach, should be interesting

Tim Dierks <tim <at> dierks.org> writes:

>Does anyone have any ideas what Rizzo may be announcing  <at>  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.
=JeffH | 12 Sep 19:45 2011

Re: Rizzo claims implementation attach, should be interesting

perhaps based on  similar attacks against the
predictable implicit IV in SSL 3.0 and TLS 1.0 described several years ago by
Greg Bard:

A CHALLENGING BUT FEASIBLE BLOCKWISE-ADAPTIVE
CHOSEN-PLAINTEXT ATTACK ON SSL
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5887&rep=rep1&type=pdf>

?

=JeffH
Martin Rex | 19 Sep 20:57 2011
Picon

Re: Rizzo claims implementation attach, should be interesting

Tim Dierks wrote:
> 
> Does anyone have any ideas what Rizzo may be announcing  <at>  ekoparty?
> 
> http://www.ekoparty.org/2011/juliano-rizzo.php
> 
> 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
Steingruebl, Andy | 20 Sep 01:42 2011

Re: Rizzo claims implementation attach, should be interesting

> -----Original Message-----
> From: tls-bounces <at> ietf.org [mailto:tls-bounces <at> ietf.org] On Behalf Of
> Martin Rex
> 
> Tim Dierks wrote:
> >
> > Does anyone have any ideas what Rizzo may be announcing  <at>  ekoparty?
> >
> > http://www.ekoparty.org/2011/juliano-rizzo.php
> >
> > 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

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.
Martin Rex | 20 Sep 02:53 2011
Picon

Re: Rizzo claims implementation attach, should be interesting

Steingruebl, Andy wrote:
> 
> Martin Rex wrote:
> > 
> > Tim Dierks wrote:
> > >
> > > Does anyone have any ideas what Rizzo may be announcing  <at>  ekoparty?
> > >
> > > http://www.ekoparty.org/2011/juliano-rizzo.php
> > >
> > > 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
> 
> 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.

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
Marsh Ray | 20 Sep 04:31 2011

Re: Rizzo claims implementation attach, should be interesting

On 09/19/2011 07:53 PM, 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.

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?

> Potential server-side mitigation of the problem:
>
>    - disable HTTP request pipelining (aka Connect: keep-alive)

Expensive.

>    - avoid CBC-based cipher suites (at least when SSLv3 or TLSv1.0
>      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
Eric Rescorla | 20 Sep 05:49 2011

Re: Rizzo claims implementation attach, should be interesting

On Mon, Sep 19, 2011 at 7:31 PM, Marsh Ray <marsh <at> extendedsubset.com> wrote:
> 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?

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
Eric Rescorla | 20 Sep 05:50 2011

Re: Rizzo claims implementation attach, should be interesting

On Mon, Sep 19, 2011 at 8:49 PM, Eric Rescorla <ekr <at> rtfm.com> wrote:
> On Mon, Sep 19, 2011 at 7:31 PM, Marsh Ray <marsh <at> extendedsubset.com> wrote:
>> 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?
>
> 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.

s/servers/clients and servers/

Best,
-Ekr
Martin Rex | 20 Sep 16:45 2011
Picon

Re: Rizzo claims implementation attach, should be interesting

Eric Rescorla wrote:
> 
> On Mon, Sep 19, 2011 at 7:31 PM, Marsh Ray <marsh <at> extendedsubset.com> wrote:
> > 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?
> 
> 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.

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
Marsh Ray | 20 Sep 17:13 2011

Re: Rizzo claims implementation attach, should be interesting

On 09/20/2011 09:45 AM, Martin Rex wrote:
>
> 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.

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.

> 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.

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
Yoav Nir | 20 Sep 06:12 2011
Picon

Re: Rizzo claims implementation attach, should be interesting


On Sep 20, 2011, at 5:31 AM, Marsh Ray wrote:

> On 09/19/2011 07:53 PM, Martin Rex wrote:
> 
> 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).

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

> 
> 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?

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.

> 
> 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.

A time like what?
Marsh Ray | 20 Sep 06:19 2011

Re: Rizzo claims implementation attach, should be interesting

On 09/19/2011 11:12 PM, Yoav Nir wrote:
>
> On Sep 20, 2011, at 5:31 AM, Marsh Ray 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
Yoav Nir | 20 Sep 07:24 2011
Picon

Re: Rizzo claims implementation attach, should be interesting


On Sep 20, 2011, at 7:19 AM, Marsh Ray wrote:

> On 09/19/2011 11:12 PM, Yoav Nir wrote:
>> 
>> On Sep 20, 2011, at 5:31 AM, Marsh Ray 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. :-)

Sorry. Reading it again, it's obvious. Guess we should switch all IETF mailing lists to lojban.
Martin Rex | 20 Sep 17:21 2011
Picon

Re: Rizzo claims implementation attach, should be interesting

Marsh Ray wrote:
> 
> 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.

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...

> 
> 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.

It does defend against man-in-the-middle 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.

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.

> 
> > Potential server-side mitigation of the problem:
> >
> >    - disable HTTP request pipelining (aka Connect: keep-alive)
> 
> Expensive.

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

> 
> >    - avoid CBC-based cipher suites (at least when SSLv3 or TLSv1.0
> >      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?

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
Eric Rescorla | 20 Sep 17:27 2011

Re: Rizzo claims implementation attach, should be interesting

On Tue, Sep 20, 2011 at 8:21 AM, Martin Rex <mrex <at> sap.com> wrote:
> Marsh Ray wrote:
>>
>> 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.
>
> 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...

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
Phillip Hallam-Baker | 20 Sep 22:04 2011
Picon

Re: Rizzo claims implementation attach, should be interesting



On Tue, Sep 20, 2011 at 11:21 AM, Martin Rex <mrex <at> sap.com> wrote:
Marsh Ray wrote:
> 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.

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.

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/

_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Nico Williams | 20 Sep 23:04 2011

Re: Rizzo claims implementation attach, should be interesting

On Tue, Sep 20, 2011 at 3:04 PM, Phillip Hallam-Baker <hallam <at> gmail.com> wrote:
> On Tue, Sep 20, 2011 at 11:21 AM, Martin Rex <mrex <at> sap.com> wrote:
>> 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.

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.

> 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.

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.

> 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?

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
--
Martin Rex | 20 Sep 23:31 2011
Picon

Re: Rizzo claims implementation attach, should be interesting

Nico Williams wrote:
> 
> On Tue, Sep 20, 2011 at 3:04 PM, Phillip Hallam-Baker <hallam <at> gmail.com> wrote:
> > On Tue, Sep 20, 2011 at 11:21 AM, Martin Rex <mrex <at> sap.com> wrote:
> >> 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.
> 
> 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?

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

> 
> 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.

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.

> 
> > 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.
> 
> 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.

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).

> 
> 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 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).

> 
> 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.

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
Marsh Ray | 20 Sep 23:47 2011

Re: Rizzo claims implementation attach, should be interesting

On 09/20/2011 04:31 PM, Martin Rex wrote:
>
> 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.

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.

> 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.

Yeah CBC sucks, especially with predictable IVs.

It's a weakness.

> 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).

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
Martin Rex | 21 Sep 00:58 2011
Picon

Re: Rizzo claims implementation attach, should be interesting

Marsh Ray wrote:
> 
> Yeah CBC sucks, especially with predictable IVs.
> 
> It's a weakness.

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.

> 
> > 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).
> 
> 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"?

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.

> 
> 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". :-)

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
Martin Rex | 20 Sep 23:53 2011
Picon

Re: Rizzo claims implementation attach, should be interesting

Martin Rex wrote:
> 
> Nico Williams wrote:
> > 
> > On Tue, Sep 20, 2011 at 3:04 PM, Phillip Hallam-Baker <hallam <at> gmail.com> wrote:
> > > On Tue, Sep 20, 2011 at 11:21 AM, Martin Rex <mrex <at> sap.com> wrote:
> > >> 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.
> > 
> > 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?
> 
> It is a design limit that should be obvious to the conscious reader
> with background knowledge about cryptography.
> 
> 
> > 
> > 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.
> 
> 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.

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
Nico Williams | 21 Sep 01:33 2011

Re: Rizzo claims implementation attach, should be interesting

On Tue, Sep 20, 2011 at 4:31 PM, Martin Rex <mrex <at> sap.com> wrote:
> Nico Williams wrote:
>> On Tue, Sep 20, 2011 at 3:04 PM, Phillip Hallam-Baker <hallam <at> gmail.com> wrote:
>> > On Tue, Sep 20, 2011 at 11:21 AM, Martin Rex <mrex <at> sap.com> wrote:
>> >> 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.
>>
>> 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?
>
> It is a design limit that should be obvious to the conscious reader
> 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.

>> 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.
>
> 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.

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

> But when you start multiplexing adaptively chosen plaintext from
> 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
--
_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Martin Rex | 21 Sep 02:10 2011
Picon

Re: Rizzo claims implementation attach, should be interesting

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?
> >
> > It is a design limit that should be obvious to the conscious reader
> > 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.

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.

> 
> > But when you start multiplexing adaptively chosen plaintext from
> > 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.

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
Nico Williams | 21 Sep 04:26 2011

Re: Rizzo claims implementation attach, should be interesting

On Tue, Sep 20, 2011 at 7:10 PM, Martin Rex <mrex <at> sap.com> wrote:
> Nico Williams wrote:
>> Martin Rex wrote:
>> Undocumented design limitations are not obvious, even if in retrospect
>> they should have been.
>
> 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
--
Martin Rex | 21 Sep 03:19 2011
Picon

Re: Rizzo claims implementation attach, should be interesting

Nico Williams wrote:
> 
> 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?

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
Geoffrey Keating | 21 Sep 00:35 2011

Re: Rizzo claims implementation attach, should be interesting

Martin Rex <mrex <at> sap.com> writes:

> 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.

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).
Martin Rex | 21 Sep 01:14 2011
Picon

Re: Rizzo claims implementation attach, should be interesting

Geoffrey Keating wrote:
> 
> Martin Rex <mrex <at> sap.com> writes:
> 
> > 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.
> 
> 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).

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
Martin Rex | 21 Sep 03:42 2011
Picon

Re: Rizzo claims implementation attach, should be interesting

Martin Rex wrote:
> 
> Geoffrey Keating wrote:
> > 
> > Martin Rex <mrex <at> sap.com> writes:
> > 
> > > 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.
> > 
> > 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).
>  
> 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).

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
Marsh Ray | 21 Sep 04:33 2011

Re: Rizzo claims implementation attach, should be interesting

On 09/20/2011 08:42 PM, Martin Rex wrote:
>
> 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.

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
Martin Rex | 21 Sep 05:01 2011
Picon

Re: Rizzo claims implementation attach, should be interesting

Marsh Ray wrote:
> 
> On 09/20/2011 08:42 PM, Martin Rex wrote:
> >
> > 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.
> 
> 
> 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

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 
> block containing secret cookie data), would it actually be a requirement 
> that they re-send the cookie then?

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.

> 
> Even if there were CSRF restrictions on cookies, would they apply to GET 
> 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
Nico Williams | 21 Sep 04:41 2011

Re: Rizzo claims implementation attach, should be interesting

On Tue, Sep 20, 2011 at 8:42 PM, Martin Rex <mrex <at> sap.com> wrote:
> 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.

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
--
_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Martin Rex | 29 Sep 15:44 2011
Picon

Re: Rizzo claims implementation attach, should be interesting

Marsh Ray wrote:
> 
> >    - avoid CBC-based cipher suites (at least when SSLv3 or TLSv1.0
> >      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).

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
Martin Rex | 29 Sep 15:51 2011
Picon

Re: Rizzo claims implementation attach, should be interesting

Martin Rex wrote:
> 
> Marsh Ray wrote:
> > 
> > >    - avoid CBC-based cipher suites (at least when SSLv3 or TLSv1.0
> > >      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).
> 
> 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.

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
Yngve N. Pettersen | 29 Sep 15:55 2011
Picon

Re: Rizzo claims implementation attach, should be interesting

On Thu, 29 Sep 2011 15:44:31 +0200, Martin Rex <mrex <at> sap.com> wrote:

> Marsh Ray wrote:
>>
>> >    - avoid CBC-based cipher suites (at least when SSLv3 or TLSv1.0
>> >      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).
>
> 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?

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: yngve <at> opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************
Martin Rex | 29 Sep 16:13 2011
Picon

Re: Rizzo claims implementation attach, should be interesting

Yngve N. Pettersen wrote:
> 
> Martin Rex wrote:
> 
> > Marsh Ray wrote:
> > >
> > > I believe there was a mitigation put in place by OpenSSL: sending an
> > > empty (just padding) message before each app data message.
> > >
> > > I read somewhere that this mitigation was off by default in OpenSSL
> > > because it [breaks] 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?
> 
> According to my testing, this breaks about as many websites,  
> unfortunately, approximately 0.15% of tested websites.

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
Yngve N. Pettersen | 29 Sep 16:34 2011
Picon

Re: Rizzo claims implementation attach, should be interesting

On Thu, 29 Sep 2011 16:13:03 +0200, Martin Rex <mrex <at> sap.com> wrote:

> Yngve N. Pettersen wrote:
>>
>> Martin Rex wrote:
>>
>> > Marsh Ray wrote:
>> > >
>> > > I believe there was a mitigation put in place by OpenSSL: sending an
>> > > empty (just padding) message before each app data message.
>> > >
>> > > I read somewhere that this mitigation was off by default in OpenSSL
>> > > because it [breaks] 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?
>>
>> According to my testing, this breaks about as many websites,
>> unfortunately, approximately 0.15% of tested websites.
>
> 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.

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

********************************************************************
Senior Developer                     Email: yngve <at> opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************
Martin Rex | 29 Sep 16:42 2011
Picon

Re: Rizzo claims implementation attach, should be interesting

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

Yngve N. Pettersen wrote:
> 
> 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.
Yoav Nir | 29 Sep 20:09 2011
Picon

Re: Rizzo claims implementation attach, should be interesting


On Sep 29, 2011, at 4:44 PM, Martin Rex wrote:

>> 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).
> 
> 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?

Interesting idea.
http://src.chromium.org/viewvc/chrome?view=rev&revision=97269
=JeffH | 21 Sep 01:31 2011

Re: Rizzo claims implementation attach, should be interesting

Martin Rex <mrex <at> sap.com> noted..
 >
 > 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.

uh, yes, web browsers are full of such issues, some by accident, some (more or 
less) by design.This provides a high-level & very brief survey & bibliography 
of the landscape..

The Need for a Coherent Web Security Policy Framework
<http://kingsmountain.com/doc/HodgesSteingruebl-NeedCoherentWebSecurityPolicyFramework-2010.pdf>

See also..

Browser Security Handbook
https://code.google.com/p/browsersec/wiki/Main

=JeffH
David Wagner | 23 Sep 20:51 2011
Picon

Re: Rizzo claims implementation attach, should be interesting

I've been reading the discussion about this attack.  Of course, until
we see a full description of BEAST, it's hard to draw firm conclusions,
but I want to suggest a slightly different perspective on some of the
views I see mentioned here.

I've seen the claim made that ~"it is inherently unsafe to mix trusted
and untrusted content over the same encrypted channel, you should never
do that, crypto protocols aren't intended to be secure against that"~.
I do not think this is a fruitful or sensible way to think about things.

Modern crypto protocols do aim to make it safe to mix trusted and
untrusted content over the same channel.  They aim to be secure against
chosen-plaintext attack; and the notion of chosen-plaintext attacks is
motivated exactly by ensuring it is safe to mix trusted and untrusted
data over the same channel.  The designers of SSL and TLS 1.0 presumably
intended for SSL to be secure against chosen-plaintext attacks, but we've
sinced learned that there is a subtle flaw that enables a successful
chosen-plaintext attack.  It is a surprise that they fell short of this
natural goal and are vulnerable to chosen-plaintext attack (by the way,
no need to bring up blockwise-adaptive attacks; blockwise-adaptivity is
not needed).  TLS 1.1 introduces revisions to fix this problem, and as
far as we know, TLS 1.1 is secure against chosen-plaintext attack.

The conventional wisdom until now has been that, while there are
known chosen-plaintext attacks on TLS 1.0, they are not very serious
in practice.  As a result, there has not been much pressure to move to
TLS 1.1.  It may be time to reconsider that conventional wisdom.

I don't think it makes sense to advocate "you should never send both
trusted and untrusted content over the same crypto channel"; that advice
leads to absurd results.  Often dynamic web pages includes both trusted
and untrusted content; are you going to advocate that no dynamic web
page should sent over TLS?  In my view, TLS had darn well better be
secure in that threat model, and as far as we know, TLS 1.1 is.

I've also seen claims on this list that ~"CBC mode is inherently
insecure and should never be used"~.  I think that's a little too broad.
The problem with TLS 1.0 is not that it uses CBC mode and CBC mode
is inherently insecure.  Rather, the problem is that TLS 1.0 uses a
special variant of CBC mode, one which turns out to be insecure against
chosen-plaintext attack.  In particular, TLS 1.0 uses "ciphertext block
chaining", where the last ciphertext block is used as the next IV.
This way of choosing the IV enables chosen-plaintext attacks.

It is worth pointing out that the crypto-theory community has proven that,
if CBC mode is used properly, it is secure against chosen-plaintext
attacks.  However, those proofs only apply to the standard form of
CBC mode, where the IV is chosen randomly.  The proofs do not apply to
TLS 1.0's "ciphertext block chaining", and in fact, "ciphertext block
chaining" is not secure: it is not IND-CPA secure.

As long as you use CBC mode securely, these problems go away.  TLS 1.1
does use a secure form of CBC mode.  So I don't think it is accurate to
suggest that CBC mode is necessarily insecure.

In summary, I'd recommend: don't throw out the baby with the bathwater.
We don't need to throw out CBC mode; TLS 1.1's use of CBC mode is fine.
There's nothing wrong with sending both trusted and untrusted content over
the same channel, as long as the crypto protocol is designed properly; and
as best as we know, TLS 1.1 is fine for that.

References for further reading:

See Wei Dai's 2002 attacks on SSH and Bodo Moeller's extension of them
to SSL and TLS 1.0:
  http://osdir.com/ml/ietf.secsh/2002-02/msg00049.html
  http://www.openssl.org/~bodo/tls-cbc.txt
Those messages were clear that the implication of their attack is that
SSL is not secure against chosen-plaintext attack, and the key enabler
for their attack is that SSL's use of CBC mode chooses IVs unsafely.
See also Greg Bard's paper, which extends those early observations and
gave an early warning about the risks to SSL and TLS 1.0:
  http://eprint.iacr.org/2006/136
Martin Rex | 23 Sep 22:02 2011
Picon

Re: Rizzo claims implementation attach, should be interesting

David Wagner wrote:
> 
> I've seen the claim made that ~"it is inherently unsafe to mix trusted
> and untrusted content over the same encrypted channel, you should never
> do that, crypto protocols aren't intended to be secure against that"~.

That is not exactly what I wrote or intended to say.

What I said is that SSLv3&TLSv1.0 were clearly and obviously
_NEVER_ designed to protect from adaptive chosen plaintext
attacks when you multiplex confidential information and
attacker-supplied chosen plaintext and have them encrypted
under the same TLS connection state.

I agree that it would be valuable if TLS provided such protection,
because folks on top of TLS would prefer if they could remain ignorant
about any consequence their usage might have on the resulting security.

>
> I do not think this is a fruitful or sensible way to think about things.

As it turns out, as unpleasant as it may be, that is the only sensible
way to approach the use of TLS.

   http://tools.ietf.org/html/rfc5246#page-16

   Any protocol designed for use over TLS must be carefully designed to
   deal with all possible attacks against it.  As a practical matter,
   this means that the protocol designer must be aware of what security
   properties TLS does and does not provide and cannot safely rely on
   the latter.

> 
> Modern crypto protocols do aim to make it safe to mix trusted and
> untrusted content over the same channel.

What exactly do you want to say by that?

Does this mean that TLS is not modern, because it obviously never
had a property that its consumers silently relied on?

>
> They aim to be secure against chosen-plaintext attack;
> and the notion of chosen-plaintext attacks is motivated exactly by
> ensuring it is safe to mix trusted and untrusted data over the
> same channel.

The cbc-based cipher suies of SSLv3&TLSv1.0 *are* as secure
against chosen plaintext attacks as humanely possible.

But the specific usage scenario where the application caller of
TLS provides to the attacker a feedback loop plus SSL record creation
capabilities for an established TLS connection is what subverts
the security properties of SSLv3&TLSv1.0 for the cbc-ciphersuites.

>
> The designers of SSL and TLS 1.0 presumably intended for SSL to be
> secure against chosen-plaintext attacks, but we've sinced learned
> that there is a subtle flaw that enables a successful
> chosen-plaintext attack.

You're confusing things.  SSLv3&TLSv1.0 are perfectly OK, any flaw
is entirely in the protocols on top of TLS being ignorant about
the attack facilities they open up.  It is very essential to
understand this difference.

the explicit random IVs of TLSv1.1 make the problem *much* harder
to exploit, but the root cause of the problem is in the application
and still present: letting an attacker perform a chosen plaintext attack.

 
>
> It is a surprise that they fell short of this natural goal and are
> vulnerable to chosen-plaintext attack

It may be a surprise to you, but as the TLS specification very clearly
and explicitly states, it MUST NOT be a surprise to any designer of
protocol that run on top of TLS.

>
> TLS 1.1 introduces revisions to fix this problem, and as
> far as we know, TLS 1.1 is secure against chosen-plaintext attack.

No, TLSv1.1 does *NOT* actually contain a fix!
TLSv1.1 contains _only_ a mitigation by imposing a distortion on 
the "oracle" (equal to the block size of the underlying block cipher),

This mitigation should provide a security margin that is sufficient
to stop those attacks that have been demonstrated, but the underlying
problem still exists.

> 
> I don't think it makes sense to advocate "you should never send both
> trusted and untrusted content over the same crypto channel"; that advice
> leads to absurd results.  Often dynamic web pages includes both trusted
> and untrusted content; are you going to advocate that no dynamic web
> page should sent over TLS?  In my view, TLS had darn well better be
> secure in that threat model, and as far as we know, TLS 1.1 is.

You're missing the point.  The protocol design MUST take into account
the side effects of mixing content from trusted and untrusted sources
and have it encrypted under the same encryption keys.  What is of
particular interest is, whether a protocol provides to the attacker
a facility for automated guessing and how many attempts it allows
the attacker to make.

The security of a 4-digit PIN for an ATM card or for a mobile phone
GSM SIM card is ridiculously small.  But when the "oracle" only
accepts 3 "guesses" and then locks the card, there still is
sufficient "security margin" for it to offer some amount of
protection.

Automated online usage scenarios and low-entropy secrets
do not go well together.  And I would not be surprised if the
issue with PayPal was primarily due to a cookie with a
ridiculously low entropy, rather than a serious weakness in SSL.

> 
> I've also seen claims on this list that ~"CBC mode is inherently
> insecure and should never be used"~.  I think that's a little too broad.

I'm in full Agreement!

>
> The problem with TLS 1.0 is not that it uses CBC mode and CBC mode
> is inherently insecure.  Rather, the problem is that TLS 1.0 uses a
> special variant of CBC mode, one which turns out to be insecure against
> chosen-plaintext attack.  In particular, TLS 1.0 uses "ciphertext block
> chaining", where the last ciphertext block is used as the next IV.
> This way of choosing the IV enables chosen-plaintext attacks.

Actually, letting the attacker know the IV that will be used for
his next plaintext, prior to him choosing that plaintext, is what
creates the problem.  It removes the "distortion" that CBC
intends to add for each first crypto block of an SSL record
(except the first one) for SSLv3&TLSv1.0.  

> 
> It is worth pointing out that the crypto-theory community has proven that,
> if CBC mode is used properly, it is secure against chosen-plaintext
> attacks.  However, those proofs only apply to the standard form of
> CBC mode, where the IV is chosen randomly.

Again, you're missing the point.  The IVs in SSLv3&TLSv1.0 _are_
random in exactly the fashion that CBC is designed to work.
The problem isn't the randomness, but that the first IV of
each new SSL record is _predictable_ by the attacker.

For TLS, processing is normally done in quantities of
SSL records, so creating a single new random IV for the
start of the SSL record is sufficient.

Other environments might be (ab-)using CBC in a directly-streaming
(i.e. data is sent as soon as the cipher block is full), and
such a usage scenario would need a random IV for EVERY cipher block
(i.e. it must not use CBC at all).

> 
> In summary, I'd recommend: don't throw out the baby with the bathwater.
> We don't need to throw out CBC mode; TLS 1.1's use of CBC mode is fine.
> There's nothing wrong with sending both trusted and untrusted content over
> the same channel, as long as the crypto protocol is designed properly; and
> as best as we know, TLS 1.1 is fine for that.

I do not feel comfortable with this assertion, because it is technically
untrue, the underlying problem remains.  Rather, I would like to
see a quantification of the resulting security margin that this
distortion provides.

(something like "if your ciphers block size is X, you must change your
 crypto keys every Y MB/GB)" to maintain an adequate security margin.")

-Martin
Eric Rescorla | 23 Sep 22:17 2011

Re: Rizzo claims implementation attach, should be interesting

On Fri, Sep 23, 2011 at 1:02 PM, Martin Rex <mrex <at> sap.com> wrote:
>  Again, you're missing the point.  The IVs in SSLv3&TLSv1.0 _are_
> random in exactly the fashion that CBC is designed to work.
> The problem isn't the randomness, but that the first IV of
> each new SSL record is _predictable_ by the attacker.
>
> For TLS, processing is normally done in quantities of
> SSL records, so creating a single new random IV for the
> start of the SSL record is sufficient.
>
> Other environments might be (ab-)using CBC in a directly-streaming
> (i.e. data is sent as soon as the cipher block is full), and
> such a usage scenario would need a random IV for EVERY cipher block
> (i.e. it must not use CBC at all).

Note that RFC4346 specifically prohibits that behavior in S 6.2.3.2:

   Note: With block ciphers in CBC mode (Cipher Block Chaining), it is
         critical that the entire plaintext of the record be known
         before any ciphertext is transmitted.  Otherwise, it is
         possible for the attacker to mount the attack described in
         [CBCATT].

This restriction was added precisely to counter the attack you describe.

-Ekr

Gmane