[squid-users] host_verify_strict and wildcard SNI

[Yuri]

07.07.2016 19:08, 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.
Interestingly, Marcus. Does this mean that the CDN may be at different 
points in time different IP connection and it makes it impossible for 
client connections through Squid?
>
> Marcus
>
>> Amos
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users