Obviously Apple crafted their own brand of statement elsewhere so everyone gets to choose extra meanings in what they say.
I'm not so sure about Twitter being safe. It may have claimed that it was not vulnerable, but it *did* still apply the patch. Better safe than sorry...
Google's a weird one. Early reports said it was safe, and all the scanners showed it as being safe from the start of the panic. Yet it has admitted it updated its systems...
Given that it was involved in the discovery, I'd assume that Google updated its systems before the vulnerability became public. Facebook claims it updated before it went public, so surely Google would have done so.
Also... Google's certificates are a month old. Unlike other sites that have applied the Heartbeat patch, Google has not bothered to update its certificates.
Laziness, even though it issues its own certificates to itself? Or, as someone speculated earlier in the thread, did it actually patch its systems a month ago and that's why the certificates were renewed a month ago? Would it / Could it have known that early?
Whilst deprecated OS/X still ships with OpenSSL for use when needed.
It just happens to be the obsolete and safe one from earlier in 2011, just prior to this.
I'm not so sure about Twitter being safe. It may have claimed that it was not vulnerable, but it *did* still apply the patch. Better safe than sorry...
Google's a weird one. Early reports said it was safe, and all the scanners showed it as being safe from the start of the panic. Yet it has admitted it updated its systems...
Given that it was involved in the discovery, I'd assume that Google updated its systems before the vulnerability became public. Facebook claims it updated before it went public, so surely Google would have done so.
Also... Google's certificates are a month old. Unlike other sites that have applied the Heartbeat patch, Google has not bothered to update its certificates.
Laziness, even though it issues its own certificates to itself? Or, as someone speculated earlier in the thread, did it actually patch its systems a month ago and that's why the certificates were renewed a month ago? Would it / Could it have known that early?
my certificates in google are showing as issued 2/4/14 but i did read that they were using some issued middle of last month.
i put that down to when they found the bug. given that it is two years old it seems like spending a month fixing it is just plausible.
my certificates in google are showing as issued 2/4/14 but i did read that they were using some issued middle of last month.
i put that down to when they found the bug. given that it is two years old it seems like spending a month fixing it is just plausible.
Yesterday Gmail was still using a certificate from March 2014, it's changed now. Probably somebody went oops and changed it. So it still wasn't safe yesterday then.
Ha ha, even GeoTrust issued new certificate a couple of days ago for their site that is selling certificates. Nice. It's valid for 2 years, so it's either a coincidence or...
Also... Google's certificates are a month old. Unlike other sites that have applied the Heartbeat patch, Google has not bothered to update its certificates.
Yesterday Gmail was still using a certificate from March 2014, it's changed now. Probably somebody went oops and changed it. So it still wasn't safe yesterday then.
I suspect you're looking at different sites. When I last checked (about an hour ago), google.co.uk was using a certificate issued on 02/04/2014 but google.com was still using one from 12/03/2014.
I suspect you're looking at different sites. When I last checked (about an hour ago), google.co.uk was using a certificate issued on 02/04/2014 but google.com was still using one from 12/03/2014.
I had what appears to be a genuine forgotten password email from ebay-genuine in that it includes my full name and ebay user id and reads 100% like an authentic ebay email-but I haven't used my account or logged in for months-in fact it's been so long that the card details I gave for paying insertion fees etc have expired. I logged in (by going to ebay first, not by clicking any links in the email) and all appears to be in order, but have changed my password anyway.
Google now seems to have a new certificate for http://www.google.co.uk, http://www.google.com, picasaweb.google.com, mail.google.com, drive.google.com, plus.google.com and accounts.google.com, with a "Not valid before" date of 2nd April 2014.
However...some of those addresses still sometimes come up with a certificate with a "Not valid before" date of 12th March 2014. I don't know why that is
A message about the ‘Heartbleed’ bug | 11 April 2014
You may be aware of recent media coverage about an internet bug called ‘Heartbleed’. This is a bug that can affect the security of websites which use OpenSSL, a piece of software that is used to protect confidential information. Approximately 60% of the world’s websites feature this software.
The trust our customers have in Sky to keep their personal data secure is something that is hugely important to us. We have tested the security of all our customer-facing websites to make sure that our customers’ details are safe. We can confirm that no security issues have been identified and we will continue to monitor the situation closely.
We have also been working to ensure that Sky Yahoo Email accounts are secure, and Yahoo have taken steps to enhance the security of the service. Our advice is that it is good practice to regularly change your passwords and Sky Yahoo email users can do this quickly and easily at sky.com/reset
I had what appears to be a genuine forgotten password email from ebay-genuine in that it includes my full name and ebay user id and reads 100% like an authentic ebay email-but I haven't used my account or logged in for months-in fact it's been so long that the card details I gave for paying insertion fees etc have expired. I logged in (by going to ebay first, not by clicking any links in the email) and all appears to be in order, but have changed my password anyway.
Anyone worked out why Google still sometimes shows the older March certificate instead of the new April one?
I had a second email tonight from a company warning me about Heartbleed - and it wasn't even from one that was vulnerable.
1Password emailed its registered users to inform them about Heartbleed and reassure them that 1Password was not vulnerable as it doesn't use OpenSSL.
So, that's 1Password and IFTTT that have actually had the decency to inform users about this via email, plus Mojang Tweeting about it and making it quite prominent on its website.
The rest? Mostly still just vague quotes to newsmedia, and buried statements on websites... :rolleyes:
Just been reading about something interesting that means for some (but not many) sites the potential theft of the server's private key would not be completely catastrophic. I apologise if this isn't news to anyone here, but I hadn't heard of it before.
The most common method for protecting the session keys used for a particular encrypted communication is to use the server's private key, which is one of the reasons Heartbleed is so serious: If a private key has been compromised, it can be used to decrypt intercepted communications whose session keys were protected with that private key.
With Forward Secrecy, an encrypted transmission can only be decrypted with the session keys for that transmission, and not with the server's private key. [I assume that a stolen key could still enable a site to be spoofed because of the certificates, tricking people into submitting information to a fake site, but at least any communications intercepted to/from the real site could not be decrypted.]
Unfortunately, not many places support it yet.
Two I've just read mention of are Google and Twitter:
The SSL Checker at SSL Labs can be used to check if a server supports Forward Secrecy and with which browsers (as well as checking for Heartbleed and for certificate dates):
The Google post also explains how to check using Chrome:
You can check whether you have forward secret connections in Chrome by clicking on the green padlock in the address bar of HTTPS sites. Google’s forward secret connections will have a key exchange mechanism of ECDHE_RSA*.
* Some Google sites now use ECDHE_ECDSA which I assume is a newer type of Forward Secrecy key exchange? The important bit seems to be ECDHE from the Qualys / SSL Labs link...
The timing is all interesting, and if you consider that it turned out that RSA was actually a British GCHQ invention, a very small maybe is that the RSA company actually came into being via NSA support.
Like many companies, we took immediate action to assess the vulnerability and address it. We are not aware of any customer impact. It’s a good practice to change passwords from time to time, and now would be a good time to think about doing so. We have additional security guidelines on our site at http://www.netflix.com/security.
Tesco suddenly decided to make me change my password to something a lot harder a few weeks ago, can't remember if it was before or after this bug was made public though.
Still haven't managed to as it locked me out of the process, can still order my groceries though. Nationwide Building Society have a message saying not to bother changing anything though.
"Is this how you do business? Drop a patch for one product that quite literally lists out, in order, the security vulnerabilities in your platform, and then fail to patch those weaknesses on your other range of products for *weeks* afterwards? You really don’t see anything wrong with this?
Someone tell me I’m not crazy here .........In what world is this acceptable?"
Comments
that is what i mean about their ambiguous statement. sly really.
I'm not so sure about Twitter being safe. It may have claimed that it was not vulnerable, but it *did* still apply the patch. Better safe than sorry...
Google's a weird one. Early reports said it was safe, and all the scanners showed it as being safe from the start of the panic. Yet it has admitted it updated its systems...
Given that it was involved in the discovery, I'd assume that Google updated its systems before the vulnerability became public. Facebook claims it updated before it went public, so surely Google would have done so.
Also... Google's certificates are a month old. Unlike other sites that have applied the Heartbeat patch, Google has not bothered to update its certificates.
Laziness, even though it issues its own certificates to itself? Or, as someone speculated earlier in the thread, did it actually patch its systems a month ago and that's why the certificates were renewed a month ago? Would it / Could it have known that early?
It just happens to be the obsolete and safe one from earlier in 2011, just prior to this.
Funny that.
i put that down to when they found the bug. given that it is two years old it seems like spending a month fixing it is just plausible.
Yesterday Gmail was still using a certificate from March 2014, it's changed now. Probably somebody went oops and changed it. So it still wasn't safe yesterday then.
google.com is using valid from 02/04/2014
I can still see the older one at google.com, but new one elsewhere. It seems random
Google now seems to have a new certificate for http://www.google.co.uk, http://www.google.com, picasaweb.google.com, mail.google.com, drive.google.com, plus.google.com and accounts.google.com, with a "Not valid before" date of 2nd April 2014.
However...some of those addresses still sometimes come up with a certificate with a "Not valid before" date of 12th March 2014. I don't know why that is
Sky update:
http://www.sky.com/mysky/latestnews/article/my-sky-updates/latest-help-and-support-issues/
I imagine that was quite stressful.
But again, if they get the private key they still have to intercept your packets from the start of your session to get the session key.
I had a second email tonight from a company warning me about Heartbleed - and it wasn't even from one that was vulnerable.
1Password emailed its registered users to inform them about Heartbleed and reassure them that 1Password was not vulnerable as it doesn't use OpenSSL.
So, that's 1Password and IFTTT that have actually had the decency to inform users about this via email, plus Mojang Tweeting about it and making it quite prominent on its website.
The rest? Mostly still just vague quotes to newsmedia, and buried statements on websites... :rolleyes:
Yeah, I read that story. Typical...
Although I think it does make the earlier revelation that the FBI site was vulnerable all the more amusing!
Forward Secrecy / Perfect Forward Secrecy / PFS
http://en.wikipedia.org/wiki/Forward_secrecy
http://www.forwardsecrecy.com/
http://www.perfectforwardsecrecy.com/
https://www.eff.org/deeplinks/2014/04/why-web-needs-perfect-forward-secrecy
https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy
The most common method for protecting the session keys used for a particular encrypted communication is to use the server's private key, which is one of the reasons Heartbleed is so serious: If a private key has been compromised, it can be used to decrypt intercepted communications whose session keys were protected with that private key.
With Forward Secrecy, an encrypted transmission can only be decrypted with the session keys for that transmission, and not with the server's private key. [I assume that a stolen key could still enable a site to be spoofed because of the certificates, tricking people into submitting information to a fake site, but at least any communications intercepted to/from the real site could not be decrypted.]
Unfortunately, not many places support it yet.
Two I've just read mention of are Google and Twitter:
Google started using it in November 2011 - http://googleonlinesecurity.blogspot.co.uk/2011/11/protecting-data-for-long-term-with.html
Twitter started using it in November 2013 - https://blog.twitter.com/2013/forward-secrecy-at-twitter
The SSL Checker at SSL Labs can be used to check if a server supports Forward Secrecy and with which browsers (as well as checking for Heartbleed and for certificate dates):
https://www.ssllabs.com/ssltest/index.html
(explained here: https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy)
The Google post also explains how to check using Chrome:
* Some Google sites now use ECDHE_ECDSA which I assume is a newer type of Forward Secrecy key exchange? The important bit seems to be ECDHE from the Qualys / SSL Labs link...
Facebook uses ECDHE_RSA, so should have Forward Secrecy.
Apple, Microsoft, and Amazon still use RSA, so don't have Forward Secrecy.
Results match via the SSL Checker: FS for Facebook, no FS for Apple, Microsoft, and Amazon.
http://www.crn.com/news/security/240164991/rsa-denies-report-that-nsa-paid-it-10-million-for-encryption-back-door.htm
The timing is all interesting, and if you consider that it turned out that RSA was actually a British GCHQ invention, a very small maybe is that the RSA company actually came into being via NSA support.
Netflix
Wikipedia/Wikimedia
(only if you have a Wiki account for editing, nothing to worry about if you just read and don't have an account)
Still haven't managed to as it locked me out of the process, can still order my groceries though. Nationwide Building Society have a message saying not to bother changing anything though.
"Is this how you do business? Drop a patch for one product that quite literally lists out, in order, the security vulnerabilities in your platform, and then fail to patch those weaknesses on your other range of products for *weeks* afterwards? You really don’t see anything wrong with this?
Someone tell me I’m not crazy here .........In what world is this acceptable?"
http://arstechnica.com/security/2014/04/apple-users-left-exposed-to-serious-threats-for-weeks-former-employee-says/
I think that's the one where I summised that it half looked there on purpose.