[squid-dev] [PATCH] invalid certificates and spliced connections

Tsantilas Christos chtsanti at users.sourceforge.net
Mon Dec 22 15:24:04 UTC 2014


On 12/19/2014 10:03 PM, Amos Jeffries wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 20/12/2014 7:27 a.m., Tsantilas Christos wrote:
>
> Okay. "transparent" is good there.
>
>
> A) Consider that CONNECT is always attempted being bumped, but non-TLS
> protocols exist within CONNECT.
>   Also non-TLS protocols over port 443.
>   Also SSL v1 / v2 / v3 over port 443 when the library used by Squid
> has all support and knowledge of those protocols removed.
>
> According to at least one user report Skype uses a TLS look-alike
> clientHello and something strange as serverHello. So we may not be
> able to rely on clientHello to indicate TLS. I dont know for certain
> the accuracy of that, you may have observed it or know differently.

ok.

>
>
> B) Remember that TLS is about *security*. In security decision making
> you validate strictly and if it fails to pass you abort (fail closed)
> quickly with nothing or a code containing as few details as necessary
> to be clear something is wrong.
>
>
> In the (A) vs (B) cases above the errors are all internal to TLS. No
> need to get HTTP involved if we can avoid it. If there is a TLS alert
> code to signal malformed traffic, use it, otherwise just abort.

It is not very easy to correctly handle all of the openSSL error 
messages. My sense is that it will be difficult to maintain it ...


> Possibly a fast ACL is appropriate:
>     ssl_bump_error allow/deny [acls...]
>
> Which is run to make the above decision. ONLY in the event that TLS
> protocol syntax errors or malformations.  Not for cert/cipher/option
> issues such as bad combinations of valid things, or insecure settings.
>   Default action on this *_error directive should be "deny all".

I believe it is OK to let this patch as is for now.
This patch will abort imediatelly:
  - If no certificate found and checked using squid ssl verify procedure 
(mostly because the server response was malformed, or unsupported)
  - if a server certificate validation failed

I believe this is handles most of the cases. The cipher or option issues 
may still be ignored, but this errors may caused because of unsupported 
features by openSSL library we are using.
But still we have verify server certificates, and this is should be 
enough for security.


>
> Amos
>



More information about the squid-dev mailing list