Subject: [TLS] Deployment data

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Nov 2009 02:23:53 +0200

I know there has been a bunch of discussion about the prevalance of
SSLv3-only stacks. As one data point, Lee, Malkin, and Nahum's 2007
IMC paper (http://www.imconf.net/imc-2007/papers/imc130.pdf) indicates
98+% deployment of TLS on Web servers. 

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Mon, 16 Nov 2009 01:48:25 +0100 (MET)

> 98+% deployment of TLS on Web servers. 

So?  Servers are in much safer position to support newer
TLS protocol versions, because they get to choose.

I'm complaining on the problem we might be creating for the clients,
those Servers which _are_ going to be fixed, can implement whatever
solution we come up with (provided the client signals through ClientHello).

Clients bear the burden to make safe assumptions about what is going
to be interoperable with the server, and safe protocol features
are the reason why the amount of traffic on the internet that is
still using prtocol version 0x03,0x00 (aka SSLv3) is _MUCH_ larger
as the amount of public Web Servers that supports TLS.

MS IIS6 on WinXP pro 64-bit likely supports TLS 1.0 by default.
MSIE6 on WinXP pro 64-bit offers only SSLv3 by default.

What this statistics likely does not cover is Intranet Servers
that offer TLS.  Some of these run vital applications for companies.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Sun, 15 Nov 2009 18:54:08 -0600

> that offer TLS.  Some of these run vital applications for companies.

It bears repeating that SSL/TLS is much much more than https.

What worries me are deployments like [all the parking meters and traffic
lights in <major city>].

Or look at all the little plastic boxes returned from searches like this:
http://search.hp.com/query.html?qt=ssl/tls

- Marsh

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Nov 2009 07:49:51 +0200

At Mon, 16 Nov 2009 01:48:25 +0100 (MET),
> TLS protocol versions, because they get to choose.
 
I don't know what "So" means. The question of what is
safe for clients to do depends on what servers support.
I'm offering data towards that question.

> as the amount of public Web Servers that supports TLS.

I'd be interested in seeing the data that supports the claim that
it is much larger. Can you provide references please?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Nov 2009 07:51:01 +0200

At Sun, 15 Nov 2009 18:54:08 -0600,
> It bears repeating that SSL/TLS is much much more than https.

Of course it is. I'd certainly be interested in seeing whatever data
you can provide.

> http://search.hp.com/query.html?qt=ssl/tls

And what fraction of those devices will patch at all?

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Mon, 16 Nov 2009 17:53:01 +0100 (MET)

> And what fraction of those devices will patch at all?

And this is why it is very important that we can signal on ALL
future TLS connections established by a client, so that a MITM
can not FORCE an updated, but backwards compatible client to
renegotiate insecurely with an updated, but backwards compatible server.
This is what the TLS extensions RI currently fails completely.

About the deployment data:

I have just made a couple of checks and here are my results:

I checked the following Microsoft platforms:
  MSIE6 on WinXP
  MSIE7 on WinXP
  MSIE6 on WinXPpro 64-bit (equal Windows 2003 64-bit)
  MSIE8 on WinXPpro 64-bit (equal Windows 2003 64-bit)
  MSIE7 on Windows2008sp1 Server 

On all of these, SSLv3 protocol was configured in the internet options,
and when SSLv3 is configured, none of the above MSIE Browsers would
send a TLS extension in ClientHello.

When I disabled SSLv3 support in the Intenet Options, only
MSIE7 on Vista started sending TLS extensions,
neither of MSIE6/7/8 on XP and XPpro64/Windows2003 sends extensions.

I wasn't able to get Firefox 3.0.15 sending TLS extension,
even when switching off SSLv3 support.

I noticed that Firefox 3.5.5 sends TLS extensions on the first connect,
and will fallback automatically to a SSLv3-with-SSLv2 ClientHello Handshake
if the Server rejects the request.

So I'm wondering about the following:

Is Microsoft really eager to ship a hotfix for WinXP and Win2K3 that
makes all MSIE-Version send a TLS extension?  It seems that such
behaviour is completely untested in the majority of installations
of Microsoft software.

And does Microsoft really want to backport TLS extensions into
WinXP and Win2K3 so badly _AND_ right now -- although we could
easily devise a _MUCH_ smaller fix entirely without TLS extensions.

What the TLS WG ought to provide is a fix that runs smoothly with
all of the backwards-compatible extension-less handshakes so
that it can be enabled for whatever backwards compatibility
requirements that customers might have.

As I said, it is extremely valuable to get the renegotiation protection
IMMEDIATELY for all modes of operation with extremely little probability
of breaking anything as soon as the client and the server are patched.

There WILL be a transistion period, and the TLS extension RI will
cause all updated clients with an automatic fallback or with
interop requirements for old components vulnerable to the problem.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Nov 2009 19:12:45 +0200

At Mon, 16 Nov 2009 17:53:01 +0100 (MET),
> This is what the TLS extensions RI currently fails completely.

I don't agree with this claim.

A client which sends RI only on renegotiation and aborts the
connection if it does not receive RI in return does not 
have this problem. 

> easily devise a _MUCH_ smaller fix entirely without TLS extensions.

Again, I think this _MUCH_ smaller claim is unconvincing.  The
implementation effort is trivial in either case. In fact, arguably RI
is a smaller fix since it uses standard and well understood TLS code
paths, whereas the fix you propose involves somehow injecting data
into the handshake hashes in the middle.

> interop requirements for old components vulnerable to the problem.

Again, I don't agree with this claim if you only send the extension on
rehandshake.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Mon, 16 Nov 2009 19:03:19 +0100 (MET)

> > > And what fraction of those devices will patch at all?

And what is your suggestion?

Enforce the client policy to not fallback to extension-less ClientHello
and BRICK all those devices?

Or suggest Browsers and TLS client to allow or implement an app-level
fallback to extension-less Client-Hello, but keep a list of servers
for which to allow this, because you want to deny them any
protection for that communication?

> connection if it does not receive RI in return does not 

A client that is in backwards compatible mode or automatic fallback
to extensionless ClientHello will continue to be susceptible to
a MITM with a server that is in backwards compatible mode.

That is a REAL problem, and it will persist through the transition/migration
period.  extension-less, it can be entirely avoided.

The RI for renegotiation is a completely unnecessary waste.  Both
peers have all the data they need.

> into the handshake hashes in the middle.

Come on!  I thought you looked at OpenSSL and realized how trivial
it would be to add the verify_data into the handshake hashes.
Adding them as a TLS extensions into the handshake messages
requires significantly more code changes.

I just looked at OpenSSL 0.9.8g sources, and what I see does not look
quite like rocket science:

Server Side: s3_srvr.c:ssl3_send_server_hello()

	return(ssl3_do_write(s,SSL3_RT_HANDSHAKE));

would have to be change to something like:

        ret = ssl3_do_write(s,SSL3_RT_HANDSHAKE);
        if ( ret>0 && s->s3->renegotiate ) {
	    /* add previous verify_data of client.finished */
	    ssl3_finish_mac(s,s->s3->peer_finished_md,
                              s->s3->peer_finished_md_len);
	    /* add previous verify_data of server.finished */
	    ssl3_finish_mac(s,s->s3->finished_md,
                              s->s3->finished_md_len);
	}

(you will need to copy the finished_md fields to the connection state anyway).

> Again, I don't agree with this claim if you only send the extension on

On the renegotiation handshake the TLS extension is pure waste.

And changing only the renegotiation handshake doesn't cover the fallback
scenarios and doesn't let the client figure out the server's patch
status on initial connect (and neither can the firewall/intrusion detection
systems do any checks).

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 16 Nov 2009 10:28:45 -0800

> connection if it does not receive RI in return does not 

You do not appear to fully understand the attack.  It is completely
unnecessary for a client to abort a renegotiation.  There is no
possible man-in-the-middle.  This is guaranteed when the client has
verified the server's certificate in its initial handshake.
Otherwise ALL of TLS would be broken.

Now, it is necessary for a client to use whatever-the-fix-is when
renegotiating so that the *server* can check for insecure
renegotiation, but this is purely mechanical to the client.

Mike

---

From: Martin Rex <[email-masked]>
Date: Mon, 16 Nov 2009 19:44:35 +0100 (MET)

> renegotiation, but this is purely mechanical to the client.

I really would appreciate an extension-less negotiation through
ClientHello+ServerHello where the Server can confirm to the client
that it will do the modified finished calculation on renegotiations,
so that the client knows that its initial handshake can not be proxied
into the reneogotiation of a server (will fail the finished mac if done). 

-Martin

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 16 Nov 2009 10:49:31 -0800

> connection if it does not receive RI in return does not

If *both* the client and the server are updated but backwards  
compatible, then they need a signal that the client can send in its  
initial handshakes.  If the server ever sees this signal in a  
renegotiation handshake, this indicates a MitM attack -- which,  
without the signal, could be successful.  The signal, thus, indicates  
to the server that treating the current handshake as a backwards- 
compatible renegotiation handshake is not acceptable.

If we don't intend to allow updated servers to perform backwards- 
compatible renegotiation handshakes at all, we don't need this  
signal.  I think this would make sense because we want to push forward  
to a point where there are only servers around that either

(a) have been updated, or
(b) don't use renegotiation in the first place.

However, adding the signal seems easy enough: We can use a pseudo- 
ciphersuite value that would be listed by updated clients in all  
initial handshakes.  (The specification should point out that this  
pseudo-ciphersuite must be listed also in handshakes that intend to  
resume a session, where some clients might be using an abbreviated  
ciphersuite list given that they already know one common ciphersuite.)

Bodo

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 16 Nov 2009 18:56:01 +0000

Martin Rex wrote:
>> March Ray wrote:

To solve this problem, a patched RI client simply must not renegotiate on a
connection that is in fallback mode.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

---

From: Nasko Oskov <[email-masked]>
Date: Mon, 16 Nov 2009 18:56:25 +0000

>that it will do the modified finished calculation on renegotiations, so that the client knows that its initial handshake can not be proxied into the reneogotiation of a server (will fail the finished mac if done). 

I consider signaling on both directions vital. The TLS stack should not dictate application policy whether secure/insecure renegotiation is used. This is application level logic, though default behavior will be present. The default could go out with allowing insecure renegos to allow for interop at the time of release, but can be tightened up once the fix has gained enough traction.
If we cannot provide signaling in both directions, then apps need to do fallback, which for non-browers apps is a pretty big breaking change.

Nasko

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 16 Nov 2009 10:58:06 -0800

On Nov 16, 2009, at 10:28 AM, Michael D'Errico wrote:

>> connection if it does not receive RI in return does not have this  
>> problem.
>

It is NOT guaranteed, however, if the initial handshake was for an  
anonymous cipersuite, with a renegotiation handshake taking place once  
the client and server think they should introduce to each other.  This  
is a perfectly valid TLS use case.

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 16 Nov 2009 11:01:38 -0800

> connection that is in fallback mode.

This solves the problem only if we don't allow updated servers to  
perform backwards-compatible renegotiation handshakes.  If we do allow  
this, we have to worry about a MitM attacker relaying the client's  
initial handshake to the server as a fallback-mode renegotiation  
handshake.

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 16 Nov 2009 11:17:12 -0800

> into the reneogotiation of a server (will fail the finished mac if  

I don't see why we'd want this to be extension-less for this purpose.

If the client wants the initial handshake to fail if the server  
doesn't confirm that it is using updated renegotiation logic, this  
means that we want to achieve interoperability only if both the client  
and the server have been updated.

Why not specify that this update will have to include minimal  
extension support (where the client uses a single fixed extension and  
checks whether the server confirms it, and the server looks for this  
single fixed extension in the client_hello_extension_list and sends  
the fixed extension back if appropriate), even for SSL 3.0?  If client  
do such handshakes with servers that haven't been updated and choke on  
extensions, these handshakes will fail -- which is just as expected if  
the client only wants to talk to those servers for which it has  
positive confirmation that they've been updated.

Bodo

---

From: Martin Rex <[email-masked]>
Date: Mon, 16 Nov 2009 20:44:08 +0100 (MET)

> I don't see why we'd want this to be extension-less for this purpose.

So that the client can signal it on EVERY SSLv3 or TLS handshake
that it can be configured to do.  Currently, Browsers have either
automatic fallbacks to extension-less ClientHellos or can be
configured for SSLv3 (which is the default for MSIE) in a
comparable fashion where they send only extension-less ClientHellos,
simply because TLS extensions are known to upset servers.

> and the server have been updated.

An SSLv3 or TLSv1.0 Server that has neither TLS extensions nor
renegotition implemented must add an awful lot of code in order
to do signaling through TLS extensions.  And interop testing that
code isn't exactly easy (because the client may send the
extension anywhere among other extensions).

Servers will usually already have code to parse and search the
list of ciphersuite IDs sent in the ClientHello, so is likely
significantly less new code and less testing necessary.

> the fixed extension back if appropriate), even for SSL 3.0?

I really do _not_ think it is a good idea to make TLS extensions
retroactively mandatory to implement (especially right now), since
TLS extensions have been a purely optional feature for the installed base
of TLSv1.1 and didn't even exist when TLSv1.0 was finalized, and
the TLS WG has been well aware about significant interop problems
with TLS extensions for at least 3 years
(draft-pettersen-tls-interop-experience-00.txt)
and didn't do all that much to change this in the meantime.

>
> If client do such handshakes with servers that haven't been updated
> and choke on extensions, these handshakes will fail -- which is just
> as expected if the client only wants to talk to those servers for
> which it has positive confirmation that they've been updated.

The IETF has permitted a 13-year growth of an installed base that
implements the existing protocols SSLv3->TLSv1.2 with that shortcoming.

It is no longer at the discretion to TLS alone to discontinue the
interoperability with the installed base from one day to the next.

This is a decision that we must leave at the discretion of the
consumers of the TLS technology.

I think we should really try hard to make the transistion from
the installed base to patched as simple and smooth as possible,
allow them to decide individually when to break interop,
provide the highest possible security for all existing usage
scenarios.

SSLv3 may have not originated in the IETF (the spec document, however,
was under discussion in the IETF).  But TLS set out to be clearly
interoperable with SSLv3, so we can not simply pull the plug and
leave them in misery -- in particular since we are able to devise
a patch that is simpler than a TLS extension and will fit
equally well across all protocol versions of TLS including SSLv3.

-Martin

---

From: David-Sarah Hopwood <[email-masked]>
Date: Mon, 16 Nov 2009 19:47:31 +0000

Bodo Moeller wrote:
>> To solve this problem, a patched RI client simply must not renegotiate
>> on a connection that is in fallback mode.
> 
> perform backwards-compatible renegotiation handshakes.

Right. I thought there was concensus on not allowing that?

If patched servers can perform backwards-compatible renegotiation
handshakes, then the attack is not fixed until *both* the client and
server on a given connection are patched.

If this is not allowed, OTOH, then:

 - the original attack (where the server sees the renegotiation) can be
   prevented by patching only the server;

 - the variant where the client sees the renegotiation (applicable
   only when the client fails to check the server certificate and
   client certs are used) can be prevented by patching only the client.

Whether both or only one peer needs to be patched in order to protect
a given connection, makes a very big difference to the expected time
until almost all connections are protected.

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 16 Nov 2009 11:53:31 -0800

> simply because TLS extensions are known to upset servers.

Sure.  We want an extension-free way for clients to signal to servers  
that they support updated renegotiation.  (We want this, that is, if  
we want to allow updated servers to continue to support legacy  
renegotiation for old clients.)

However, for clients that want confirmation from the server that it's  
an updated server (because otherwise they wouldn't want to talk to it,  
suspecting it may support legacy renegotiation and thus be  
vulnerable), why would *this* have to be done in an extension-free way?

The server-side code changes to tolerate and ignore most extensions  
(which is desirable anyway!) and to scan through them looking for a  
specific fixed extension shouldn''t really be too complicated.

Bodo

---

From: Marsh Ray <[email-masked]>
Date: Mon, 16 Nov 2009 14:00:35 -0600

> server on a given connection are patched.

Unless this is allowed, servers cannot be patched before clients. There
are likely more clients with less centralized administration than there
are servers, so it's backwards from the way you'd want to do things.

If a transition period is not allowed, people just won't patch.

- Marsh

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 16 Nov 2009 12:01:34 -0800

> Right. I thought there was concensus on not allowing that?

Well, I'm in -- but Martin's quote above is specifically about a  
"updated, but backwards compatible client" talking to an "updated, but  
backwards compatible server".

> until almost all connections are protected.

Yes.  Note that it's more complex, though -- we'd possibly *allow*  
patched severs to perform backwards-compatible renegotiation, but not  
*require* them to do so.

I'd think reasonable defaults are for *clients* to support backwards- 
compatible servers (although they might not actually want to perform  
renegotiation with them), and for *servers* to completely disallow  
legacy renegotiation.  The question is if we'd want to allow server  
administrators to modify this default, and support legacy  
renegotiation for old clients.  The problem that I see is, if we don't  
plan for this configuration option in the specs, some implementations  
might introduce it anyway, thus breaking the security that the we  
intend to provide.  If we plan for it (such as with client-to-server  
signaling using a pseudo-ciphersuite number), the protocol will be  
more fool-proof.

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 16 Nov 2009 12:05:04 -0800

> are servers, so it's backwards from the way you'd want to do things.

Servers could be patched before clients -- it's just renegotiation  
that would break when an old client talks to an updated server.

> If a transition period is not allowed, people just won't patch.

Yup.  Backwards-compatible renegotiation should be enabled just on  
those servers that *need* renegotiation (for the transition period).   
This shouldn't be the default.

Bodo

---

From: Martin Rex <[email-masked]>
Date: Mon, 16 Nov 2009 21:19:54 +0100 (MET)

> Right. I thought there was concensus on not allowing that?

We can make it a MUST NOT only for TLSv1.3 onwards.

Retroactively, we can only make it a SHOULD NOT for the installed base,
because there is an installed base which we would completely brick
otherwise.

We must leave that decision to the consumers of the technology,
and only give guidance, make it as easy as possible to adopt the
necessary fix and try hard to cover as many existing usage scenarios
with the fix as possible.

> server on a given connection are patched.

Which would indicate a design flaw in the fix.

The fix I proposed will protect an updated client talking to an updated
server even when both allow backwards-compatible renegotiation.

If a fix is only secure if neither peer allows backwards-compatible
renegotiation then the fix is definitely a failure.

The purpose of the TLS handshake protection is specifically to prevent
attackers from downgrading without breaking the finished macs.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Mon, 16 Nov 2009 14:32:56 -0600

Bodo Moeller wrote:
> 
> Servers could be patched before clients -- it's just renegotiation that
> would break when an old client talks to an updated server.

If it's your systems that need it, it's not "just renegotiation"  it may
be your entire product or mission-critical application.

We may talk in terms of statistics, but for the affected systems it's a
total show-stopper, that shouldn't be overlooked.

- Marsh

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 16 Nov 2009 13:59:27 -0800

>> that

Sure.  My point was that it's exaggerated to claim that "Unless this  
is allowed, servers cannot be patched before clients".  Server could  
be patched before clients; just servers that need renegotiation  
couldn't be patched before clients.

However, I agree that even this interoperability case needs to be  
taken seriously.

I wouldn't want legacy renegotiation to be enabled in updated servers  
by default -- normally I'd want to see this disabled so that once all  
servers have been updated, the security problem will be resolved.

If a server operator decides to accept the price of accepting legacy  
renegotiation, the specs should cater for this in a way such that  
there's no downgrade attack if an updated but lenient clients talks to  
an updated but lenient server (which implies that the client has to  
send some signal in the Client Hello, or elsewhere in the handshake);  
and such that an updated but lenient client doesn't have to send an  
extension in the initial handshake (i.e., said signal will have to be  
something other than an extension) or even in a renegotiation  
handshake unless it has established that it's talking to an updated  
server.

The latter indeed suggests we need a signal from the server back to  
the client to confirm that it's updated.

Here's a rather specific proposal, which I think doesn't agree 100%  
with anything that has previously been proposed, although certainly  
all the bits and pieces come from the various proposals that are around.

If the client's "I am updated" signal to the server is a pseudo  
ciphersuite (to avoid having to send an extension and breaking  
interoperability with older servers), I don't see why the server's "I  
am updated too" signal back to the client couldn't be an extension in  
any case.  The TLS Extensions specs don't allow the server to send  
extensions that haven't been proposed by the client -- that's somewhat  
broken to start with (we really just wouldn't want the server to send  
any extensions to a client that doesn't know *anything* about  
extensions), but we can certainly override this rule for this specific  
case, where the client opts in by sending its own signal.

The client and server wouldn't have to know anything else about  
extensions.  If the client doesn't, the server_hello_extension_list it  
sees in the Server Hello in this scheme would always correspond to a  
fixed encoding, which is trivial to handle.  If the server doesn't, it  
would only have to generate this fixed encoding, which is just as  
trivial.

If updated clients send the pseudo ciphersuite in every Client Hello,  
and updated servers send the (empty) extension in every Server Hello  
responding to such a Client Hello, both parties have enough  
information to detect when they are both updated.  For this case,  
we'll have to change the definition of the Finished messages.  My  
preferred approach is (following the suggestion by Martin Rex) to  
include the previous handshake's Finished messages into  
handshake_messages if it's a renegotiation handshake (as "virtual  
handshake messages" -- maybe I'd rather call them "silent handshake  
messages", or just "remembered handshake messages" to better capture  
the specific scenario).  For an initial handshake, nothing needs to be  
changed, except that some updated clients might be configured to  
refuse to complete a handshake with any server that hasn't been  
updated (just like most updated servers should be configured to refuse  
to complete a renegotiation handshake with any client that hasn't been  
updated).

Updated clients and servers should probably send their signals in  
*all* handshakes: (a) initial handshakes and (b) legacy renegotiation  
handshakes are a must, but I think requiring them too in (c) updated  
renegotiation handshakes makes things easier to get right.  We'd get  
rid of the signals from a specific protocol version on: If the client  
and server agree on that version, the new renegotiation Finished  
computation would be implied.  If the client is offering  
interoperability with earlier protocol versions, it should still send  
the explicit signal.

Bodo

---

From: David-Sarah Hopwood <[email-masked]>
Date: Tue, 17 Nov 2009 00:36:08 +0000

[Please, can everyone please retain the attribution lines at the top of
replies, and preferably also sufficient context to resolve the referents
of phrases such as "this problem"?]

Michael D'Errico wrote:
> [Eric Rescorla wrote:]
>> [Martin Rex wrote:]
>>
>>> ... it is very important that we can signal on ALL future TLS
>>> connections established by a client, so that a MITM can not FORCE an
>>> updated, but backwards compatible client to renegotiate insecurely
>>> with an updated, but backwards compatible server. This is what the
>>> TLS extensions RI currently fails completely.
>>
>> A client which sends RI only on renegotiation and aborts the connection
>> if it does not receive RI in return does not have this problem.
> 
> unnecessary for a client to abort a renegotiation.  There is no possible
> man-in-the-middle.

That's not correct. The client should abort such a renegotiation in
order to prevent variants of the attack in which the client sees a
renegotiation, and the server doesn't.

> This is guaranteed when the client has verified the
> server's certificate in its initial handshake.

Consider the case where client certificates are used, and the server
has a "wildcard certificate". Then the attack allows a MITM who can
subvert any server matching the wildcard, to prepend data to a
session between a client authorized by a client cert, and any other
server matching the wildcard.

This shouldn't be possible; it's a violation of TLS's designed security
properties. If patched clients behave according to Eric's statement above,
then this attack is prevented.

---

From: Martin Rex <[email-masked]>
Date: Mon, 23 Nov 2009 23:20:23 +0100 (MET)

> it is much larger. Can you provide references please?

While archiving past discussions I noticed an incorrect statement
I made.  I'm sorry.

What I wanted to say was:

The amount of traffic on the internet that uses SSLv3 {0x03,0x00}
is much larger than the amount of public Web-Servers that is
SSLv3-only, because of clients that lack app-level reconnect
fallbacks and therefore have to make safe/conservative
assumptions about the protocol features supported by the server
in order to get a reply instead of a TCP RST.

-Martin