This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .
According to the public document (TDS 8.0 - SQL Server | Microsoft Learn), Azure SQL Database now supports Tabular Data Stream(TDS) 8.0, which is compatible with Transport Layer Security (TLS)1.3.
(The Tabular Data Stream (TDS) protocol is an application layer protocol used by clients to connect to SQL Server. SQL Server uses Transport Layer Security (TLS) to encrypt data that is transmitted across a network between an instance of SQL Server and a client application.)
To comprehend the basic TLS 1.3 handshake message during a connection to an Azure SQL Database, you can refer to another blog post of mine here: Decoding the TLS 1.3 protocol handshake during a connection to an Azure SQL DB with Wireshark - Micr...
However, occasionally, instead of a ServerHello followed by a ClientHello message, you might encounter a HelloRetryRequest in response to the ClientHello message from the server. What does it mean?
Based on RFC8446, this occurs when the client has not provided a sufficient "key_share" extension (e.g., it includes only DHE or ECDHE groups unacceptable to or unsupported by the server), the server corrects the mismatch with a HelloRetryRequest and the client needs to restart the handshake with an appropriate "key_share" extension.
And the message flow is depicted below (the figure is cited from RFC8446):
Examining the captured network packets with Wireshark on this scenario
Again, this is conducted with an ODBC Driver 18.3.2.1 with (Encrypt=strict).
#1 ClientHello with the key share of group x25519.
#2 HelloRetryRequest from the server as the client's key share of group x25519 is unacceptable or unsupported to the server.
#3 ClientHello again., now providing the key share of a different group(secp384r1).
#4 ServerHello. The server accepts the client's key share of group secp384r1 and responds ServerHello with its own key share of the same group (secp384r1).
To avoid seeing the HelloRetryRequest, you can either:
- Disabling the group unsupported by the server with Disable-TlsEccCurve PowerShell command
- Changing the preference order of Supported Groups with Enable-TlsEccCurve PowerShell command.
If you don't know the Curve name, you can run Get-TlsEccCurve PowerShell command to get it.
Below demonstrate how it works.
Disabling the Group Unsupported by the Server
Run the command:
Now, the client will use the key share of group secp256r1.
The Server will send ServerHello instead of HelloRetryRequest.
Changing the Preference Order of Supported Group
Run the command to set secp384r1 the most preferred group to use.
Now the client sends the key share of group secp384r1 in the ClientHello message.
The server responds a ServerHello message with the key share of the same group.
Hope this brief overview of HelloRetryRequest helps you understand the message flow better.