Introduction:
==========
We have had occasional reports of interoperability problems between Java Clients and Microsoft Schannel-based servers (e.g. IIS 7.5). However, they are rare and we believe they are due to a previous defect in the Microsoft TLS Schannel implementation. The issue discussed below has been corrected in all supported, fully patched Windows versions, starting with Server 2012 or newer.

It can impact performance, as additional expensive handshakes might be performed by protocol fallback workarounds by application code that calls JSSE.

Symptom:
========
We are seeing this when the following protocols are enabled:

    Client: TLSv1/TLSv1.1/TLSv1.2 (Java)
    Server: TLSv1 (IIS)

Java Client tries to connect with TLSv1.2, IIS replies with TLSv1. On a renegotiation (say due to a client authentication request), the TCP connection is reset (RST) when the handshake silently fails.

Solutions/Workarounds:
===================
In order of preference:

1. Negotiate a non-RSA-based (TLS_RSA_*) ciphersuite. (e.g. use TLS_ECDHE_*, TLS_DHE_DSS_*, or TLS_DHE_RSA_*)

2. Enable both TLSv1.1/TLSv1.2 on the server, (Server 2008 R2 is the oldest release with TLS 1.1/1.2 support (disabled by default)), or

3. Upgrade to Windows Server 2012 or 2016. Server 2012 is the oldest they have without this specific issue.

4. Disable TLSv1.1/TLSv1.2 on the client. (this is not encouraged and only a workaround, as the older versions of SSLv3/TLSv1 are being phased out.)

Note: The System Property com.sun.net.ssl.rsaPreMasterSecretFix does not address this issue.


Issue Details:
===========

Here's what's happening:

NOTE: There should be should be 1 TCP connection/2 TLS handshakes. Instead we are seeing 2 TCP connections/4 TLS handshakes.

Connection 1

    client/server completes initial TLS handshake.
        client requests *TLSv1.2*
        server responded TLSv1

        The RSA PreMasterSecret version field offered by client is *TLSv1.2*

    client requests a sensitive document

    server requires client authentication to access, init's client authentication handshake

    client/server handshake - *fails*
        client requested TLSv1
        server responded TLSv1

        The RSA PreMasterSecret version field offered by client is *TLSv1*.
        If server expects/requires TLSv1.2, that will kill the handshake, and reset the TCP connection

        *UPDATE 2016/11/11*: Confirmed. Replacing with TLSv1.2 allowed the handshake to complete.

Connection 2

    client retries the connection offering TLSv1 only
        client requested TLSv1
        server responded TLSv1

    client requests a sensitive document

    server requires client auth to access, init's client auth handshake

    client/server attempt handshake/succeeds
        The RSA PreMasterSecret version field offered by the client is TLSv1

    server responds with sensitive document.

I wrote to the TLS developer at Microsoft and he responded with:

    The current behavior is as follows:
    - Schannel-based servers allow PreMasterSecret.client_version >= most recent ClientHello.client_version (e.g. from the resumption ClientHello).
    - Schannel-based clients always set ClientHello.client_version to the highest supported/enabled protocol version (even when resuming).

That is:

    They will allow RSA PMS values of TLSv1 and greater (i.e. TLSv1/TLSv1.1/TLSv1.2/TLSv1.3/etc.)

Since this bug has been fixed by Microsoft, I don't feel we need to provide a workaround System Property to send the wrong RSA PMS. I am of the opinion that since this only occurs on an old OS (Windows 2008, fixed in later releases) and the customer can easily enable TLSv1.2, there's little need to be proactive.

Background Information
===================
Here is some relevant emails from April 2012 from the IETF TLS Working Group mailing list.

    https://mailarchive.ietf.org/arch/msg/tls/eXfviKewlYoskcvnUyEF4vHwrJo
    https://mailarchive.ietf.org/arch/msg/tls/icV08a_z-b4iVXJAN5aS71KNj0M

which was a followup to this August 10 2010 discussion:

    https://mailarchive.ietf.org/arch/msg/tls/OoCcFd-_B3ydjOFGBbCevpaqSqI

These threads and the followups can be found here:

    https://mailarchive.ietf.org/arch/search/?email_list=tls&q=PreMasterSecret