Does Indy's IdHTTP send SNI when connecting to an HTTPS site using only an IP address?
0 reputation · 10 May 2022, 02:47 UTC
0 reputation · 10 May 2022, 02:47 UTC
The goal is to confirm whether the IdHTTP component automatically includes the Server Name Indication (SNI) extension in the TLS ClientHello when the destination is specified by a raw IP address rather than a hostname.
Indy’s IdSSLIOHandlerSocketOpenSSL sets the SNI extension only when the Host property of IdHTTP is explicitly assigned; if the Host property is left blank or later overridden by a custom Host header, the SNI field may be omitted, potentially causing virtual‑host mismatches on servers that rely on SNI for certificate selection.
Uncertainty remains about whether this behavior is consistent across recent Indy versions, whether any internal fallback copies the IP address to SNI, and if developers must manually enforce SNI in such scenarios.
Does Indy automatically populate SNI from the IP address when Host is unset?
Can SNI be forced without setting the Host property?
Does the SNI handling differ between Indy 10.6.2 and earlier releases?
35775 reputation · 10 May 2022, 09:08 UTC
No. Indy’s TIdHTTP does **not** automatically include the Server Name Indication (SNI) extension in the TLS ClientHello when the request URL specifies only an IP address and the Host property is left unset.
TIdSSLIOHandlerSocketOpenSSL.Host.TIdSSLIOHandlerSocketOpenSSL.Host is set from the URL’s hostname component. An IP literal is treated as a hostname but is **not** copied into the SNI field; if the URL contains no hostname (e.g., https://203.0.113.5/), the property remains empty and no SNI is sent.TIdHTTP.Host or adding a custom HTTP Host header does **not** propagate to SSLIOHandler.Host. Developers must assign SSLIOHandler.Host explicitly to force SNI.Host property:IdSSLIOHandlerSocketOpenSSL.Host := 'example.com';
TIdHTTP.Get (or other) call as usual.If you prefer to keep the URL as an IP address but still send a custom HTTP Host header, you must still set SSLIOHandler.Host separately; the HTTP header alone does not affect SNI.
Capture the TLS handshake with Wireshark or openssl s_client -connect <IP>:443 -servername <desired‑SNI> and confirm that the SNI extension appears only after you assign SSLIOHandler.Host.
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 10 May 2022, 09:31 UTC
It is important to clarify that the Host property in TIdHTTP primarily affects the HTTP request header, which is sent after the TLS handshake is complete. The Server Name Indication (SNI) extension occurs during the TLS ClientHello phase, which is managed by the TIdSSLIOHandlerSocketOpenSSL component.
When connecting via a raw IP address, Indy typically does not automatically map that IP to an SNI hostname. To verify this behavior in your specific version (e.g., Indy 10.6.2), you can use a packet analyzer like Wireshark to inspect the Client Hello packet. Look for the server_name extension; if it is missing or contains the IP address, the server may fail to provide the correct certificate for virtual hosting.
For environments requiring strict SNI while using IP-based routing, you may need to manually ensure the SSL handler is aware of the intended hostname before the connection is established.