Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt

[[e-mail] (Martin Rex)]

Andrei Popov <Andrei.Popov=[e-mail]> wrote:
>
> On the recent Windows versions, TLS 1.0 is negotiated more than 10%
> of the time on the client side (this includes non-browser connections
> from all sorts of apps, some hard-coding TLS versions),
> and TLS 1.1 accounts for ~0.3% of client connections.

"On recent Windows versions" sounds like figure might not account
for Windows 7 and Windows Server 2008R2, about half of the installed
base of Windows, and where the numbers are likely *MUCH* higher.

When troubleshooting TLS handshake failures, I sometimes trying
alternative SSL/TLS clients on customer machines through remote support,
and it seems when I run this command on a Windows 2012R2 server:

        powershell "$web=New-Object System.Net.WebClient ; $web.DownloadString('https://www.example.com/')" 2>&1

it connects with TLSv1.0 only, and this is a client-side limitation.

To make it use TLSv1.2, I would have to use

        powershell "[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 ; $web=New-Object System.Net.WebClient ; $web.DownloadString('https://www.example.com/')" 2>&1

i.e. explicit opt-in.


I already have a long list of stuff that uses TLSv1.0 for outgoing
communication by default, and that list is constantly growing, and that
is not just stuff running with JavaSE 1.6 or JavaSE 1.7.
Btw. lots of J2EE Servers are still on JavaSE 1.6, without the
non-public TLSv1.2-capable update.


We also had customer incidents about hardware stuff, they called it "RF Gun",
probably some RFID scanner, that seems to be limited to TLSv1.0 and
TLSv1.0 cipher suites (either 3DES-EDE-CBC-SHA or RC4-128).


I would really hate it to see the IETF enter the "planned/forced obsolence"
market, growing the dumpsters of electronic equipment that would still work
just fine, but has to be retired for the sole purpose of economic growth.


-Martin