[squid-users] after changed from 3.4.13 to 3.5.8 sslbump doesn't work for the site https://banking.postbank.de/

[Amos Jeffries]

On 3/10/2015 7:08 a.m., Jason Haar wrote:
> On 02/10/15 23:43, Amos Jeffries wrote:
>> I'm suspecting the order of these options screws things up. Or maybe
>> just the use of "ALL". sslproxy_options NO_SSLv2:NO_SSLv3:ALL
> 
> ...but I don't even use sslproxy_options.... There have been at least 3
> people saying that bump doesn't work with that site - we all won't have
> identical configs.
> 
> Chrome reports "ERR_CONNECTION_CLOSED" and Firefox "The connection to
> banking.postbank.de was interrupted while the page was loading." - that
> doesn't even sound cert-related - more TCP related (between client and
> squid). Remember: the site works fine when squid is set to splice that site
> 
> I have compared the fake cert generated by squid against the real one
> and there's obvious differences (using "openssl s_client -connect
> banking.postbank.de:443 -servername banking.postbank.de|openssl x509
> -noout -text"). References to "Certificate Policies" and "Certificate
> Transparency" are present in the real cert and there's no equivalent in
> the Fake cert. How that could trigger a TCP reset is beyond me? I've
> also cranked up logging and there was nothing overt showing an issue
> 
> Real:
> 
>              X509v3 Certificate Policies:
>                 Policy: 2.16.840.1.113733.1.7.23.6
>                   CPS: https://d.symcb.com/cps
>                   User Notice:
>                     Explicit Text: https://d.symcb.com/rpa
>            X509v3 Basic Constraints:
>                 CA:FALSE
>            1.3.6.1.4.1.11129.2.4.2:
>                 ...k.i.w.......X......gp
> .....N.........H0F.!......<
> ...u.V.../.......D.>.Fv....\....U.......N...J.....F0D.
> .W!....z...@'..n...C.W ....m.K/..
> ....S.R,...K....T....u..)e.......w.h....d..:...(.L.qQ]g..D.
> g..OO.....N.........H0F.!.....~F.n#
> Y..&^.v.....x.+........!..n..J at 9.[.....J.C.1.L5.(.%%..9..
>     Signature Algorithm: sha256WithRSAEncryption
> 
> 
> Fake:
> 
>             X509v3 Basic Constraints:
>                 CA:FALSE
>     Signature Algorithm: sha256WithRSAEncryption
> 

Those bits how the origin certificate to be an EV (Extended Validation)
certificate issued by Symantec. That could be causing trouble. I've not
looked into EV in particular detail, but it is supposed to be one of the
better ways to use TLS to prevent MITM like ssl-bump.


Also, Symantec have had a unusually large amount of trouble getting
certain of their CA certs to stay in the global trusted set. Something
to do with the clients they vouch for turning out to be bad, and again,
and again.
 Anyhow, there have been long periods (12-18 months IIRC) where they
were not trusted as a global CA. If your CA certificates set is from one
of those periods your Squid will not be able to verify trust of the
origin cert.

Amos