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

[Amos Jeffries]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 20/12/2014 7:27 a.m., Tsantilas Christos wrote:
> Currently peek-and-splice mode have the following bug: 1) When the 
> certificate validation procedure found that the certificate is 
> invalid, splice action is selected and the certificate validator 
> helpers are not used it will splice the connection (even if 
> certificates found invalid).
> 

Okay. "transparent" is good there.


> 2) When server sends a malformed or unsupported Hello response, 
> squid may splice the connection if splice action is configured.
> 
> This patch, cause squid to return an error page to the user for 
> both cases.
> 
> But about the (2) I need squid developers opinions:
> 
> a) Should we abort with an error when a malformed or unsupported 
> server hello message received? In this case the user may be able
> to control squid behaviour using cert_validator helpers: squid
> will send empty certificates list, and cert validator can respond
> with en error.
> 
> b) Abort with an error, if the server response can not be parsed.
> 


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.


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.

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".

Amos

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUlISSAAoJELJo5wb/XPRjRnkIANo6hCm5qxVmDNUC7Ium4fCv
lP9TrNXKcwMYSuFU325QswFXKwhSLctnVq4+yTiaKwU4zbjFqjXVN4qbbBNcjgt9
CikN9d6p5HHKUfOrONRMkih0RxihpvgKFG4REa2UByQQerwpWmZuCZ3a6/74nulT
0eRUmTsVL+bRSIft2TqPjnz4x7xlXA1wqIQdxQSGB/Ew/Ms3Ip6UsAu2tSOAx78D
U63U2SBL770L3cWJw/VVnRd3/FPnSKQk5fTt4K9qSv171yQfaxMOJ+8zJUVaHOZi
v/Bpaet0dJoD10SwRWQK7kM3Vb0umPqy1lBJKNcGfin322WIB2XZJnbRAdOd7Ck=
=WFtK
-----END PGP SIGNATURE-----