[squid-users] host_verify_strict and wildcard SNI

Thu Jul 7 07:37:06 UTC 2016

Couple thoughts Alex,

Currently the basic splice rules are being used with regex which means that they can work with wildcard.
And I can understand the argument of a client wanting some wildcard domain but I do not know about an application that actually
tries to uses such logic.

There are cases which the RFC do leave the open minds to get wild and I am not saying if these are right or wrong but,
they do states it's a hostname and not a certificate common name or some v3 component.

Practically some client can try to contact some arbitrary website and there are couple aspects to it.
If a user tries to connect to a site using a company proxy, then what companies will want to allow?
Would large companies allow such a connection to be spliced, or maybe they will want to inspect this connection deeper?
What about ISP's, these mostly care about cache and not about ACL's, while there are many who uses squid for content filtering.

>From where anyone understands, a wildcard should never be required to be tested against any DNS server in the current state of the internet since these do have a strict policy to honor only valid hostname characters.
Maybe the future will bring the wildcard into the DNS world, should we consider such an option even if the RFC tends to minimize and containerize the options?

Thanks,
Eliezer

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: eliezer at ngtech.co.il

-----Original Message-----
From: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] On Behalf Of Alex Rousskov
Sent: Thursday, July 7, 2016 4:07 AM
To: squid-users at lists.squid-cache.org
Subject: Re: [squid-users] host_verify_strict and wildcard SNI

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.

_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users