Thank you.
What will the temporary packages be called ?
On Tue, 2014-04-08 at 03:30 +0100, Always Learning wrote:
Thank you.
What will the temporary packages be called ?#
I've answered my own question: openssl*
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.
2. See this page for figuring out which services you should restart after applying updates .. or just reboot the machine which will restart all services:
On 09.Apr.2014, at 15:54, Johnny Hughes johnny@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:
- The first susceptible version of openssl in a CentOS release was
openssl-1.0.1e-15.el6, released on December 1, 2013.
- 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.
- 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.
- 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:
- 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?
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.
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.
On 04/09/2014 09:09 AM, Markus Falb wrote:
On 09.Apr.2014, at 15:54, Johnny Hughes johnny@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:
- The first susceptible version of openssl in a CentOS release was
openssl-1.0.1e-15.el6, released on December 1, 2013.
- 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.
- 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.
- 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:
- 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)
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@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:
- The first susceptible version of openssl in a CentOS release was
openssl-1.0.1e-15.el6, released on December 1, 2013.
- 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.
- 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.
- 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:
- 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
Dne 9.4.2014 17:27, Johnny Hughes napsal(a):
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).
What about the user credentials sent over this "insecure" communication channel. They could be also compromised... DH
On 04/10/2014 05:17 AM, David Hrbáč wrote:
Dne 9.4.2014 17:27, Johnny Hughes napsal(a):
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).
What about the user credentials sent over this "insecure" communication channel. They could be also compromised... DH
Anything in the actual memory of the process can be retrieved in random 64KB chunks, when/if someone uses an exploit against your server on the https or one of the other ports (imaps, pop3s, etc).
The exploiter does not get to choose the memory check they get (it is random), so they would need to run the exploit, in a loop, dump the data, and grab the info in chunks. Then they would need to string the data together or grab pieces out of the data.
So, yes, older transactions on that process could be seen. So some user names, passwords, credit card numbers, any other traffic someone posted on a connection to the machine could be read in the data that was dumped and saved, including the server's private key as that key is used to decrypt the connection.
That is one part of the exploit ... gleaning info from a service that is running in real time.
If you are patched now, and if you restarted all services that were running the old version of ssl, then that can no longer be done to your machine. It could have been done as long as someone was exploiting the port in question from the time any from the installation of the 6.5 openssl's were installed until at least version openssl-1.0.1e-16.el6_5.4.0.1.centos.el6 (or openssl-1.0.1e-16.el6_5.7) was installed ... AND all applicable services were restarted.
All of the chunks of up to 64KB that someone gathered, they can look back through.
==============================
Another potential thing that someone who had access to your network traffic could have done was dump/save that IP traffic, regardless of if it was encrypted or not.
They could then use, if they obtained it, the private key for an https server you connected to (one of the things they could have gotten while a server was vulnerable). If someone did get a private key and if they did save encrypted traffic that was on going, then they could at that point decrypt the traffic that they have.
Those are the two possible things that could have happened.
=============================
In the case of CentOS servers, the time period where that could have occurred is from December 1, 2013 (when openssl-1.0.1e-15.el6 was released in CentOS-6.5) until people using 6.5 upgrade to openssl-1.0.1e-16.el6_5.7 (available on April 8th, 2014). In the case of some other distributions, the possible time frame is from March 2012 until April 2014.
Dne 10.4.2014 14:47, Johnny Hughes napsal(a):
Those are the two possible things that could have happened.
=============================
In the case of CentOS servers, the time period where that could have occurred is from December 1, 2013 (when openssl-1.0.1e-15.el6 was released in CentOS-6.5) until people using 6.5 upgrade to openssl-1.0.1e-16.el6_5.7 (available on April 8th, 2014). In the case of some other distributions, the possible time frame is from March 2012 until April 2014.
Yes, that's I wanted to point out. And that's why we are going to replace all the SSL certificates. But this is not enough, we have to and are going to regenerate the user passwords and ssh keys. What more we are also going to regenerate server ssh keys, they could be compromised because of GSISSHD.
DH
On Thu, Apr 10, 2014 at 03:10:31PM +0200, David Hrbá?? wrote:
are going to regenerate the user passwords and ssh keys. What more we
SSH keys were not compromised by heartbleed (unless you had a management tool that was vulnerable or an alternative ssh daemon that used libssl). Nothing in the standard SSH was vulnerable so if your only encrypted traffic was via OpenSSH then you have no problems.
Web servers, POP3, IMAP etc that were vulnerable may have potentially leaked user passwords, but they can't leak SSH keys.
are also going to regenerate server ssh keys, they could be compromised because of GSISSHD.
If the GSI patches used libssl then you might be vulnerable, but if they only used libcrypt then you weren't exposed.
On 04/10/2014 03:09 AM, Markus Falb wrote:
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...
No, the server never sees a private client certificate, it only ever has access to the public certificate, which by its very nature of being public doesn't really matter if it gets leaked. No vulnerability on the server can expose a private client certificate, only a vulnerability on the client can.
Peter
On 09.Apr.2014, at 22:12, Peter peter@pajamian.dhs.org wrote:
On 04/10/2014 03:09 AM, Markus Falb wrote:
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...
No, the server never sees a private client certificate, it only ever has access to the public certificate, which by its very nature of being public doesn't really matter if it gets leaked.
I know.
No vulnerability on the server can expose a private client certificate, only a vulnerability on the client can.
With malicious server I did not meant one that was affected by heartbleed but a server which is run by bad people that want to exploit vulnerable clients.
If it's easy to write a malicious client to read the server's ram, it's maybe easy to write a malicious server that can read the client's ram? Does heartbleed work in both directions?
Assume that the client uses a vulnerable openssl, and it connects to a malicious server, can the server read the ram of the client?
In article 1483A20E-66B7-4ECC-8C14-34DE4B24BA33@gmail.com, Markus Falb wnefal@gmail.com wrote:
No vulnerability on the server can expose a private client certificate, only a vulnerability on the client can.
With malicious server I did not meant one that was affected by heartbleed but a server which is run by bad people that want to exploit vulnerable clients.
If it's easy to write a malicious client to read the server's ram, it's maybe easy to write a malicious server that can read the client's ram? Does heartbleed work in both directions?
Assume that the client uses a vulnerable openssl, and it connects to a malicious server, can the server read the ram of the client?
https://reverseheartbleed.com/
Cheers Tony
On Wed, 9 Apr 2014, Johnny Hughes wrote:
- 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.
The OpenVPN folks note that if your configuration uses the additional TLS auth configuration bits (tls-auth), then OpenVPN certificates were not exposed to a heartbeat attach.
-
Always Learning -
David Hrbáč -
Johnny Hughes -
Markus Falb -
Paul Heinlein -
Peter -
Stephen Harris -
tony＠softins.co.uk