[squid-users] host_verify_strict and wildcard SNI

[Alex Rousskov]

On 07/06/2016 05:01 PM, Marcus Kool wrote:
> 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.


> An SNI with a wildcard indeed does not make sense.

There are three rather different questions to consider here:

1. Is wildcard SNI "legal/valid"?
2. Can wildcard SNI "make sense" in some cases?
3. What should Squid do when receiving a wildcard SNI?


Q1. Is wildcard SNI "legal/valid"?

I do not know the answer to that question. The "*.example.com" name is
certainly legal in many DNS contexts. RFC 6066 requires HostName SNI to
be a "fully qualified domain name", but I failed to find a strict-enough
RFC definition of an FQDN that would either accept or reject wildcards
as FQDNs. I would not be surprised if FQDN syntax is not defined to the
level that would allow one to reject wildcards as FQDNs based on syntax
alone.


Q2. Can wildcard SNI "make sense" in some cases?

Yes, of course. The client essentially says "I am trying to connect to
_any_ example.com subdomain at this IP:port address. If you have any
service like that, please connect me". That would work fine in
deployment contexts where several servers with different names provide
essentially the same service and the central "routing point" would pick
the "best" service to use. I am not saying it is a good idea to use
wildcard SNIs, but I can see them "making sense" in some cases.


Q3. What should Squid do when receiving a wildcard SNI?

The first two questions are not really important and each may not even
have a single "correct" answer. I am sure protocol purists can argue
about them forever. The last question is important, which brings us to:

> 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.

I believe that is what Squid does already but please correct me if I am
wrong.

When forming a fake CONNECT request, Squid uses SNI information because
that is what ACLs and adaptation services usually want to see. However,
I hope that intercepting Squid always connects to the intended
destination of the intercepted connection instead of trusting its own
fake CONNECT request.

Whether Squid should generate a fake CONNECT with a wildcard host name
is an interesting question:

1. A fake CONNECT targeting an wildcard name may break ACL-driven rules
and adaptation services (at least).

2. A fake CONNECT targeting an IP address instead of a wildcard name may
not give some ACL-driven rules and adaptation services enough
information to make the right decision.

3. A premature rejection of a connection with wildcard SNI does not
allow the admin to make the bump/splice/terminate decision.

#2 is probably the lesser of the three evils, but I wonder whether Squid
should also include the invalid host name as an X-SNI or similar HTTP
header in that CONNECT request, to give advanced ACLs and adaptation
services a better chance to work around known benign issues where the
admin knows the wildcard is not malicious (and to kill wildcard
transactions the admin knows to be malicious!).


A similar question can be asked about SNI names containing unusual
characters. At some point, it would be too dangerous to include SNI
information in the fake CONNECT request because it will interfere with
HTTP rules, but it is not clear where that point is exactly.


Cheers,

Alex.