[squid-users] A bunch of SSL errors I am not sure why

Sameh Onaissi sameh.onaissi at solcv.com
Wed Jan 18 23:53:30 UTC 2017


Hello, Amos… all

Yuri, thanks for the reply.


Amos,

I added: Thanks to Eliezer)
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER
to the config file, I am not too worried about the verification since the accessed sites showing problems are government site or local paying services/partners.

However, some sites are still showing the Handshake problem. https://ibin.co/38uz8akvWayM.png

You had previously replied to this saying:

"If you actually read that error message it tells you exactly what the
problem is.

"Handshake with SSL server failed: [blah blah codes]: dh key too small"

The server is trying to use a Diffi-Helman cipher with a too-short key.
DH cipher with short keys has recently been broken. By recently I mean
about a whole year ago.”

However, I still wonder what the solution is? is it possible to fix this? and who needs to fix it? is it a squid side error? is it an OS level error?

Any more information is greatly appreciated.






Thanks again,
Sam


On Jan 18, 2017, at 12:44 PM, Yuri Voinov <yvoinov at gmail.com<mailto:yvoinov at gmail.com>> wrote:



18.01.2017 23:40, Eliezer Croitoru пишет:
Thanks for the detail Amos,

I noticed that couple major Root CA certificates was revoked so it could be one thing.
And can you give some more details on how to fetch the certificated using the openssl tools?
(Maybe redirect towards an article about it)
There is no article about trivial things.

root @ khorne / # openssl s_client -connect symantec.com<http://symantec.com>:443
CONNECTED(00000003)
depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU =
"(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class
3 Public Primary Certification Authority - G5
verify return:1
depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network,
CN = Symantec Class 3 EV SSL CA - G3
verify return:1
depth=0 1.3.6.1.4.1.311.60.2.1.3 = US, 1.3.6.1.4.1.311.60.2.1.2 =
Delaware, businessCategory = Private Organization, serialNumber =
2158113, C = US, postalCode = 94043, ST = California, L = Mountain View,
street = 350 Ellis Street, O = Symantec Corporation, OU = Symantec Web -
Redir, CN = symantec.com
verify return:1
---
Certificate chain
0
s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/businessCategory=Private
Organization/serialNumber=2158113/C=US/postalCode=94043/ST=California/L=Mountain
View/street=350 Ellis Street/O=Symantec Corporation/OU=Symantec Web -
Redir/CN=symantec.com
  i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec
Class 3 EV SSL CA - G3
1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec
Class 3 EV SSL CA - G3
  i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006
VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public
Primary Certification Authority - G5
2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006
VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public
Primary Certification Authority - G5
  i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006
VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public
Primary Certification Authority - G5
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIJ7jCCCNagAwIBAgIQGxlwar89MNsXoPlBKLC9ZjANBgkqhkiG9w0BAQsFADB3
MQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd
BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxKDAmBgNVBAMTH1N5bWFudGVj
IENsYXNzIDMgRVYgU1NMIENBIC0gRzMwHhcNMTYwNjEzMDAwMDAwWhcNMTcwNjEz
MjM1OTU5WjCCARsxEzARBgsrBgEEAYI3PAIBAxMCVVMxGTAXBgsrBgEEAYI3PAIB
AgwIRGVsYXdhcmUxHTAbBgNVBA8TFFByaXZhdGUgT3JnYW5pemF0aW9uMRAwDgYD
VQQFEwcyMTU4MTEzMQswCQYDVQQGEwJVUzEOMAwGA1UEEQwFOTQwNDMxEzARBgNV
BAgMCkNhbGlmb3JuaWExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcxGTAXBgNVBAkM
EDM1MCBFbGxpcyBTdHJlZXQxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9u
MR0wGwYDVQQLDBRTeW1hbnRlYyBXZWIgLSBSZWRpcjEVMBMGA1UEAwwMc3ltYW50
ZWMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwRqh8lRuQgtO
ZDvGmr2+JKD5dgS8do3CQttE0wUosst5uMBoI0JdWCcD+dBKBMf+5PD2TZie75qY
Dwg4TPWhiJhLVDtriB4xPHIaI3l4HNyiC2QbCYIlNxiYBApEX3xi7V94ZJBiQGhD
jBjVBlWTwYMgcEP+1ivUL0h/ShZOjcJaqdlvLrne7WFQVDzcGcezqXEovgl/63sB
5tL0MDY5lpqUIllNLoMhk+o/NAu19NSQRTqVPmfSQZIQM/aki70LKQWmXzM7yjWk
TYVfoqgj7zE9fwfyEZ3mdohSkxaNKdbnafCLHI6Yzc9t9wnnmYvBWDfTCSE+kdYC
m/hEfFJaTQIDAQABo4IFzjCCBcowggNqBgNVHREEggNhMIIDXYIMc3ltYW50ZWMu
Y29tggpub3J0b24uY29tggt2ZXJpdGFzLmNvbYISYWNjb3VudC5ub3J0b24uY29t
ghRjYXJlZXJzLnN5bWFudGVjLmNvbYIZY3VzdG9tZXJjYXJlLnN5bWFudGVjLmNv
bYIOZGUubm9ydG9uLm1vYmmCGmRvd25sb2Fkcy5ndWFyZGlhbmVkZ2UuY29tghFl
bWVhLnN5bWFudGVjLmNvbYIQZXUuc3RvcmUucGdwLmNvbYIRam9icy5zeW1hbnRl
Yy5jb22CFW1vc3RkYW5nZXJvdXN0b3duLmNvbYITbXlub3J0b25hY2NvdW50LmNv
bYIQbmEuc3RvcmUucGdwLmNvbYIRbm9ydG9uYWNjb3VudC5jb22CFW5vcnRvbmxl
YXJuaW5naHViLmNvbYIKbnVrb25hLmNvbYIRcm93LnN0b3JlLnBncC5jb22CEHNz
bC5zeW1hbnRlYy5jb22CDXN0b3JlLnBncC5jb22CEHVrLnN0b3JlLnBncC5jb22C
Fnd3dy5hY2NvdW50Lm5vcnRvbi5jb22CFXd3dy5lbWVhLnN5bWFudGVjLmNvbYIZ
d3d3Lm1vc3RkYW5nZXJvdXN0b3duLmNvbYIVd3d3Lm5vcnRvbmFjY291bnQuY29t
ghl3d3cubm9ydG9ubGVhcm5pbmdodWIuY29tgg53d3cubnVrb25hLmNvbYILd3d3
LnBncC5jb22CFHd3dy5zc2wuc3ltYW50ZWMuY29tgg93d3cudmVyaXRhcy5jb22C
End3dy5zeW1hbnRlYy5jby5qcIISd3d3LnN5bWFudGVjLmNvLnVrgg93d3cuc3lt
YW50ZWMuZnKCD3d3dy5zeW1hbnRlYy5kZYIPd3d3LnN5bWFudGVjLml0ghN3d3cu
c3ltYW50ZWMuY29tLmF1ghJ3d3cuc3ltYW50ZWMuY28ua3KCE3d3dy5zeW1hbnRl
Yy5jb20uYnKCD3d3dy5zeW1hbnRlYy5teIIPd3d3LnN5bWFudGVjLmVzgg93d3cu
c3ltYW50ZWMuY2GCD3d3dy5zeW1hbnRlYy5oa4ISd3d3LnN5bWFudGVjLmNvLmlu
gg93d3cuc3ltYW50ZWMudHeCD3d3dy5zeW1hbnRlYy5zZzAJBgNVHRMEAjAAMA4G
A1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwbwYD
VR0gBGgwZjAHBgVngQwBATBbBgtghkgBhvhFAQcXBjBMMCMGCCsGAQUFBwIBFhdo
dHRwczovL2Quc3ltY2IuY29tL2NwczAlBggrBgEFBQcCAjAZDBdodHRwczovL2Qu
c3ltY2IuY29tL3JwYTAfBgNVHSMEGDAWgBQBWavn3ToLWaZkY9bPIAdX1ZHnajAr
BgNVHR8EJDAiMCCgHqAchhpodHRwOi8vc3Iuc3ltY2IuY29tL3NyLmNybDBXBggr
BgEFBQcBAQRLMEkwHwYIKwYBBQUHMAGGE2h0dHA6Ly9zci5zeW1jZC5jb20wJgYI
KwYBBQUHMAKGGmh0dHA6Ly9zci5zeW1jYi5jb20vc3IuY3J0MIIBBgYKKwYBBAHW
eQIEAgSB9wSB9ADyAHcA3esdK3oNT6Ygi4GtgWhwfi6OnQHVXIiNPRHEzbbsvswA
AAFVS+V56QAABAMASDBGAiEAlwG/vUrML+CkdGkmUuyjvTHeWMaIvR409GHqmKjC
LAoCIQDSg0zyzCM7ORf0yF/ZaAqQpuWbm+mSSUXp6lRmP29BrwB3AKS5CZC0GFgU
h7sTosxncAo8NZgE+RvfuON3zQ7IDdwQAAABVUvlegwAAAQDAEgwRgIhAMimfbuI
vtq3d1b5fbkjtmrZ5SKi0kI/7BX32AU3ApXOAiEAvVHUc3PNoZiUq5ryyQeqWR1q
1j8QzHlUf8xeFVes7iMwDQYJKoZIhvcNAQELBQADggEBAB4Ve4SAScHpnOtq3I6m
buH90PEoq0m9503ooEwywvZOeqQOQwDmqOJZsraznC70kmWlr5UY5Yd2eUph6IR+
6VdaJQlfbMhGc60JVZi8Pewk+clo/CyX6CTmwwh0nJ2Q5blcgGRLvdWEOumK16ET
MGV5VCXFWExTFYGleYvsAAH8AMYf3f+k9qB3vu6YljKzp1mv/NJL29kmhciY7oaR
wLbzicQbK6uEuZfM7+HmM/bW0UGJPOHgpv+os6kQSSxx4w3BhizpIid4v+5VS+8o
XLxAH5+bfEsaMQMNfEddxXT9Y/2Ly2IAr24EQn3s+SsdP9oc5dTTTVacikz3tQCA
JfU=
-----END CERTIFICATE-----
subject=/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/businessCategory=Private
Organization/serialNumber=2158113/C=US/postalCode=94043/ST=California/L=Mountain
View/street=350 Ellis Street/O=Symantec Corporation/OU=Symantec Web -
Redir/CN=symantec.com
issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust
Network/CN=Symantec Class 3 EV SSL CA - G3
---
No client certificate CA names sent
---
SSL handshake has read 5624 bytes and written 433 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
   Protocol  : TLSv1.2
   Cipher    : ECDHE-RSA-AES128-SHA
   Session-ID:
7ED48810D697DDAE5C591942755CF47E3D96431EC46C074641B5E1363ABE812E
   Session-ID-ctx:
   Master-Key:
68B42DE89E49E2F16E7461853B9CD8F5393955C9A8C3B6DB27A560CD753669285C51FEA33C2324694F1AA43B833021E8
   Key-Arg   : None
   PSK identity: None
   PSK identity hint: None
   SRP username: None
   Start Time: 1484761429
   Timeout   : 300 (sec)
   Verify return code: 0 (ok)
---
^C

That's all.
I think that if some sites are have issues then a simple script that will run the openssl tools to fetch the certificates and add them to the system can be useful for those which are running 3.5 and yet to jump into the 4.0 testing.
I can write the script that will do come of the work for these admins.

Eliezer

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: eliezer at ngtech.co.il


-----Original Message-----
From: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] On Behalf Of Amos Jeffries
Sent: Wednesday, January 18, 2017 6:06 PM
To: squid-users at lists.squid-cache.org
Subject: Re: [squid-users] A bunch of SSL errors I am not sure why

On 19/01/2017 3:29 a.m., Sameh Onaissi wrote:
Hello Eliezer, all

Sorry for the late reply.

When I configure the browser to access a non intercept port, the errors do not show up and the site is accessed without a problem.

The client machine has the .crt file installed, but still shows the error.

Other pages with errors:
http://pasteboard.co/nA20FD7om.png
http://pasteboard.co/nA2yWRyTE.png

Here is the second page in a browser without an intercepted port:
http://pasteboard.co/nA39CEFGU.png


Thanks in advance.
Some of these sites are used to pay company bills, so it’s important to get this issue resolves ASAP.
I assume from that first part that the most important of these sites are a small enough set to deal with as a special case without becoming a maintenance nightmare.

The error messages both show that Squid at least cannot find one of the CA required to verify the servers cert.

Soo...
you can probably use the openssl client tool to identify and fetch the certs manually; then

1a) add the root CA (only if needed) into your machines global CA set,

1b) add any intermediary certs to the file Squid loads through sslproxy_foreign_intermediate_certs directive.
<http://www.squid-cache.org/Doc/config/sslproxy_foreign_intermediate_certs/>

OR

2) create a cache_peer to the domains server port 443, using the originserver option and sslcafile= option to specify what its CA chain is supposed to be.
<http://www.squid-cache.org/Doc/config/cache_peer/>


Worth mentioning that this was not a problem about 10 days ago.
Nod, these types of things can appear out of nowhere as servers certs expire or get blacklisted, ciphers etc suddenly get rejected by browsers as insecure. TLS advocates deny it, but F*ups happen far too often in reality when dealing with certs.



* Try the latest Squid-4, which can auto-download intermediate certificates.

Is squid-4 stable for production?

Sorry I missed this in your earlier post.

Well strictly speaking no. It still has a handful of critical bugs to be tracked down and quashed. But whether those affect you, or if they do whether its worth an occasional crash to avoid these SSL isues is a different matter.

Amos

_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

--
OpenSource should be called "Fifty shades of Brown"
<0x613DEC46.asc>_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20170118/462e673a/attachment-0001.html>


More information about the squid-users mailing list