I guess that when you say "to inspect encrypted traffic with the knowledge of the users on that network", you meant in fact "to inspect encrypted traffic without the knowledge of the users on that network" ?
The Certificate Authority structure is profoundly broken. There are too many points of failure where a valid cert could be issued to untrustworthy people. What's the solution at this point aside from users individually deciding which certs to trust? Can something be set up where once a cert is issued it has to be in some way countersigned by the receiving party, like using your private key to generate a signature for an email message?
Please be aware of the HN discussion on this post and how certificate transparency could be improved further: https://news.ycombinator.com/item?id=6869705
The French NSA was spying, doing man-in-the-middle attacks using a certificate authority that it publicly controls. They used it to spy on Google SSL encrypted traffic, and Google found out. If I were to guess, I bet they monitor the fingerprints of all SSL certs in Chrome. Google found out, they revoked the CA and told ANSSI that they were busted.
Then everybody pretended it was some kind of mistake....
I have written several times to security team, but they don't take this seriously. So I decided to post my comment here. My issue is how easy it is to recover your password, even though you answer the most of the security questions wrong.
I have received an email from Adam at security team, but he does not seem to understand the core. Basically, what I gather from his email, Google looks at Device ID and IP address, and put so less focus on what users put in as an answer.
Here is one example - I used a shared computer in my company that I used to access Gmail a few years ago for only few times, and I gave wrong answer all to "password you can remember", "recovery address," "time you opened your account," but nonetherless, I was able to "hack" into my account. No questions asked.
That means that, if devide is stolen, or if one use shared computer (even that was years ago), the password is easy to crack even with wrong answers. I think Google should look at what users's answer more closely, and don't put too much reliance on whatever the mechanical algorism you Google using. At the least "last password you can remember" should match - in my case, I gave completely wrong one, "googlemail," which I never used - it went through! I gave completely different opening date, backup email, too, but but I was able to hack into my account using the computer and IP address that I used a few years ago for only few times.
This is very grave problem which needs serious solutions. I think users will prefer much tighter security control, as Google service spans a broad range of things. If Google does not act on this, I have to flag this issue to security journalist, such as Wired ITworld, and many of them out there, because using Google is insecure!. If cracking password is this easy, nobody will use Gmail. I will stop using Gmail and switch to Hotmail.
I am dismayed that the event took place months ago, but only now are we hearing about this. I would think that support for DNSSec across the Google Properties and inclusion of DANE in the Crome browser would provide a realtime and strong level of protection against detect this type of fraud. This would also go a long way to protecting your customers!
You say that the intermediate certificate was used "to inspect encrypted traffic with the knowledge of the users"? You mean that users of the network knew that this would happen?
Why doesn't Chrome check the Certificate Revocation List (CRL)? If in this instance the CA revoked these certificates Chrome wouldn't know any better. Chrome would have to wait for it's certificate revocation metadata to be updated. Chrome doesn't just surf the Internet it's used on the Intranet for accessing applications. Many company internal CA's rely and think that there CRL process is working when it appears Internet Explorer is the only browser that checks CRL's anymore.
I don't understand how you detected the unauthorized certificate if it was signed by a valid intermediate CA.
And what does "to inspect encrypted traffic with the knowledge of the users on that network" mean ? Did the users allow to be spied their Google accounts ?
Ok, this is be off topic, but I just received a notice saying that my inbox has been restored. Even though I was converting it over from a Win 7 to Win 8 machine, I didn't recognize the address or URL. Tell me if I'm being paranoid. Here's the notice:
Gmail Team 5:09 PM (9 minutes ago)
We've finished restoring your inbox To make your transition easier, You are required to upgrade to newly secure server by clicking on follow below:
Follow
18 commenti :
I guess that when you say "to inspect encrypted traffic with the knowledge of the users on that network", you meant in fact "to inspect encrypted traffic without the knowledge of the users on that network" ?
Okay well, how and when did it happen? The CA gets a free pass as usual, I presume?
That's good news.
Seems like if Google really wanted to give this issue the attention it deserves, they would revoke ANSSI entirely.
The Certificate Authority structure is profoundly broken. There are too many points of failure where a valid cert could be issued to untrustworthy people. What's the solution at this point aside from users individually deciding which certs to trust? Can something be set up where once a cert is issued it has to be in some way countersigned by the receiving party, like using your private key to generate a signature for an email message?
Does Google Chrome feedback when certs don't mach the pin? Also is there a way to look for the sending of these logs so I can load them into a SIEM?
P.S. If so, what certs were MitMed?
Please be aware of the HN discussion on this post and how certificate transparency could be improved further: https://news.ycombinator.com/item?id=6869705
Let's translate this into proper English.
The French NSA was spying, doing man-in-the-middle attacks using a certificate authority that it publicly controls. They used it to spy on Google SSL encrypted traffic, and Google found out. If I were to guess, I bet they monitor the fingerprints of all SSL certs in Chrome. Google found out, they revoked the CA and told ANSSI that they were busted.
Then everybody pretended it was some kind of mistake....
Ordinarily, I wouldn't comment.
But this is important.
So I'll do the, rather pointless, Google verification dance.
Basically, I think there are two circumstances here:
1. Where the CA identifies a problem and reports it to browser vendors.
The problem might be the one you describe above, or something else (like a possible intrusion).
In this case, the trust bits for the problem certificate (the intermediary in this case) should be revoked.
2. Where you, or a 3rd party, identifies a problem.
In this case the trust bits for the CA root should be revoked.
The intention here is to provide an incentive for CAs to proactively monitor and report problems themselves.
Lest someone else report the problem and they be entirely disabled.
I have written several times to security team, but they don't take this seriously. So I decided to post my comment here. My issue is how easy it is to recover your password, even though you answer the most of the security questions wrong.
I have received an email from Adam at security team, but he does not seem to understand the core. Basically, what I gather from his email, Google looks at Device ID and IP address, and put so less focus on what users put in as an answer.
Here is one example - I used a shared computer in my company that I used to access Gmail a few years ago for only few times, and I gave wrong answer all to "password you can remember", "recovery address," "time you opened your account," but nonetherless, I was able to "hack" into my account. No questions asked.
That means that, if devide is stolen, or if one use shared computer (even that was years ago), the password is easy to crack even with wrong answers. I think Google should look at what users's answer more closely, and don't put too much reliance on whatever the mechanical algorism you Google using. At the least "last password you can remember" should match - in my case, I gave completely wrong one, "googlemail," which I never used - it went through! I gave completely different opening date, backup email, too, but but I was able to hack into my account using the computer and IP address that I used a few years ago for only few times.
This is very grave problem which needs serious solutions. I think users will prefer much tighter security control, as Google service spans a broad range of things. If Google does not act on this, I have to flag this issue to security journalist, such as Wired ITworld, and many of them out there, because using Google is insecure!. If cracking password is this easy, nobody will use Gmail. I will stop using Gmail and switch to Hotmail.
I am dismayed that the event took place months ago, but only now are we hearing about this. I would think that support for DNSSec across the Google Properties and inclusion of DANE in the Crome browser would provide a realtime and strong level of protection against detect this type of fraud. This would also go a long way to protecting your customers!
You say that the intermediate certificate was used "to inspect encrypted traffic with the knowledge of the users"? You mean that users of the network knew that this would happen?
Why doesn't Chrome check the Certificate Revocation List (CRL)? If in this instance the CA revoked these certificates Chrome wouldn't know any better. Chrome would have to wait for it's certificate revocation metadata to be updated. Chrome doesn't just surf the Internet it's used on the Intranet for accessing applications. Many company internal CA's rely and think that there CRL process is working when it appears Internet Explorer is the only browser that checks CRL's anymore.
Thanks for your advise.
I don't understand how you detected the unauthorized certificate if it was signed by a valid intermediate CA.
And what does "to inspect encrypted traffic with the knowledge of the users on that network" mean ? Did the users allow to be spied their Google accounts ?
Thanks and regards
It's a serious problem...Suppose if any rogue employee of CA or Intermediate CA can impersonate any domain and do what he wants.
Ok, this is be off topic, but I just received a notice saying that my inbox has been restored. Even though I was converting it over from a Win 7 to Win 8 machine, I didn't recognize the address or URL. Tell me if I'm being paranoid. Here's the notice:
Gmail Team
5:09 PM (9 minutes ago)
We've finished restoring your inbox To make your transition easier, You are required to upgrade to newly secure server by clicking on follow below:
Follow
Regards,
Administrator
This is a great post. It’s Very informative and well writing.
website design baton rouge
this is really a great blog.... thanks for sharing the blog...
ISO Certification Agencies
Posta un commento