Subject: Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft

From: Yuhong Bao <[email-masked]>
Date: Tue, 10 Feb 2015 23:46:52 -0800

>> On Dec 24, 2014, at 9:23 AM, Dave Garrett <[email-masked]> wrote:
>>
>> On Wednesday, December 24, 2014 01:40:10 am you wrote:
>>>> There's no reason to maintain any backwards support here just for
>>>> Internet Explorer 2.0 on Windows 3.1.
>>>
>>> I’m not objecting to the change, but I am objecting to the hyperbole. The
>>> issue is with Internet Explorer 6 on Windows XP, which still exists, but
>>> more importantly, a lot of web service clients running on top of Windows
>>> XP use the same SCHANNEL library as IE would use, so they issue a SSLv2
>>> ClientHello. Despite Microsoft’s best efforts, there is still a
>>> substantial but diminishing install base of XP.
>>
>> I was not aware Microsoft used an SSL2 ClientHello for SSL3. Thanks for pointing
>> that out. Is it not capable of sending an SSL3/TLS Hello at all? If it were
>> properly configured to enable TLS1 and disable SSL2/3, would it send the proper
>> TLS compatible Hello? (Microsoft really should've pushed an XP update to flip
>> that switch years ago)
>
> Yes. From the control panel you clicked “Internet Options”, and that had a tab for security, but it wasn’t there. Instead, it was in the tab for advanced, which had a bunch of options, some related to security, but it was under “encryption”, not security. There were checkboxes for support of SSLv2, SSLv3, and TLS 1.0. By default the SSLv2 and SSLv3 checkboxes were checked, while the TLS 1.0 box was unchecked. To get rid of the SSLv2 ClientHello you had to uncheck the SSLv2. I don’t think the kind of people who still use Windows XP are the same ones who would go into the settings to disable SSLv2.
>
> I might have some of the details wrong. It’s been a few years since I last set Internet Options on a Windows XP box.

In fact, i think you can disable the SSLv2 ClientHello globally for all users of SChannel using the following reg key:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\Multi-Protocol Unified Hello\Client]
"Enabled"=dword:00000000

---

From: Florian Weimer <[email-masked]>
Date: Wed, 11 Feb 2015 14:12:53 +0100

On 12/24/2014 08:02 AM, Yuhong Bao wrote:
>>>
>>> There's no reason to maintain any backwards support here just for Internet
>>> Explorer 2.0 on Windows 3.1.
>>>
>>
>> I’m not objecting to the change, but I am objecting to the hyperbole. The issue is with Internet Explorer 6 on Windows XP, which still exists, but more importantly, a lot of web service clients running on top of Windows XP use the same SCHANNEL library as IE would use, so they issue a SSLv2 ClientHello. Despite Microsoft’s best efforts, there is still a substantial but diminishing install base of XP.
>>
>> It’s fine for us to break compatibility with these clients, but let’s not pretend it’s some ancient technology that doesn’t exist in the market anymore.
>>
> If needed, one suggestion would be to cap the old SSLv2 ClientHello to TLS 1.2.

At least make it TLS 1.1 instead.  With TLS 1.2, the SSLv2 ClientHello
cannot include the signature algorithms extension, so SHA-1 is used
instead of the concatenation of MD5 and SHA-1, and this usually not what
is wanted.

-- 
Florian Weimer / Red Hat Product Security

---

From: Florian Weimer <[email-masked]>
Date: Wed, 11 Feb 2015 14:17:36 +0100

On 12/27/2014 11:39 PM, Dave Garrett wrote:
> On Saturday, December 27, 2014 05:07:12 pm Hauke Mehrtens wrote:
>> On 12/24/2014 07:40 AM, Yoav Nir wrote:
>>> It’s fine for us to break compatibility with these clients, but let’s not
>>> pretend it’s some ancient technology that doesn’t exist in the market
>>> anymore.
>>
>> In addition the Oracle Java Runtime Environment in Version 6 uses a SSL
>> v2 compatible ClientHello in the default settings. It supports SSL v3
>> and TLS 1.0. In Java JRE 7 a SSLv3 ClientHello is used by default.
>>
>> I think a TLS 1.3 Client must not send a SSLv2 ClientHello, but a server
>> should understand it.
> 
> The newest version of TLS should not be have to be written to accommodate an 8 
> year old EOL Java version's default settings.

I could reproduce the behavior with OpenJDK 6 which is still supported:

  https://bugzilla.redhat.com/show_bug.cgi?id=880223

Because it's not EOL, we can still fix the defaults, although this may
not be what some users expect or need.

(FWIW, Android does not use “Java 6”, it's an independent implementation
with different behavior and defaults.)

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 11 Feb 2015 11:41:38 -0500

On Fri 2014-12-26 13:11:39 -0500, Kurt Roeckx wrote:
> On Mon, Dec 22, 2014 at 07:45:35PM -0500, Dave Garrett wrote:
>> I've submitted a straightforward PR to remove the SSL 2 backwards compatibility 
>> section from the current TLS 1.3 draft:
>> 
>> https://github.com/tlswg/tls13-spec/pull/105
>> 
>> SSL 2.0 backwards compatibility was previously deprecated in TLS 1.2 (2008) and 
>> was warned to be "phased out with all due haste". RFC 6176 (2011) prohibits it 
>> entirely. It's a section of obsolete complexity still in the draft.
>> 
>> The PR replaces the section with a simple "MUST NOT" send or accept for TLS 1.3 
>> implementations.
>
> I'm having mixed feelings about this.
>
> It's saying that you should refuse a connection from a client that
> supports TLS 1.0 but set it up using a SSLv2 compatible client
> hello.  If TLS 1.0 is still acceptable, why would you refuse such
> a connection?

It's not saying that.  It says:

   Implementations MUST NOT negotiate TLS 1.3 or later using an SSL
   version 2.0 compatible CLIENT-HELLO. Implementations MAY accept an
   SSL version 2.0 compatible CLIENT-HELLO in order to negotiate older
   versions of TLS, however this is not recommended.

So if the client connects with an SSLv2 handshake, we can negotiate TLS
1.0 with it (while acknowledging that this isn't a recommended state).

    --dkg

---

From: Yuhong Bao <[email-masked]>
Date: Thu, 12 Feb 2015 15:48:22 -0800

> instead of the concatenation of MD5 and SHA-1, and this usually not what

Just confirmed that IE on Win7 even when misconfigured to enable SSLv2 doesn't send a SSLv2 ClientHello with TLS 1.2 on it which means that SChannel probably can't do it at all. Andrei Popov should be able to confirm this.

---

From: Andrei Popov <[email-masked]>
Date: Thu, 12 Feb 2015 23:53:16 +0000

I confirm.

Cheers,

Andrei

-----Original Message-----
From: Yuhong Bao [mailto:[email-masked]] 
Sent: Thursday, February 12, 2015 3:48 PM
To: Florian Weimer; [email-masked]
Cc: Andrei Popov
Subject: RE: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft

>>> I'm not objecting to the change, but I am objecting to the hyperbole. The issue is with Internet Explorer 6 on Windows XP, which still exists, but more importantly, a lot of web service clients running on top of Windows XP use the same SCHANNEL library as IE would use, so they issue a SSLv2 ClientHello. Despite Microsoft's best efforts, there is still a substantial but diminishing install base of XP.
>>>
>>> It's fine for us to break compatibility with these clients, but let's not pretend it's some ancient technology that doesn't exist in the market anymore.
>>>
> instead of the concatenation of MD5 and SHA-1, and this usually not 
> what is wanted.

---

From: [email-masked] (Martin Rex)
Date: Sat, 14 Feb 2015 09:54:29 +0100 (CET)

Yuhong Bao wrote:
>
> Just confirmed that IE on Win7 even when misconfigured to enable
> SSLv2 doesn't send a SSLv2 ClientHello with TLS 1.2 on it which
> means that SChannel probably can't do it at all. Andrei Popov
> should be able to confirm this.

IIRC, Win7 shipped with TLSv1.2 *disabled*.

I see the following downgrade dances with MSIE 10
on (a fully patched) 64-bit Win7sp1.

What's a little weird about the MSIE downgrade dances:
  - duplicated attempts with certain Hellos in certain configurations
  - empty connection attempts when SSLv2 is disabled.

The (dummy) server that I had MSIE connect to read the ClientHello
from the network waited a second and then closed the network connection.

-Martin

everything enabled (SSLv2->TLSv1.2):

  TLS record (3,3)  ClientHello.client_version(3,3) with TLS extensions
  SSL2 record  ClientHello.client_version(3,1)
  SSL2 record  ClientHello.client_version(3,0)
  SSL2 record  ClientHello.client_version(0,2)

SSLv2 plus default (SSLv3,TLSv1.0,TLSv1.1):

  SSL2 record  ClientHello.client_version(3,2)
  SSL2 record  ClientHello.client_version(3,1)
  SSL2 record  ClientHello.client_version(3,0)
  SSL2 record  ClientHello.client_version(0,2)

SSLv2 plus TLSv1.0+TLSv1.1 (this looks weird!):

  SSL2 record  ClientHello.client_version(3,2)
  SSL2 record  ClientHello.client_version(3,1)
  SSL2 record  ClientHello.client_version(0,2)
  SSL2 record  ClientHello.client_version(0,2)

For comparison the (hopefully more common scenarios):

SSLv3->TLSv1.2:

  TLS  record (3,3)  ClientHello.client_version(3,3) with TLS extensions
  TLS  record (3,1)  ClientHello.client_version(3,1) with TLS extensions
  SSL3 record (3,0)  ClientHello.client_version(3,0)
  TCP-connect + TCP-close

TLSv1.0+TLSv1.1+TLSv1.2

  TLS  record (3,3)  ClientHello.client_version(3,3) with TLS extensions
  TLS  record (3,1)  ClientHello.client_version(3,1) with TLS extensions
  TCP-connect + TCP-close

And finally the more esoteric configurations:

TLSv1.1+TLSv1.2

  TLS  record (3,3)  ClientHello.client_version(3,3) with TLS extensions
  TCP-connect + TCP-close

TLSv1.2 alone

  TLS  record (3,3)  ClientHello.client_version(3,3) with TLS extensions
  TCP-connect + TCP-close

SSLv3+TLSv1.2

  TLS  record (3,3)  ClientHello.client_version(3,3) with TLS extensions
  SSL3 record (3,0)  ClientHello.client_version(3,0)
  SSL3 record (3,0)  ClientHello.client_version(3,0)
  TCP-connect + TCP-close

TLSv1.0+TLSv1.2

  TLS  record (3,3)  ClientHello.client_version(3,3) with TLS extensions
  TLS  record (3,1)  ClientHello.client_version(3,1)
  TCP-connect + TCP-close

SSLv2+TLSv1.2

  TLS  record (3,3)  ClientHello.client_version(3,3) with TLS extensions
  SSL2 record  ClientHello.client_version(0,2)
  SSL2 record  ClientHello.client_version(0,2)
  SSL2 record  ClientHello.client_version(0,2)

---

From: Dave Garrett <[email-masked]>
Date: Sat, 14 Feb 2015 12:04:34 -0500

>   - empty connection attempts when SSLv2 is disabled.
[...]
> everything enabled (SSLv2->TLSv1.2):
[...]
> SSLv2 plus default (SSLv3,TLSv1.0,TLSv1.1):
[...]
> SSLv2 plus TLSv1.0+TLSv1.1 (this looks weird!):
[...]
> SSLv3->TLSv1.2:
[...]
> TLSv1.0+TLSv1.1+TLSv1.2
[...]
> TLSv1.1+TLSv1.2
[...]
> TLSv1.2 alone
[...]
> SSLv3+TLSv1.2
[...]
> TLSv1.0+TLSv1.2
[...]
> SSLv2+TLSv1.2

Are there any other clients that allow fine-grained enabling/disabling of each version? Firefox and Chrome set min/max. Safari is incompetent and provides no configuration. IE is the only one that seems to allow this wide list of configurations, and the resulting oddities. I'm curious what non-browser clients do here commonly.

Dave

---

From: Yuhong Bao <[email-masked]>
Date: Tue, 17 Feb 2015 00:45:32 -0800

> Date: Wed, 11 Feb 2015 14:17:36 +0100
> From: [email-masked]
> To: [email-masked]
> Subject: Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft
>

Even Oracle's latest paid support version of Java 5 and Java 6 have now disabled SSLv2Hello:
http://www.oracle.com/us/technologies/java/overview-156328.html
http://www.oracle.com/technetwork/articles/javase/overview-137139.html

---

From: [email-masked] (Martin Rex)
Date: Wed, 18 Feb 2015 02:17:46 +0100 (CET)

> should be able to confirm this.

Speaking of Windows 7 SChannel, just today I enabled TLSv1.2
for the IIS on my Windows 7 test machine (it is disabled by default)
and tried to negotiate TLSv1.2 with it -- but I'm facing handshake failures.

I'm sending a pretty vanilla, extension-less ClientHello

  record=(3,0) and ClientHello.client_version=(3,3)

with the following TLS cipher suites:

  TLS_RSA_WITH_AES128_CBC_SHA
  TLS_RSA_WITH_RC4_128_SHA
  TLS_RSA_WITH_RC4_128_MD5
  TLS_RSA_WITH_3DES_EDE_CBC_SHA

and the Microsoft IIS server on my Win7 machine closes the connection.
The following two Events get written to the Windows "System" Eventlog:

 Source: Schannel   EventID: 36874
  An TLS 1.2 connectin request was received from a remote client application,
  but none of the cipher suites supported by the client application are
  supported by the server.  The SSL connection request has failed.

 Source: Schannel   EventID: 36888
  The following fatal alert was generated: 40.
  The internal error state is 1205.

As some might notice, the ClientHello lists the mandatory-to-implement
TLSv1.2 cipher suite (rfc5246, section 9), so it is extremely unexpected
to see the handshake fail when proposing TLSv1.2, but succeed when
proposing only TLSv1.1.

Since I can connect with a browser with TLSv1.2 (and with openssl-1.0.1j)
the issue might be the absence of the TLS signature algorithm extension.

Per rfc5246, the use of TLS extensions is a MAY for the TLSv1.2 client and
accepting a ClientHello without extensions is a MUST for the TLSv1.2 server:

(rfc 5246, section 7.4.1.2  ClientHello)
https://tools.ietf.org/html/rfc5246#page-42

   extensions
      Clients MAY request extended functionality from servers by sending
      data in the extensions field.  The actual "Extension" format is
      defined in Section 7.4.1.4.

                                       A server MUST accept ClientHello
   messages both with and without the extensions field,

Myself I don't have any Win8 / Win2012 machines, but I assume they're
also both affected.  I only tried this because the customers ADFS server
(2012 I believe) didn't want to interop.

-Martin

---

From: Yuhong Bao <[email-masked]>
Date: Tue, 24 Feb 2015 01:08:00 -0800

----------------------------------------
> with different behavior and defaults.)

FYI on SMTP, IBM Domino was forced to restore SSLv2 ClientHello support under a switch that has to be enabled:
http://www.wiseman.la/web/cpwBlog.nsf/dx/domino-customer-please-call-ibm-support-help-get-smtp-tlsssl-fixed.htm?opendocument&comments#anc1
http://www-10.lotus.com/ldd/ndseforum.nsf/xpTopicThread.xsp?documentId=E614F339E975A7A485257D860064343A