[squid-users] host_verify_strict and wildcard SNI

[Amos Jeffries]

On 7/07/2016 11:30 p.m., Marcus Kool wrote:
> 
> 
> On 07/07/2016 07:15 AM, Amos Jeffries wrote:
>> On 7/07/2016 1:55 p.m., Marcus Kool wrote:
>>>
>>>
>>> On 07/06/2016 10:07 PM, Alex Rousskov wrote:
>>>> 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.
>>>
>>> [snip]
>>>
>>>>
>>>> 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.
>>>
>>> Steve said that Squid rejects the connection because of a failed DNS
>>> lookup.
>>> So what is Squid doing?  Is it doing  the following ?
>>> - connect to the original IP
>>> - use the presented SNI to the server
>>> - do a DNS lookup and reject
>>
>> No it is doing Host: header verification on the faked CONNECT request
>> which uses the SNI in the Host: header value. This is not strictly
>> required for CONNECT messages, but does potentially prevent Squid using
>> other IPs than the original one the client was contacting.
> 
> Squid _has_ the original IP so why would Squid potentially connect to an
> other IP ?

Because the inbound and outbound connections are not related. The
outbound is normally done to any of the IPs that the request message
domain/Host header resolve to. It takes special circumstances (such as
failing the Host verification) to tie them together.

> 
>> If the SNI is a valid domain name (ie resolves in DNS). Then Squid
>> should continue on past the check.
> 
> Does Squid do a DNS lookup or only check the value for "valid" characters?

DNS lookup.

> 
>>>> 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.
>>>
>>> It is interesting to know if an ICAP server or URL rewriter is called
>>> and with which parameters when the ios app breaks.
>>>
>>>> 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!).
>>>
>>> I use url_rewrite_extras with "... sni=\"%ssl::>sni\" ..."
>>> so the URL redirector receives both the original IP address and
>>> the peeked SNI value to make its decisions.
>>> I agree that an ICAP service needs X-SNI or perhaps X-Squid-SNI to
>>> also get both the IP address and the SNI value.
>>
>> That is a problem for the service. Squid can already send anything in:
>> <http://www.squid-cache.org/Doc/config/adaptation_meta/>.
> 
> Which problem are you referring to?

I mean it as: IF it is a problem, then its a problem for the service
side of things since Squid can send the data fine.

> 
>> Maybe you have mistaken it for the inability of most ICAP services to
>> send things back to Squid in the same way.
> 
> The ICAP server needs both the IP and the SNI which Squid can be configured
> to do.  What do you suggest that an ICAP server needs to send back to
> Squid?

Sorry I misread your earlier post as implying Squid needs to be extended
to send those details.

> 
>>>> 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.
>>>
>>> To support the weirdest apps Squid might have to simply copy all
>>> unusual characters to present the same parameter values to the server.
>>
>> It is being mapped into the HTTP equivalent value. Which are Host:
>> header and authority-URI. Only valid FQDN names can make it through the
>> mapping.
> 
> Here things get complicated.
> It is correct that Squid enforces apps to follow standards or
> should Squid try to proxy connections for apps when it can?

Squid isn't enforcing standards here. As Steve original messge says it:
"generates a "CONNECT *.example.com:443" request based on the peeked SNI"
 - which is arguably invalid HTTP syntax, but oh well.

It then is unable to do a DNS lookup for *.example.com to find out what
its IPs are and does the error handling action for a failure to verify
on a CONNECT message.

Amos