Re: filtering HTTPS

On 03/14/2012 05:20 PM, Marcus Kool wrote:
>> But again, why not using ACLs to avoid applying sslBump on applications
>> like skype?
>
> What ACL do you have in mind?

There are cases where you can find out the application type from the
HTTP headers included in CONNECT request. Specially for skype I think
you can use in such acls the destication servers (... whitelists).
But OK we have already discuss this one and it is not what you need...

>> Case 1: The server is an SSL server
>> 1a) The squid-to-server connection fails with an SSL error (and
>> maybe the connection dropped, if the error can not be ignored).
>
> depends on the SSL error. If the handshake fails the server endpoint
> probabley has no SSL.
>
>> 1b) Squid initiates an SSL handshake with the client and wait the
>> first GET (or other request, tunnelled through client-to-squid SSL
>> handshake)
>
> issue: we know the server has SSL but do not know if it has
> SSL+HTTP.
> it might be SSL+SMTP or SSL+anything
>
>> 1c) Read the GET request from client and send it to the ICAP server
>> WITH the "X-Squid-SSLhandshakeResult" header.
>
> Here is an interesting phase. Reading the data from the client
> gives us a clue if the CONNECT is for SSL+HTTP.
> Note that a server can send data before the client sends data.
> If there is a GET/HEAD/POST we assume SSL+HTTP and the filter
> can be asked for a decision.
> If there is no "GET/HEAD/POST" the CONNECT is not to and SSL+HTTP
> endpoint and also the filter should decide on what to do.
>
>> 1d) Squid send the error page to the web client. Or any possible
>> error/deny page from ICAP server. Or just ignore the SSL error (eg an
>> error certificate expired) and continue as normal.
>
> sslBump takes over the certificate checking for a community of
> users.
> IMHO Squid may *never* allow unsafe connections. One should
> be extremely careful here. I am in favor of modifying
> squid.conf.documented to suggest a Squid admin to publish to all
> users which sites are not checked for having valid certificates.
OK. The Bump-Server-First feature is comming with the "Mimic original
SSL server certificate" feature:
  http://wiki.squid-cache.org/Features/MimicSslServerCert
Which allow the final user to decide if he should accept a connection to
a web server with a non valid certificate.

The "case 1" (the server is an SSL server and it is HTTP like protocol)
I am describing here can be implemented inside squid.

But my opinion is what you need for "case 2" (the server is not an ssl
server) is not easy to be implemented.....

>
>> Case 2) The server is not an SSL server:
>> 2a) Squid does not initiate SSL handshake with the client, and allow
>> CONNECT request continue without ssl bump.
>
> Here the filter remains necessary. In another thread there was
> a slight favor for implementing a filter pipe in tunnel mode.
>>
>>
>> Am I correct? Is this what you need?
>
> In an other thread I wrote this:
>
> I think Squid should do the following in the sslBump handler:
>
> - Open socket. If error, close socket to the browser.
> - *possibly*: go to the filters indicating the start of a CONNECT, a
> filter may decide to BLOCK just based on the endpoint address.
> - Initiate SSL/TLS handshake, if error, signal filters (preferably
> indicating there is no SSL/TLS)
> If the filter says "PASS", reopen a socket to have a clean tunnel
> - If the SSL/TLS handshake is ok, do the certificate checking. If error,
> send an erroneous certificate to the browser to give the end user a good
> idea of what is going on.
> - Verify that the server speaks SSL+HTTP, if not signal filters
> (preferably indicating there is SSL/TLS but no HTTP)
> - If the endpoint speaks SSL+HTTP, go to the filters, indicating a
> succesful CONNECT to an SSL+HTTP endpoint.
>
> The implementation of the second step is a trade off between a delay of
> the roundtrip to the filter and preventing unnecessary SSL handshakes
> for blocked endpoints.
>
> I do not know much about Squid internals, so maybe the suggested logic
> needs to be changed a little.
>
> Marcus
>
Received on Wed Mar 14 2012 - 16:02:03 MDT