1

We found out that calling a host like following using curl 7.21 or 7.24 does produce an error in the apache config (we have multiple SSL Vhosts!). Whereas the same command runs smooth with curl 7.34 and higher. Does anyone know why?

Command: curl https://192.168.0.1/version -H "Host: example.domain.com" -k

This should return a version like "1.2.1". It really does with newer curls (tested 7.34 and 7.38/39) but returns a 400 with curl 7.21/7.24.

When executing with an older curl, the apache returns this:

[error] Hostname 192.168.0.1 provided via SNI and hostname example.domain.com provided via HTTP are different

Normally i thought this could be a problem due to missing SNI support in curl, but i've read that SNI should have been added to curl 7.18 already.

sysadmin1138
  • 131,083
  • 18
  • 173
  • 296
martinseener
  • 149
  • 11
  • 1
    I would rather assume that the SNI value is still based on the URL while you have overridden the Host header to be something else. – Håkan Lindqvist Nov 10 '14 at 11:13
  • Can you explain that in more detail what you mean, please @HåkanLindqvist? – martinseener Nov 11 '14 at 08:52
  • I think what the previous commenter means is maybe this version of curl always uses the host header from the original URL (so you would need to set up dns, and then you might get it to work) - try using curl to fetch another https site (with dns) and see if the correct sni header is sent (use wireshark). Also worth looking at what ssl library curl is built against. – Tom Newton Nov 11 '14 at 19:49
  • While you're testing: try forcing a later tls version (1.2?) just for fun – Tom Newton Nov 11 '14 at 19:58
  • @TomNewton this is not (yet) possible since we only support TLS1.0 at the moment (disabled SSLv3 due to POODLE) and still using Squeeze Apache2 which only supports TLS1.0. but we will try! – martinseener Nov 13 '14 at 14:27

1 Answers1

1

The described behaviour is correct. SNI is based on the URL (192.168.0.1), host HTTP header is set manually by you (example.domain.com).

When Apache handles this request, it gets 192.168.0.1 in SNI and uses configuration for that vhost (probably default). However when the payload is decrypted it encounters a different host => ERROR.

Pavel Horal
  • 111
  • 3