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-boun...@lists.squid-cache.org] On Behalf
Of Xen
Sent: Saturday, September 5, 2015 1:58 PM
To: squid-users@lists.squid-cache.org
Subject: [squid-users] 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@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
