@kevin - You’re correct that Windows 8.1/Server 2012R2 don’t ship with these cipher suites, however the article you referenced has information that is critical here:
-
The highest supported TLS version is always preferred in the TLS handshake
-
Windows 8.1 and Windows Server 2012 R2 are updated by Windows Update by the update 2919355 applied which adds the new cipher suites and changes the priority order.
You can read the additional ciphers that were added to Server 2012R2 here: Update adds new TLS cipher suites and changes cipher suite priorities in Windows 8.1 and Windows Server 2012 R2
I’m more of the suspicion that something in the Roon Server configuration has caused this error.
I captured the packets on my Server 2012 R2 machine and examined the cipher suite negotiation and found that the client’s list had TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (the cipher that was “offered”) and the server (in this case streaming-std.qobuz.com) returned with a negotiated cipher of TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - So it appears they did negotiate a cipher suite and agree on it. The error is somewhere else - See last two photos of the Wireshark capture where I’ve highlighted the pertinent sections.!
I can’t help but wonder what a fresh install in Server 2012 R2 will do. You can’t argue with the raw data stream from the Roon Server to Qobuz. There are many negotiations and they all are the same cipher suite that is ultimately negotiated.
