Since upgrading to 1.17 in which the cipher order is determined by the golang lib, clients that previously negotiated with more secure ciphers are now using less secure ciphers.
We see that Windows 7 and 8 clients can no longer negotiate using
xc027 and are instead using
0x9c, which is lower in both of their preference order.
On 1.16, using testssl.sh, for example:
IE 11 Win 7 TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH (P-256)
IE 11 Win 8.1 TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH (P-256)
IE 11 Win Phone 8.1 TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH (P-256)
IE 11 Win 10 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 256 bit ECDH (P-256)
And since upgrading to 1.17 (and 1.18):
IE 11 Win 7 TLSv1.2 AES128-GCM-SHA256, No FS
IE 11 Win 8.1 TLSv1.2 AES128-GCM-SHA256, No FS
IE 11 Win Phone 8.1 TLSv1.2 ECDHE-RSA-AES128-SHA256, 256 bit ECDH (P-256)
IE 11 Win 10 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256, 256 bit ECDH (P-256)
Win 7 and
Win 8.1 prefer
0xc027 over
0x9c, but now both negotiate using
0x9c.
We could theoretically solve this by removing 0x9c from our supported cipher suites to force the selection of 0xc027, but unfortunately we need to keep supporting these older clients.
I wanted to check here to see if anyone has any suggestions before filing a bug, because in my opinion, the client cipher suite order preference should be honored at the very least even if the server preference is no longer honored.