On 07/06/2016 11:36 AM, Steve Hill wrote:
I'm using a transparent proxy and SSL-peek and have hit a problem with an iOS app which seems to be doing broken things with the SNI. The app is making an HTTPS connection to a server and presenting an SNI with a wildcard in it - i.e. "*.example.com". I'm not sure if this behaviour is actually illegal, but it certainly doesn't seem to make a lot of sense to me. Squid then internally generates a "CONNECT *.example.com:443" request based on the peeked SNI, which is picked up by hostHeaderIpVerify(). Since *.example.com isn't a valid DNS name, Squid rejects the connection on the basis that *.example.com doesn't match the IP address that the client is connecting to. Unfortunately, I can't see any way of working around the problem - "host_verify_strict" is disabled, but according to the docs, "For now suspicious intercepted CONNECT requests are always responded to with an HTTP 409 (Conflict) error page." As I understand it, turning host_verify_strict on causes problems with CDNs which use DNS tricks for load balancing, so I'm not sure I understand the rationale behind preventing it from being turned off for CONNECT requests?
An SNI with a wildcard indeed does not make sense. Since Squid tries to mimic the behavior of the server and of the client, it deserves a patch where instead of doing a DNS lookup and then doing a connect (based on the result of the DNS lookup?), Squid simply connects to the IP address that the client tries to connect to and does the TLS handshake with the SNI (that does not make sense). This way it mimics the client a bit better. Marcus _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
