On 04/09/2014 09:27 AM, Johnny Hughes wrote: > On 04/09/2014 09:09 AM, Markus Falb wrote: >> On 09.Apr.2014, at 15:54, Johnny Hughes <johnny at centos.org> wrote: >> >>> On 04/07/2014 08:30 PM, Always Learning wrote: >>>> Thank you. >>>> >>>> What will the temporary packages be called ? >>>> >>>> >>> Since this is the first post about the openssl update, I want to answer >>> a couple questions here: >>> >>> 1. The first susceptible version of openssl in a CentOS release was >>> openssl-1.0.1e-15.el6, released on December 1, 2013. >>> >>> 2. The version of openssl that you should install to fix the issue is >>> openssl-1.0.1e-16.el6_5.7, released on April 8, 2014. >>> >>> 3. Versions of CentOS-6.5 openssl that were affected are: >>> openssl-1.0.1e-15.el6, openssl-1.0.1e-16.el6_5, >>> openssl-1.0.1e-16.el6_5.1, openssl-1.0.1e-16.el6_5.4. >>> >>> 4. Only CentOS-6.5 was affected. CentOS-6 at versions 6.4 or earlier >>> was not affected. No versions of CentOS-5 (or any other CentOS) were >>> affected. >>> >>> Besides doing updates, things you should do include: >>> >>> 1. Besides doing the updates, you should replace any certificates using >>> SSL or TLS that are openssl based. This includes VPN, HTTPD, etc. See >>> http://heartbleed.com/ for more info on impacted keys. >> update openssl, reissue the certificates (with new key!), revoke the old certificates. >> So far so good, but it goes further, doesn't it? Not only the ssl key could have been >> leaked, but also other sensible data. session keys, passwords, ... to handle this bug >> consequently, not only the ssl key and certificate has to be replaced, but also >> passwords, etc., i.e. every piece of sensible data that could have been transported >> over tls encrypted connections. Am I correct? > If someone actually got a copy of your old private-key and if they also > had the ability to log all the traffic to and from your site, they could > decrypt that. Not likely to have happened. They could also use that > old private key to act as if they are your site until that certificate > is revoked. > > If someone actually used the exploit against your server before you > installed the update, they can see the things in memory (in random > chunks) ... so they could see a username and password or other data that > might be in memory at that time. The ultra safe thing would be to > assume all your passwords for SSL/TLS things are compromised. > >> This was about server side certificates, and that's a controlled environment. After >> you fixed your server it is not vulnerable anymore. Another issue is client certificates, >> and I am quite unsure the implications on these. > It is only things that actually used SSL in memory (like httpd, imaps, > pop3s, etc) . those certificates COULD have been impacted. > > openssh was not impacted (based on my reading). >> I am assuming that client certificates are handed out to staff. Basically you can't >> really control where people install client certificates and which client software is used. >> If one is tricked to do a SSL Handshake with a malicious server, the key of the client >> certificate is leaked. Reissue of the cert won't help because on the other day there >> would be another malicious handshake with another bad server... >> >> Does this bug render authentication with client certificates obsolete/insecure/useless ? >> >> How does you handle client certificates after this heartbleed thing? >> Your opinions and knowlegde or specific links about client certificates and heartbleed would be appreciated. >> > If you change a private key with any of those things on the server, > then the public (client) keys that access them would also need to be > changed as well. (The old ones would not work anyway). If someone (bad > guy who stole your private key) set up a server with the old key, the > old clients would work with those (so that is why you need to change AND > revoke your cert, not just change it on your machine :D) This is an excellent write up: http://www.theregister.co.uk/2014/04/09/heartbleed_vuln_analysis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20140409/ba055bf1/attachment-0004.sig>