4

I am getting an SNI error:

Hostname X provided via SNI, but no hostname provided in HTTP request

On some Android phones when making SSL requests to my domain. This is despite ensuring that the Host header is set on the client.

I have also tried setting:

SSLStrictSNIVHostCheck off

In my apache conf, but I still see this error. Can someone point me a way forward?

JordanC
  • 141
  • 2
  • According to [wiki.apache.org](https://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI#SNI.2FRequest_hostname_mismatch.2C_or_SNI_provides_hostname_and_request_doesn.27t.), it's a browser bug, and Apache will reject these requests with a 400 error. I don't think it's possible to change this behaviour in Apache; you might need to change to nginx instead. – bennettp123 May 08 '14 at 08:04
  • Is it a browser bug in the sense that they aren't sending the correct headers? If necessary I can control/change the request. – JordanC May 08 '14 at 09:52
  • Correct: the client is sending incorrect headers. According to Apache, that is. The SSLStrictSNIVHostCheck allows clients to access vhosts without using SNI. However, your android clients _are_ using SNI without setting the Host header in the HTTP request. The [rfc](http://tools.ietf.org/html/rfc6066#page-6) isn't quite so clear: it states that clients should not do this, but it doesn't actually define what the server should do if it does: `If the server_name is established in the TLS session handshake, the client SHOULD NOT attempt to request a different server name at the application layer`. – bennettp123 May 12 '14 at 00:50
  • (And also in this case, the clients aren't actually specifying a _different_ server name at the application layer; they're specifying _no_ server name at the application layer). In a nutshell, SNI requests need a matching Host: header in the HTTP request. – bennettp123 May 12 '14 at 00:52
  • Thanks for helping me out. Is it just the regular "Host:" header or is it something specifically in the SSL handshake. Because I have verified that the Host: header seems to be sending OK. – JordanC May 13 '14 at 00:59

1 Answers1

2

According to this report https://code.google.com/p/android/issues/detail?id=35050 your problem could also arise from a bug in Androids implementation of the libcore/luni/src/main/java/libcore/net/http/HttpConnection.java.

Due to this bug the SNI at the TLS layer is the hostname of the proxy instead of the hostname provided in the HTTP request URL it should actually be.

So any app using the android version < 4.1.2 (it was fixed on Jul 20, 2012) implementation of the HttpConnection might cause this behavior.

Christian.D
  • 121
  • 3