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) -------------- 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/d22a203a/attachment-0004.sig>