[squid-dev] Fake CONNECT requests during SSL Bump

[Marcus Kool]

On 09/26/2015 10:21 PM, Amos Jeffries wrote:
> On 24/09/2015 11:40 p.m., Marcus Kool wrote:
>>
>> On 09/24/2015 02:13 AM, Eliezer Croitoru wrote:
>>> On 23/09/2015 04:52, Amos Jeffries wrote:
>>>> Exactly. They are processing steps. Not messages to be adapted.
>>>>
>>>> Amos
>>>
>>> +1 For that.
>>>
>> [...]
>>
>>> In any case the bottom line from me is that for now ICAP and ECAP are
>>> called ADAPTATION services and not ACL services.
>>> It can be extended to do so and it's not a part of the RFCs or
>>> definitions and it might be the right way to do things but it will
>>> require simple enough libraries that will let most admins (if not all)
>>> to be able to implement their ACL logics using these
>>> protocol\implementations.
>>>
>>> Eliezer
>>
>> ICAP is an adaptation protocol that almost everybody uses for access
>> control.
>
> Which is wrong way to do it in many cases. All the effort put into
> avoiding the use of correct APIs is frustrating.
>
> Adaptation is for adaptation, not authorization.
>
>>
>> The ICAP server must be able to see all traffic going through Squid so
>> that it can do what it was designed for and block (parts) of websites
>> and other data streams.
>
> Blocking *parts* of websites is not access control. It is censorship and
> copyright violation.

We may interpret the words "parts of websites" differently.  I find
removing an ad or a tracking java script not censorship nor a violation.
Even if you want to call removing ads censorship, it is _desired_ censorship,
i.e. censorship in the good sense of the word, like you censor a child not
to see everything that the world offers.

> Rejecting the requests with 451 status is the correct (and legal) way to
> go about that.
>
>
>> Other data streams may not be HTTP(S)-based and hence are not bumped,
>> but for the ICAP server to be able to do its thing, it still needs a
>> (fake) CONNECT.
>>
>> Going back to Steve's original message, I think that it is not necessary
>> to generate a (fake) CONNECT for each bump step,
>> but to send exactly one CONNECT at the moment that Squid makes a
>> decision.  I.e. when Squid decides to bump or splice.
>>
>
> No. CONNECT means a change of traffic protocols is happening on the
> connection.
>
> Specifically it is a placeholder for the request message that would have
> been sent by the client if it was using an explicit-proxy and the
> protocol stack was being changed properly by an explicit HTTP layer
> CONNECT message, instead of intercepted.
>
>
> The first layer protocol received is TCP.
>
>   - If that was intercepted we use a CONNECT with raw-IP to represent the
> machine NAT subsystem requesting a tunnel.
>    + Explicit proxies this actually exists as bytes of on-wire message
> and can have domain names from the client.
>
>   - If that HTTP-over-TCP CONNECT request is allowed it gets serviced,
> maybe adapted. Otherwise it gets rejected.
>
>   - If ssl_bump says to do anything other than splice with it ...
>
>
> The second layer protocol is TLS-over-HTTP (-over-TCP).
>
>   - If the connection was intercepted and SNI was now found to be present.
>     + We reset (some of) the connection state and go back to "first layer
> protocol" processing but using the SNI instead of raw-IP.
>     + For the *sole* reason of better emulating the real explicit-proxy
> behaviour. Otherwise...
>
>   - If splicing is chosen the tunnel is enacted.
>
>   - If bumping is done ...
>
>
> The third protocol is HTTP-over-TLS (-over-HTTP-over-TCP).
>
>   - If that HTTP(S) request is allowed it gets serviced, maybe adapted.
> Otherwise it gets rejected.
>
>
> ** Interception proxies run through later 1, maybe 1 again and 3.
> ** Explicit proxies run through layer 1 and 3.
>
>
> IMO we are better off removing the raw-IP CONNECT by always peeking at
> the SNI than going the other way and adding more repeated CONNECT
> processing.
>
> Contextually a second CONNECT for explicit proxy is meaningless since
> the SNI value is just the FQDN used for all the bumped HTTPS requests
> URLs. There is no real HTTP message or even a protocol change action for
> the adaptation to associate a client response with.

Sorry, I read your response 3 times, but I fail to understand the point.
What is wrong with Squid sending exactly one message to an ICAP server
when a CONNECT message is being bumped ?

Marcus

> One part lacking that we do need to fix soonish is to add hostVerify
> logics to enforce the inner layer (3) messages Host: header == SNI
> security requirement.
>
> Amos
> _______________________________________________
> squid-dev mailing list
> squid-dev at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>