[_wmd]

SNI-enabled browsers send the unencrypted hostname in the initial ClientHello frame. It's the first transaction in the protocol, and it's how the server decides the content of the ServerHello reply. There is no way to detect the ability to avoid SNI, or indeed any sensible and generally useful way to tell if a ServerHello varied according to the ClientHello SNI hostname without probing the server, which entails introducing roundtrips, and disclosing the hostname unencrypted at least once on the wire.

[aplorbust]

"There is no way to detect the ability to avoid SNI..."

Assuming one is using an SNI-enabled browser.

I dont use an SNI-enabled browser to make the first encrypted HTTP request.

In fact I didnt even say I was using a "browser". I said "https client".

For example, one can use an https client that has SNI disabled or which has no SNI code at all, or one can send any string as the servername in ClientHello.1 If the server responds with hostname not found, then retry using SNI and the desired hostname. IME, most TLS-enabled websites do not require SNI.

  1
  exec printf 'GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n'|exec openssl s_client -tls1_2 -no_ssl2 -no_ssl3 -ign_eof -connect 93.184.216.34:443 -servername SNI_NOT_REQUIRED

[mike-cardwell]

When you say "If the server responds with hostname not found", what are you talking about? Exactly which protocol are you refering to when you say "hostname not found" ?

Most web servers will just fall back to the default virtual hosts SSL certificate if no SNI header is present in the clients request... They don't reply "hostname not found", or "nope, no such host", or anything similar...

[aplorbust]

"They don't reply "hostname not found", or "nope, no such host", or anything similar..."

"hostname not found" was meant to be a general term for failure due to not sending the correct servername when it is required, not a specific protocol error. I apologise for not being more precise. What happens with the non-SNI clients I use in the rare case when absence of correct servername is fatal is that the connection fails. (Most times a correct servername, let alone any servername, is not required1 and the connection succeeds. Thats the point of the original comment: in a majority of cases, its possible to get the page content without using SNI.)

1 As in the case of example.com, for example.

However, I use a local forward proxy for TLS-enabled websites. The proxy returns HTTP 503 error when the connection fails due to SNI. Thus, I do get a consistent "server response" when this happens, albeit not from the remote server.

[_wmd]

Since the ClientHello is sent in the clear, a MITM can simply reset the connection until the client retries with SNI. Again, there is no generally useful way to solve this

[aplorbust]

"... a MITM can simply reset the connection until the client retries with SNI."

That doesnt happen when I fetch https://example.com without sending a servername in ClientHello.

For the majority of TLS-enabled websites on the internet, that does not happen. I get the page content just fine witout sending a servername in ClientHello.

But I should send the servername in ClientHello anyway?

This reasoning I am too stupid to understand.