[squid-users] host_verify_strict and wildcard SNI

[Marcus Kool]

On 07/07/2016 09:23 AM, Amos Jeffries wrote:
> 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.

Oops.  An application wants to connect to A.B.C.D has an SNI for foo.example.com
which resolves to A.B.C.D and A.B.C.E and Squid may connect the stream
to A.B.C.E... It is easy to imagine that some applications break with this behavior.

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

[snip]

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

yes, the fake CONNECT is dealt with like a regular CONNECT including
DNS lookup.  I fear for other apps (besides the one ios app that Steve
refers to) to break because Squid may connect to a different IP than
the client/app is requesting.
If Squid uses the original IP to connect without doing a DNS lookup,
Steve's app will work and potential issues with other apps are
prevented.

Marcus

> Amos