Urro..
Arrr, another nginx convert. They're all over the place! :-) I've got
one nginx box so far and its' been good to me apart from some problems
converting over some funky URL rewrite rules. Seems to be the way
things are heading so I'll probably go there myself as well.
I'm not really being paranoid, just curious. Even before the HB issue
the old device/browser support vs qualsys thing came up every now and
then. I think a lot of folks do the big copy'n'paste from an old post
on the qualsys forums. As with all things in this space there seems to
be only a few folks doing original testing/research and they just
blindly follow a few bloggers.
I'm not sure on the benefits of getting certs added to the CRL or, ummm,
the new one... (OSCP?? OPSC? Brain fade)
I manage one multi-domain EV cert across IIS and Apache servers and
having the old cert in the CRL caused me no end of pain one year when we
renewed early. Folks connecting to non-updated boxes started to get
revocation errors and continued to after I'd updated the cert as it was
being cached by their browsers. Wound up doing a re-issue and requested
the CA leave it out of the CRL for a while.
My take on it is that if you have very critical data or high
value/volume transactions going on in a B2B situation you'd use a
revocation mechanism and use a defined outage window to pull the old
cert, update the CRL/other and put up the new cert. If it's public
facing B2C infrastructure just clean up the old certs and install the
new one. YMMV, no warranty implied or offered. :-)
Cheers, Chris H.
On 20/04/14 10:32, Steve Holdoway wrote:
I get A+ on my own webmail interface, but then I pretty much know what
devices are talking to it. That uses
ssl_ciphers
TLS_ECDHE_RSA_WITH_RC4_128_SHA:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA:ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS;
(nginx syntax, sorry. I'm a convert) ciphers and, apart from
supporting SNI on this would talk to anything but java 6 I think. This
is the 'best practice' I've come up with. Interesting just how many
blog posts are just cut/pastes of other works when researching this!
To be honest, I reckon that you're being pretty paranoid ( even if it
is in the SysAdmin jobspec ) by tuning SSL at all, although I do make
all these newfangled elliptical ciphers available, and try to use the
less computationally complex options. Can't remember what not using
RC4 disables, but that also seems to be a logical step as it's been
pretty well discredited. SSL2 is in the same boat.
One question does intrigue me though... with all this grief about the
difficulty in revoking certs, is it really necessary if you're just
binning it??
Cheers,
Steve
On 20/04/14 00:24, Chris Hellyar wrote:
Hi Steve...
Not really related to the heartbleed issue, but about apache SSL
protocol settings..
Have you had any issues with disabling ssl 2/3 ?
I've never managed to get qualsys to give me better than an 'A-' and
still keep support for older IE7/8 and early android 2.x mobile
devices intact. I turn off SSL2, but keep 3 enabled for the old stuff.
ie: https://www.ssllabs.com/ssltest/analyze.html?d=rd3.co.nz
(My own one, can't really share any of the work ones that have the
issue as they are what we'd call dark-web. :) )
There's lots written about this all over the web but no real
best-practice info for keeping the old devices supported that floats
to the top. Unfortunately I support some stuff that is used
predominantly in Asia and there are a _lot_ of old mobile and windows
XP devices there...
Cheers, Me.
On 09/04/14 11:33, Steve Holdoway wrote:
Here's one I cleaned up earlier...
https://www.ssllabs.com/ssltest/analyze.html?d=kidstoybox.com.au (:
Cheers, Steve
_______________________________________________
Linux-users mailing list
[email protected]
http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
_______________________________________________
Linux-users mailing list
[email protected]
http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
_______________________________________________
Linux-users mailing list
[email protected]
http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
