On 09/05/2015 02:22 PM, Rafael Akchurin wrote:
Hello Xen,
The certificate warning was most probably indeed caused by default SHA-1 signature of the mimicked certificate in stock version of Squid present by default in popular Linux distribs. Latest version does that correctly and your "not private" connection warnings in Chrome/etc is now gone.
Please see http://docs.diladele.com/faq/filtering/chrome_not_private.html - I tried to explain it clearly.
Please note this is may also be caused by your trusted root certificates expiring in 2017+.
Hope other members of the list know better the cipher set. I am very interested in this too.
Best regards,
Rafael Akchurin
Diladele B.V.
Thank you mr. Diladele. Actually when I first ran into this I was using
your packaged version of Squid on Windows. I just couldn't get it
working, although I had a wrong certificate (generated in a different
way on Debian) at first and I didn't notice. But after that was fixed,
if I remember correclty, I still had the problems with Opera and Chrome.
I have no clue what changed now to remove this problem. Maybe my memory
is incorrect of this.
The Diladele Squid, of course, was a version 3.5
But if you say the SHA1 warning created the Invalid Certificate warning
(as you indicate) then perhaps I am mistaken about my Windows problems
now. In any case I upgraded and now it seems to work :).
Regards...
-----Original Message-----
From: squid-users [mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Xen
Sent: Saturday, September 5, 2015 1:58 PM
To: squid-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Default ssl-bump that works with chrome/opera
Hey,
Might I perhaps ask.
Currently with the default minimum configuration for ssl-bump that is advocated everywhere, my Firefox bumping works but Chrome and Opera are more strict and will say my certificate is invalid.
The certificate was simply generated (self-signed) with openssl x509 with no additional options for cipher or message digest or whatever.
Browsers typically complain that the certificate was signed using an insecure hash (sha1). I don't know if this is the result of my own certificate or whether it is the result of what Squid does to it using the regen it does.
Actually Chromium works fine now, I don't know why that change. I had so many problems with it.
In fact, I don't know what happened. Both Chromium and Opera now work.
I did upgrade to 3.5.7 but I tested after.
All browsers mostly complain about using obsolete cipher suites though.
So that is the question I wanted to ask: Is there a default SSL configuration for Squid that will limit or reduce or do away with those obsolete cipher questions and remarks?
I have been trying to find configs on the web, but they go into great technical detail about those ciphers and also require you to make difficult choices you can't make until and unless you are a security expert.
I believe going from RSA to ECDHE_ECDSA (or something similar) will do the trick. But I also read here about Squid supporting something only in version 4.
Even typing that word makes me sick. ECDHE_ECDSA buh.
Does it have to be anything more difficult :P.
Is there a smallest subset SSL configuration for Squid that will simply reduce those messages and allow the level of security of the original site not to go down as much? I would think that Squid doesn't communicate with that server any different than it does with me. So the whole chain is now using something less than it did before.
So that is my question: give me 3 lines of code (or configuration) that will allow this?
I beg of you :p :).
Regards, X.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
