Server 2008 and TLSv1.2 Server Issues (KB4019276)


  • Hi, I seemed to have originally posted this on another forum which is no longer active so I will try here.

    I've been trying to get TLS 1.2 working with some Server 2008 hosts that I have and I have been having some issues. I have read through KB4019276, installed the update and configured the host to allow the TLS 1.2 protocol for both the server and the client but I am having trouble trying to get it actually working. I have installed IIS to help troubleshoot these problems but this also affects other services that use the HTTP stack like WinRM and it would be great to finally solve this issue so I am not reliant on older protocols.

    Before I begin, I have a baseline server with the following;

    * Server 2008 x64
    * KB4019276 installed (as well as all other patches that are available as of March 2018)
    * The TLS 1.2 Protocol keys for both the Client and Server are created and set to Enabled
    * IIS installed with the default website and a HTTPS binding with a self signed certificate
    * Server is fresh from a reboot after all of the above is done

    I am able to verify that the client TLS 1.2 settings work perfectly fine, I set up an OpenSSL mock server that only accepted TLS 1.2 requests and was able to access it from this PowerShell script as well as a non-IE browser like Firefox.

    [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
    [System.Net.ServicePointManager]::ServerCertificateValidationCallback = { $true }
    $client = [System.Net.WebRequest]::Create('https://openssl-server:8443')
    $client.Method = "GET"

    The issue comes to hand when dealing with the TLS 1.2 server implementation, to start with I just added a https binding to the default website that comes with IIS. From there I used OpenSSL on another host to test out the connection with the following command;

    openssl s_client -connect server2008:443

    no peer certificate available
    No client certificate CA names sent
    SSL handshake has read 0 bytes and written 308 bytes
    New, (NONE), Cipher is (NONE)
    Secure Renegotiation IS NOT supported
    Compression: NONE
    Expansion: NONE
    No ALPN negotiated
        Protocol  : TLSv1.2
        Cipher    : 0000
        Key-Arg   : None
        PSK identity: None
        PSK identity hint: None
        SRP username: None
        Start Time: 1521631121
        Timeout   : 300 (sec)
        Verify return code: 0 (ok)

    This seems to me that TLSv1.2 is being offered by the server but there is no common ciphers available between OpenSSL and the IIS site. If I was to force the use of TLSv1.0 from the OpenSSL side I get the following output

    openssl s_client -connect server2008:443 -tls1

    SSL handshake has read 1447 bytes and written 782 bytes
    New, TLSv1/SSLv3, Cipher is AES128-SHA
    Server public key is 4096 bit
    Secure Renegotiation IS supported
    Compression: NONE
    Expansion: NONE
    No ALPN negotiated
        Protocol  : TLSv1
        Cipher    : AES128-SHA
        Session-ID: B80C000008360326F805C89F2E2DD9F48B7F2395AD371EFAC2A8CD808F3711F1
        Master-Key: 8CDFF54BA91C87C425FA72488880BFC802FF8E521AF9DDE4A23A053466D1D4C49CEC4C967168D878D40FB3B98623FB48
        Key-Arg   : None
        PSK identity: None
        PSK identity hint: None
        SRP username: None
        Start Time: 1521631269
        Timeout   : 7200 (sec)
        Verify return code: 21 (unable to verify the first certificate)

    We can see that is was able to negotiate with TLSv1 being set and it actually had a common cipher between the two. When accessing the site from IE on another Windows host like Windows Server I can see the following packet flow

    1. Client tried to connect to the Server 2008 host with TLSv1.2 and offers a wide range of ciphers

    2. Server breaks the socket with a RST and ACK packet back
    3. Client then sends another ClientHello now with TLSv1.0 and some different ciphers on offer

    4. Server response with a ServerHello and selects the TLSv1.0 protocol and specific cipher to use

    In this particular example, it resulted in a TLSv1.0 connection and the cipher 'TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)' was selected. This cipher was present in the original TLSv1.2 ClientHello message so I know the client and the server has some common cipher suites that can be negotiated. On a freshly rebooted host, on the first connection that uses TLSv1.2 I see the following error in the System event log;

    An SSL connection 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.

    The source for this error is from Schannel and will only appear on the first request after a server is rebooted, any further attempts and this event will not be logged anymore. What is interesting is that it is saying no common cipher suites could be negotiated between the client and the server but from our Wireshark capture above we know TLS_RSA_WITH_AES_128_CBC_SHA is common as that was ultimately negotiated in TLSv1.0. It sounds like the server's TLSv1.2 implementation cannot see any available cipher suites and so breaks the connection effectively not supporting TLSv1.2 at all.

    Is someone able to confirm my suspicions and offer some alternatives to get this going. While having full TLSv1.2 support would be great the unfortunate part of this is the RST/ACK message sent from the Server 2008 host. Without the TLSv1.2 server side enabled, the process flow would be

    1. Client send ClientHello with TLSv1.2 and list of cipher suites it supports
    2. Server response with ServerHello with TLSv1.0 as the protocol and the cipher suite selected
    3. .... continues as normal

    On Windows it seems like it automatically copes with this by then sending another ClientHello on receipt of the RST/ACK but for some other implementations like OpenSSL it just outright fails saying the socket was closed.

    This breaks things like open source implementations of WinRM if the server TLSv1.2 key is set to Enabled. So summing up

    • TLSv1.2 Client seems to work fine on Server 2008 with the patch
    • TLSv1.0 works fine and Schannel supports incoming requests based on TLSv1.2 and response correctly if TLSv1.2 server is not enabled
    • With the Server TLSv1.2 key applied and set to Enabled, Schannel would now abruptly close the socket saying no common cipher suites and the client must now resend another request with TLSv1.0 as the protcol

    While yes, the patch is useless if TLSv1.2 doesn't actually work but because the behaviour around protocol downgrades changes and Schannel sends that RST/ACK packet on the first request, this could break some implementations out there.

    I've got a copy of the Wireshark packet capture and the Schannel event log, please let me know if you would like me to send them through.



    vendredi 23 mars 2018 10:31

Toutes les réponses