Added host name parsing from the client, so that a hostname, rather t…

[aviramc]

…han an IP

address will be sent in http-connect. This can be expanded for the other types
of relays.
In order to use the feature, one should add the directive 'parse_host' to the
configuration file. Its value can be either "sni" or "http_host".

For "sni", the client is expected to send an SSL client hello with the SNI
extenion containing the server name.
For "http_host" the clien is expected to send an HTTP request with the Host
header.

If the hostname is received, it will be placed (including the port to which
the connection was intended) in the CONNECT method that is sent to the proxy.

[lensen]

I'd like to 'second' this pull request. Can be very helpful with Squid ACLs based on hostnames (Google Cloud Platform for example).

[lensen]

This patch does seem to break any requests going to an IP instead of hostname.

~ # curl -I https://www.googleapis.com --resolve 'www.googleapis.com:443:172.217.17.41'
HTTP/1.1 404 Not Found
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Date: Mon, 03 Apr 2017 09:37:05 GMT
Vary: X-Origin
Content-Type: text/html; charset=UTF-8
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Server: GSE
Alt-Svc: quic=":443"; ma=2592000; v="37,36,35"
Transfer-Encoding: chunked
Accept-Ranges: none
Vary: Origin,Accept-Encoding

1491212224.906450 info redsocks.c:1459 redsocks_accept_client(...) [10.0.0.1:51128->172.217.17.41:443]: accepted
1491212225.022778 info redsocks.c:982 redsocks_hostname_reader(...) [10.0.0.1:51128->172.217.17.41:443]: searching for hostname by sni
1491212225.022834 info redsocks.c:994 redsocks_hostname_reader(...) [10.0.0.1:51128->172.217.17.41:443]: found hostname www.googleapis.com, now connecting
1491212225.061087 info redsocks.c:689 redsocks_drop_client(...) [10.0.0.1:51128->172.217.17.41:443]: connection closed

~ # curl -I https://172.217.17.41
curl: (35) Encountered end of file

1491212235.217968 info redsocks.c:1459 redsocks_accept_client(...) [10.0.0.1:51132->172.217.17.41:443]: accepted
1491212235.328921 info redsocks.c:982 redsocks_hostname_reader(...) [10.0.0.1:51132->172.217.17.41:443]: searching for hostname by sni
1491212235.328968 info redsocks.c:707 redsocks_drop_client(...) [10.0.0.1:51132->172.217.17.41:443]: dropping client (R/W), relay (R/W), idle 0.111017s

The latter never ends up at the proxyserver.

[wheelerlaw]

Any update on this? I've been using Redsocks for a while now and I'm beginning to notice several websites stop working (just certificate errors) because they are requiring SNI.

[andronoob]

This patch doesn't work for me, the connection was just stuck. The proxy server received nothing more than HTTP CONNECT header.

Sorry, I had rebuilt redsocks without this patch, then it still didn't work, so that it's more likely to be related to my OS, rather than this patch.

Update: after applying libevent-2.1-compat.patch, redsocks seems to be working. Same as #123

[andronoob]

out-of-bounds?