[squid-dev] Fake CONNECT requests during SSL Bump

[Amos Jeffries]

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.

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.

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