Gmail.com being MITM'd by Iran using this certificate(pastebin.com)
pastebin.com
Gmail.com being MITM'd by Iran using this certificate
http://pastebin.com/ff7Yg663
26 comments
So Google wrote Stuxnet?
Found a pastebin with slightly more info: http://pastebin.com/SwCZqskV
[deleted]
In order to mitigate attacks like this Firefox users can use:
http://convergence.io/
There's also another, similar, project called Perspectives: http://perspectives-project.org/
The Syrian government was doing this recently as well: https://www.eff.org/deeplinks/2011/05/syrian-man-middle-agai...
Oh and don't forget about the EFF's SSL Observatory: https://www.eff.org/observatory
The Syrian government was doing this recently as well: https://www.eff.org/deeplinks/2011/05/syrian-man-middle-agai...
Oh and don't forget about the EFF's SSL Observatory: https://www.eff.org/observatory
How easy is it to MITM the convergence requests themselves? And does it send all of my web-browsing habits to the notaries? How much money would I have to pay for someone to run a notary for me and would that be safe?
convergence is not compatable with FF 6.0 btw. You'll need to manually check if your using 6.0.
O.
O.
Interesting, but how do you use it?
OK, how do we remove this CA from our computers?
On a Mac, go to Keychain Access, hit the padlock in the upper left to unlock the system keychain with an admin account, select System Roots from the list of available Keychains in the upper left, find and select DigiNotar Root CA, get info (command-I or hit the i in the bottom area of this window), open the Trust section, for "When using this certificate" select Never Trust.
Anybody knows how to view/delete the root certificates on an iPad? From what I've seen, it seems like you can only view/delete the certificates you have installed yourself.
That's right. iPhone and iPad wireless carrier profiles come with special carrier root CAs. You can't delete them, and by using them, your carrier can easily MITM your IMAP password, Google cookie, online banking credentials, or anything else you do over SSL. Your carrier's unfettered access is in addition to the Department of Defence Root CA, the China Internet Network Information Center Root CA, and the others who enjoy the same privilege already. Apple just made it easier to hide by making it impossible for you to actually see the chain of trust in Mobile Safari.
Interestingly, this is why corporations and governments managing secret information continue to rely on Blackberry, where each device gets a locked certificate on activation. That provides the only serious protection from man-in-the-middle attacks in the wireless industry today. Remember the public pressure on RIM to support wiretapping in India? They were the only company not making it easy.
Interestingly, this is why corporations and governments managing secret information continue to rely on Blackberry, where each device gets a locked certificate on activation. That provides the only serious protection from man-in-the-middle attacks in the wireless industry today. Remember the public pressure on RIM to support wiretapping in India? They were the only company not making it easy.
Firefox extension to do the trick is linked below: http://news.ycombinator.com/item?id=2938623
In chrome looks like you can't remove it, but at least you can disable the use of that CA to identify sites,ecc... from preference>manage certificates.
Chrome uses whatever the OS uses, as far as I can tell. Preferences > Manage Certificates just opens up the Keychain Access app. Upthread are instructions for how to do it from there.
[deleted]
I checked and the cert from gmail.com for me is from Thawte. Is this a targeted attack toward only those in Iran?
I think so. This kind of thing are almost always targeted attacks.
The Thawte certificate is the certificate issued to google by request of google. This certificate is apparently being used to MITM connections to gmail that originate inside Iran. Outside of Iran BGPing a major ISP into routing through them, or setting up a standard "phishing" mirror site, no one outside of Iran should worry much.
It still is a good idea to blacklist that root certificate on your internet devices though. If this certificate is being used, who knows what other websites it has issued legitimate but malicious certificates for.
It still is a good idea to blacklist that root certificate on your internet devices though. If this certificate is being used, who knows what other websites it has issued legitimate but malicious certificates for.
No one outside of Iran should worry about this particular google cert, you mean.
The obviously compromised root CA shipped by default in every computer in operation is something we very much should worry about. Who else has access to DigiNotar's cert? Surely there are players out there willing to pay more than Iran is...
The obviously compromised root CA shipped by default in every computer in operation is something we very much should worry about. Who else has access to DigiNotar's cert? Surely there are players out there willing to pay more than Iran is...
Of course you should worry. The attacker may have sold the cert to other parties, not just Iran. Or if it was Iran directly, they may sell the certs to other parties to make a pretense of deniability.
Most likely. It would be pretty impressive if the Iranian government were able to MITM every Gmail user in the world.
Impressive? Do you remember the news that China published routing that sent all traffic for Facebook through Beijing? Given that the China Internet Network Information Center (CNNIC) root CA comes with every browser these days, all it takes for a hostile entity is a fake BGP advertised route through a compromised router to make that happen.
...and issued directly by google for *.google.com
If you want to disable diginotar's root CA on your Mac (for Safari/Chrome) you can open Keychain Access, select the "System Roots" keychain at the top left, find the diginotar certificate in the list, and delete it (or disable it, which is what I did).
EDIT: This definitely works for Safari, not 100% sure if it does for Chrome after all.
EDIT: This definitely works for Safari, not 100% sure if it does for Chrome after all.
$ sudo dpkg-reconfigure ca-certificates # for debian-based systems
I've always wondered what that package is actually used for, because programs like firefox, chromium, &c, maintain their own list of root CAs.
So help me understand...
A government agency in Iran has obtained the private key of the root certificate for the DigiNotar Certificate Authority. And with that, they can decrypt and re-encrypt SSL traffic by pretending that they have the valid SSL certificate for *.google.com.
Is that the way this works?
A government agency in Iran has obtained the private key of the root certificate for the DigiNotar Certificate Authority. And with that, they can decrypt and re-encrypt SSL traffic by pretending that they have the valid SSL certificate for *.google.com.
Is that the way this works?
That's one possibility, and quite scary because someone with that private key could hijack any SSL connection to any site, not just Google. More likely is that Iran caused DigiNotar to issue them a valid .google.com certificate via social engineering, bribery, or hacking. This is slightly less scary because only .google.com would be affected.
Either way, IMHO DigiNotar's root certificate should be revoked and they should be barred from participating in the CA system ever again. The seriousness of SSL MITM attacks is such that a "one strike and you're out" policy is warranted. With so much commerce running over SSL these days, possession of the private key of a CA's root certificate would allow you to implement plots worthy of a James Bond supervillan.
Either way, IMHO DigiNotar's root certificate should be revoked and they should be barred from participating in the CA system ever again. The seriousness of SSL MITM attacks is such that a "one strike and you're out" policy is warranted. With so much commerce running over SSL these days, possession of the private key of a CA's root certificate would allow you to implement plots worthy of a James Bond supervillan.
In fact, guess what:
http://blog.mozilla.com/security/2011/08/29/fraudulent-googl...
Great! I'm glad DigiNotar will be punished for this lapse. Too bad it takes a code update to revoke their certificate. This won't be the last CA compromise we see.
"This won't be the last CA compromise we see."
Indeed. I strongly suspect too that it's only "the first one we've seen", and not "the first one".
I have very little doubt that most nation-state sized adversaries have the ability to forge whatever certs they want. It's only careful use of those forged certs (or dumb luck) by the agencies using them that have kept them out of the blogosphere...
Indeed. I strongly suspect too that it's only "the first one we've seen", and not "the first one".
I have very little doubt that most nation-state sized adversaries have the ability to forge whatever certs they want. It's only careful use of those forged certs (or dumb luck) by the agencies using them that have kept them out of the blogosphere...
Yeah, if NSA doesn't have at least one root CA key they're not doing their jobs. What we need is an alternative to the centralized CA system, like TOFU POP MONK.
They do, and it isn't even hiding. Take a look in your cert store and you will see multiple DoD root CAs.
I just checked, and at least with firefox, I didn't see any. What are you referring to exactly?
Odd, my OS X machine has 2 of them listed. I don't see it in firefox though.
[deleted]
More than likely someone hacked or socially engineered the DigiNotar CA into issuing just that cert, or some limited set of certs.
essentially, they would be MITMing the connection and presenting an SSL cert issued by DigiNotar (instead of the actual CA that issued the cert to *.google.com). because the compromised CA is in the browser's trusted CAs list, it probably produces no user-visible warning.
Either that or they've got the cooperation of someone who has access to that private key, potentially the CA itself. But a compromise seems more likely in this case.
A quick check of Bugzilla didn't turn up a bug directly about this issue, but https://bugzilla.mozilla.org/show_bug.cgi?id=681902#c6 from one of the people who deals with CA issues at Mozilla mentions "the current DigiNotar incident", so they clearly know about it.
It took 3 months to get their customers transferred over to this new cert. https://bugzilla.mozilla.org/show_bug.cgi?id=622589 I wonder if the CA was compromised since earlier this year, or if it's more recent?
See also https://bugzilla.mozilla.org/show_bug.cgi?id=682956#c2 , an explicit acknowledgment.
[deleted]
Assuming this certificate stuff is legit, how do we know this is being done by Iran? What makes anyone think this is Iran?
The claims reported in various places suggest that people in Iran have actively observed this certificate used in MITM attacks on gmail connections. No hard evidence yet, and no idea what original source people keep repeating (possibly the pastebin itself).
It's weird, isn't it? From zero to accepted fact on the basis of some guys assumption mentioned in the title of a pastebin dump. The only other original source I've been able to find is this:
http://www.google.com/support/forum/p/gmail/thread?tid=2da61...
He even invokes the Comodo incident, which as we know turned out to be the work of a single individual and NOT Iran.
Propaganda spreads quickly, even in the HN circle where people usually pride themselves on requiring evidence as a prerequisite to belief.
http://www.google.com/support/forum/p/gmail/thread?tid=2da61...
He even invokes the Comodo incident, which as we know turned out to be the work of a single individual and NOT Iran.
Propaganda spreads quickly, even in the HN circle where people usually pride themselves on requiring evidence as a prerequisite to belief.
This is perhaps the earliest-dated public indication of the attack: https://www.google.com/support/forum/p/gmail/thread?tid=2da6...
Hi, Today, when I trid to login to my Gmail account I saw a certificate warning in Chrome . I took a screenshot and I saved certificate to a file .
this is the certificate file with screenshot in a zip file: http://www.mediafire.com/?rrklb17slctityb
and this is text of decoded fake certificate: http://pastebin.com/ff7Yg663
when I used a vpn I didn't see any warning ! I think my ISP or my government did this attack (because I live in Iran and you may hear something about the story of Comodo hacker!)
Hi, Today, when I trid to login to my Gmail account I saw a certificate warning in Chrome . I took a screenshot and I saved certificate to a file .
this is the certificate file with screenshot in a zip file: http://www.mediafire.com/?rrklb17slctityb
and this is text of decoded fake certificate: http://pastebin.com/ff7Yg663
when I used a vpn I didn't see any warning ! I think my ISP or my government did this attack (because I live in Iran and you may hear something about the story of Comodo hacker!)
Anyone can tell us if this is for real or a hoax? I am lacking sufficient ssl knowledge here...
Mikko Hypponen of F-Secure seems to think that it is real: http://twitter.com/#!/mikkohypponen
Here's a bug report from the user who originally noticed it: http://www.google.co.uk/support/forum/p/gmail/thread?tid=2da...
This type of compromised-CA attack is why I never understood why browsers don't use the OpenSSH model: accept and store (prompting for confirmation) the certificate the first time you connect to a site, then throw up enormous red flags if the certificate ever changes.
The Firefox root CA list has dozens and dozens of organizations on it. Could a compromise of any one of them mean that this attack could be repeated?
The Firefox root CA list has dozens and dozens of organizations on it. Could a compromise of any one of them mean that this attack could be repeated?
Because that security model means that a compromised ISP can permanently MITM you the first time you visit a site on any computer for the first time. In exchange for losing the single points of failure, it creates a constant stream of opportunities to break the trust model.
You may think that's a good tradeoff. I don't, but reasonable people can disagree about it. However, it's completely untenable for financial information, because attackers after financial information aren't laser targeted and are perfectly happy with a constant stream of compromised sessions. Remember what TLS was designed for in the first place.
You may think that's a good tradeoff. I don't, but reasonable people can disagree about it. However, it's completely untenable for financial information, because attackers after financial information aren't laser targeted and are perfectly happy with a constant stream of compromised sessions. Remember what TLS was designed for in the first place.
Wrong.
The OpenSSH model implies that you check the fingerprint of the public key before you send encrypted data using that key. That is why SSH shows you the fingerprint of the server key when you first connect, and you have to answer "yes" in order to accept the key and add it to your keyring. You are supposed to have talked to the person managing the system and that person should have given you the fingerprint of the key.
It is virtually impossible for the ISP to intercept and sniff the stream without changing the fingerprint.
The user still has to trust its SSH client.
The OpenSSH model implies that you check the fingerprint of the public key before you send encrypted data using that key. That is why SSH shows you the fingerprint of the server key when you first connect, and you have to answer "yes" in order to accept the key and add it to your keyring. You are supposed to have talked to the person managing the system and that person should have given you the fingerprint of the key.
It is virtually impossible for the ISP to intercept and sniff the stream without changing the fingerprint.
The user still has to trust its SSH client.
"Wrong! Random people will totally verify key fingerprints when they're logging into Google Mail at Starbucks! After all, that's what every sysadmin does with SSH, right!"
gmaslov is clearly talking about the OpenSSH trust model. You are confusing it with the Trust On First Use model, which is not the same thing.
I have no idea what you are trying to express here. "Trust On First Use" is a synonym for key continuity. The fact that you have to type "yes" when SSH does it and click a series of buttons when a browser does it doesn't change anything.
I think you think that "Trust On First Use" means "automatically accept keys the first time you hit a site". In fact, that's only true in practice. Presumably everyone's going to get the "Watch Out! This Could Be Iran!" dialog from their browser, too.
I think you think that "Trust On First Use" means "automatically accept keys the first time you hit a site". In fact, that's only true in practice. Presumably everyone's going to get the "Watch Out! This Could Be Iran!" dialog from their browser, too.
There isn't any non-Internet communication channel that users could use to find Google's fingerprint. Google won't give their fingerprints on the phone for billions of web users.
Theoretical models that have no practicality in a given real life context aren't worth discussing as a solution.
Theoretical models that have no practicality in a given real life context aren't worth discussing as a solution.
the cert patrol add-on for firefox can be configured to behave that way:
http://patrol.psyced.org/
normally it just shows you a horizontal bar alerting you when a host's ssl certificate changes, and whether it thinks it was for a good reason like the old cert being near its expiration date.
annoyingly, google has a number of different ssl certificates installed on different servers/load balancers (some wildcard, some not, some signed by different CAs, some signed by google's root) so nearly every time i would use a google service, the add-on would be throwing warnings at me that must be manually clicked to be dismissed. eventually i gave up and stopped using the add-on.
http://patrol.psyced.org/
normally it just shows you a horizontal bar alerting you when a host's ssl certificate changes, and whether it thinks it was for a good reason like the old cert being near its expiration date.
annoyingly, google has a number of different ssl certificates installed on different servers/load balancers (some wildcard, some not, some signed by different CAs, some signed by google's root) so nearly every time i would use a google service, the add-on would be throwing warnings at me that must be manually clicked to be dismissed. eventually i gave up and stopped using the add-on.
In the latest version, you can now tell it to stop warning you about the changes from a particular domain only.
Unfortunately that still wouldn't have helped in this case.
You are absolutely right. Although I think it is undesirable to enable such a feature by default, as a technical user, I badly want it. I want browsers to cache certificate public keys and alert me when they change.
Note that Chrome's key pinning feature (http://www.imperialviolet.org/2011/05/04/pinning.html) is a somewhat comparable idea, except the well-known key hashes are hard coded in Chrome and not user updateable.
Note that Chrome's key pinning feature (http://www.imperialviolet.org/2011/05/04/pinning.html) is a somewhat comparable idea, except the well-known key hashes are hard coded in Chrome and not user updateable.
But wouldn't the red flags go up when the certificate is renewed?
Or just when the host is migrated. This technique "works", I guess, but the false postive rate is staggeringly high. I see these errors daily (generally due to DHCP reuse of my test boxes' addressess). In decades of use, I don't believe I've ever once been MitM'd over ssh.
SSH users understand the issue and are happy to triage a "not in known_hosts" error. The general public won't have a clue.
SSH users understand the issue and are happy to triage a "not in known_hosts" error. The general public won't have a clue.
SSL snake oil. SSL and the percieved trust around it has to die. It's a big lie, especially with broken CAs, lax security, poor encryption due to international policy and several technical and conceptual flaws.
Some critique here to back me up:
http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysi...
Some critique here to back me up:
http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysi...
So you don't like the way SSL/TLS is configured in your browser and therefore we should throw out 15+ years of intense study for whatever flavor-of-the-month protocol is most popular when everyone agrees with you?
How about instead of "SSL sucks!", you propose things that will (from your vantage point) improve SSL/TLS? What, so you don't like that Mozilla gets to dictate what all the trust roots are? Neither do I. But that is not one of the worlds great compute or UX problems to solve. Propose a solution.
It's a virulent misconception that the SSL/TLS security model depends on Verisign and Thawte. The only place in the whole model we have that dependency is your browser's configuration and that stupid dialog it shows when a cert doesn't check out. You can replace just those two parts and get virtually any other trust model you want.
How about instead of "SSL sucks!", you propose things that will (from your vantage point) improve SSL/TLS? What, so you don't like that Mozilla gets to dictate what all the trust roots are? Neither do I. But that is not one of the worlds great compute or UX problems to solve. Propose a solution.
It's a virulent misconception that the SSL/TLS security model depends on Verisign and Thawte. The only place in the whole model we have that dependency is your browser's configuration and that stupid dialog it shows when a cert doesn't check out. You can replace just those two parts and get virtually any other trust model you want.
Yes I'd quite happily throw out 15+ years of intense study and research (inclusing SSL/TLS) as it occasionally breaks down and kicks you in the face (google for TLS MITM vulns).
There should be an explicit trust model where the service vendor ships your keys via an alternative side channel -or- a decentralised model which works on reputation or trust.
If it works, why do all the online banks use two-factor authentication these days?
Oh wait, there is the solution!
There should be an explicit trust model where the service vendor ships your keys via an alternative side channel -or- a decentralised model which works on reputation or trust.
If it works, why do all the online banks use two-factor authentication these days?
Oh wait, there is the solution!
At the current rate of discovery, every vulnerability in TLS should make you more confident in the protocol. We're running an average of 3-5 years between protocol-level discoveries in TLS. Each one is the product of, literally, millions and millions of dollars of adversarial research.
Psst. I've got news for you. adb56780a76686326612a1eb3c2b32053bbcf3d8. Ask a friendly vulnerability researcher what I probably meant by saying that. Guess what? More confident as a result of knowing it.
The rest of your comment is just pique. "Why do online banks use two-factor auth?" Because the alternative is passwords. "There should be an explicit trust model!" Go ahead and build it. Because TLS is well-designed, your new scheme will work just fine with it.
Psst. I've got news for you. adb56780a76686326612a1eb3c2b32053bbcf3d8. Ask a friendly vulnerability researcher what I probably meant by saying that. Guess what? More confident as a result of knowing it.
The rest of your comment is just pique. "Why do online banks use two-factor auth?" Because the alternative is passwords. "There should be an explicit trust model!" Go ahead and build it. Because TLS is well-designed, your new scheme will work just fine with it.
That we know about...
> We're running an average of 3-5 years between protocol-level discoveries in TLS.
Everyone knows the weakness with our current system isn't the protocol--it's the "trusted" roots. There are upwards of 100 organizations that have roots installed on my computer and each of them is an attack surface. And it's frustrating because if I'm Google, there's no way I can protect myself from these other firm's security flaws. That is the part of SSL/TLS that needs to change. Getting certs from DNSSEC would be a good start...
Everyone knows the weakness with our current system isn't the protocol--it's the "trusted" roots. There are upwards of 100 organizations that have roots installed on my computer and each of them is an attack surface. And it's frustrating because if I'm Google, there's no way I can protect myself from these other firm's security flaws. That is the part of SSL/TLS that needs to change. Getting certs from DNSSEC would be a good start...
Getting certs from DNSSEC is morally equivalent to getting them from X509 PKIs.
Again: the problem we have is that the UX and policy for HTTPS/TLS is brittle, so that it's hard to recognize and even harder to react to misconfigurations like "we're trusting CAs who are not trustworthy".
Faced with a policy and UX problem, someone needs to explain to me how a reasonable next step is to bake a new PKI into the core of the Internet.
There is a reason the IETF-types are so gung-ho on DNSSEC. But it isn't that they know it's a sound replacement for the CA system. It's that it bothers them that DNS- the- protocol is insecure. And that's fine (I think their solution stands a good chance of making DNS even less secure, but whatever). But they shouldn't get to piggyback on other security issues to achieve their goal.
Again: the problem we have is that the UX and policy for HTTPS/TLS is brittle, so that it's hard to recognize and even harder to react to misconfigurations like "we're trusting CAs who are not trustworthy".
Faced with a policy and UX problem, someone needs to explain to me how a reasonable next step is to bake a new PKI into the core of the Internet.
There is a reason the IETF-types are so gung-ho on DNSSEC. But it isn't that they know it's a sound replacement for the CA system. It's that it bothers them that DNS- the- protocol is insecure. And that's fine (I think their solution stands a good chance of making DNS even less secure, but whatever). But they shouldn't get to piggyback on other security issues to achieve their goal.
> adb56780a76686326612a1eb3c2b32053bbcf3d8. Ask a friendly vulnerability researcher what I probably meant by saying that.
OK. Hey tptacek... :)
Mind elaborating a bit more, for those of us who don't happen to know any other vulnerability researcher who know what that hash means? The one vulnerability researcher I know had no idea what you were talking about.
OK. Hey tptacek... :)
Mind elaborating a bit more, for those of us who don't happen to know any other vulnerability researcher who know what that hash means? The one vulnerability researcher I know had no idea what you were talking about.
Here's another request for elaboration...
(and a meta-comment; OMG, look how quick google is getting hackernews into it's index these days!)
(and a meta-comment; OMG, look how quick google is getting hackernews into it's index these days!)
I'll let someone else explain, and let me be clear: not my bug.
I assume you're referring to the practice of releasing hashes of one's advisory to prove that you discovering it while giving the vendor time to fix their software before disclosing it publicly.
Google doesn't turn up anything for that particular hash, though, nor did I see anything on the Matasano website, but I'm probably looking in the wrong places. I don't claim to be a security researcher, after all, even if I try to keep up to date.
Google doesn't turn up anything for that particular hash, though, nor did I see anything on the Matasano website, but I'm probably looking in the wrong places. I don't claim to be a security researcher, after all, even if I try to keep up to date.
Ouch, that was a bad typo. I meant "discovered" not "discovering" and it's too late to edit.
So why did you say it and direct people to ask researchers what it means, if pretty much no one does?
If it works, why do all the online banks use two-factor authentication these days?
I don't know about where you are, but even if I show up at my bank branch in person, they do two-factor authentication (card + PIN).
I don't know about where you are, but even if I show up at my bank branch in person, they do two-factor authentication (card + PIN).
The card is not enough to authenticate you. It is enough to identify you. Slightly different concepts.
So card = identify. PIN = authenticate. That's not two factor.
The second factor would be an RSA key or a Digipass device.
So card = identify. PIN = authenticate. That's not two factor.
The second factor would be an RSA key or a Digipass device.
You are using the words "authenticate" and "identify" in ways that professionals do not. In reality, a card and a pin are two factors in an authentication system; your fingerprint is a third (biometric) factor which does not need yet another synonym for "identify" to describe; the reputation of your origin IP is a fourth factor, your behavior a fifth.
If it works, why do all the online banks use two-factor authentication these days?
Oh wait, there is the solution!
That's used to authenticate the client. SSL's job here is to authenticate the server. So no, that's not a solution.
Besides, it's completely preposterous to claim that HTTPS is useless just because it's not enough for banks. Should each website send an RSA Token to each user?
That's used to authenticate the client. SSL's job here is to authenticate the server. So no, that's not a solution.
Besides, it's completely preposterous to claim that HTTPS is useless just because it's not enough for banks. Should each website send an RSA Token to each user?
I've been quietly hoping that perhaps Google's Authenticator app might provide this for us... If there were a way for one of my websites to seed the Authenticator, I could provide an RSA-token-like 3rd factor to my logins effectively for free (at least to anyone with an iOS/Android device).
(I don't suppose anybody's more up-to-date than me on if/when that'll be possible?)
(I don't suppose anybody's more up-to-date than me on if/when that'll be possible?)
Two factor auth is more about stopping your login details being nicked and then used at a later time - not atall really a question of SSL, not to mention that as far as I can see this attack here would not be affected by it in the slighest except for future login attempts.
The idea of having a distributed certificate mechanism over a peer to peer net seems like it might be a good starting point. Essentially, you'd self-sign and serve out your certificate on your ports; possibly connecting to some sort of super-node. You get connections from other members of the net, and they'd send you some certificates; you'd cache the certs and their IP addresses. Then after a timeout, you'd broadcast your certificates to all the interested IPs.
Part of the intrinsic concept is that there's no authoritative identity service. Without an authority, you can't crack the authority.
Of course, this is just a sketch of an idea; it has the usual issues with peer to peer nets such as "evil majority wins". Plus, it has the potential to eat a good deal of bandwidth.
Regardless, I think it'd be a good idea to explore, probably in an academic setting first.
Part of the intrinsic concept is that there's no authoritative identity service. Without an authority, you can't crack the authority.
Of course, this is just a sketch of an idea; it has the usual issues with peer to peer nets such as "evil majority wins". Plus, it has the potential to eat a good deal of bandwidth.
Regardless, I think it'd be a good idea to explore, probably in an academic setting first.
Okay, so SSL dies. it's gone. Kaput.
Now what?
I get that a false sense of security is worse, but we haven't yet figured out a better way that is still decentralized and works with a wide variety of user skill levels.
Because people who aren't expert users deserve security too. And they deserve functionality.
Now what?
I get that a false sense of security is worse, but we haven't yet figured out a better way that is still decentralized and works with a wide variety of user skill levels.
Because people who aren't expert users deserve security too. And they deserve functionality.
people who aren't expert users deserve security too. And they deserve functionality.
Well, SSL certainly isn't giving serious security in the "My ISP has been intruded" attack model.
You can't have both security and ignorance. If you really want to be secure, you're going to have to learn how to be secure, and then to know how to implement it.
Well, SSL certainly isn't giving serious security in the "My ISP has been intruded" attack model.
You can't have both security and ignorance. If you really want to be secure, you're going to have to learn how to be secure, and then to know how to implement it.
Your ISP can be completely compromised and SSL/TLS will continue to work, even in its broken incarnation in your browser configuration.
Umm. What do you mean by work? If my ISP injects certain proxies in my route, they can unwrap the encrypted communication.
No they can't. That's not how TLS works. The problem we are talking about is not that SSL/TLS- the- protocol allows ISPs to decrypt traffic. It's that some browsers have been shipped with a certificate authority that is willing to sign Google CN's. Remove that CA's cert. What's your ISP going to do now?
A brief search for TLS MITM suggests to my inexperienced eye that there are indeed TLS attacks via MITM cert-swapping that the ISP can assert.
--- edit. Not looking for argument. Looking for facts.
- This is my top hit for 'tls mitm proxy'
http://www.delegate.org/delegate/mitm/
It's dated as '06, however.
- I can install Fiddler (Windows https debugger) on my machine and read https traffic in the clear.
- A competent admin assures me that Websense can read https traffic. Couldn't really dig real detail up on the websense sites though. This chap suggests the admin is not wrong (search for corporate, it's toward the end): http://www.carbonwind.net/blog/post/Random-SSLTLS-101%E2%80%...
--- edit. Not looking for argument. Looking for facts.
- This is my top hit for 'tls mitm proxy'
http://www.delegate.org/delegate/mitm/
It's dated as '06, however.
- I can install Fiddler (Windows https debugger) on my machine and read https traffic in the clear.
- A competent admin assures me that Websense can read https traffic. Couldn't really dig real detail up on the websense sites though. This chap suggests the admin is not wrong (search for corporate, it's toward the end): http://www.carbonwind.net/blog/post/Random-SSLTLS-101%E2%80%...
I have no idea how I might go about arguing with you; it's as if I were to argue "a brief search of the literature suggests that P is definitely NP". Give me something more specific and I'll give you the context behind it; right now, I don't know what you're talking about.
(Sigh). Fiddler pops the browser certificate warning when you use it; it's not breaking TLS.
You must just as productively say "my friend assures me AES is broken; maybe that's what Iran is doing." Just like your competent admin friend, there would be some reason for him to say that; it just wouldn't be relevant.
(Sigh). Fiddler pops the browser certificate warning when you use it; it's not breaking TLS.
You must just as productively say "my friend assures me AES is broken; maybe that's what Iran is doing." Just like your competent admin friend, there would be some reason for him to say that; it just wouldn't be relevant.
Well, rephrased, what I am led to believe is that Websense can read HTTPS traffic without sparking a certificate warning.
I don't have details on that, unfortunately.
I don't have details on that, unfortunately.
It is crazy that you're even entertaining the thought that the entire security model of the world wide web has been circumvented by WebSense. I guess they just really know how to keep a secret?
I am a little confused by the disparity between your statements and the statements here:
http://security.stackexchange.com/questions/2914/can-my-comp...
It sounds pretty clear to me that with some work on the adversary's part and lack of checking of the certificate chain, TLS can be subverted.
http://security.stackexchange.com/questions/2914/can-my-comp...
It sounds pretty clear to me that with some work on the adversary's part and lack of checking of the certificate chain, TLS can be subverted.
Websense doesn't break TLS or SSL or PKI. Websense abuses an organizations control over their own workstations to conduct a 'mitm' or 'proxy' of the TLS connection. It does that in a fairly straight forward manner.
Websense is used in organizations that distribute their own root ca key to the workstations behind it. The Websense machine is then given that root ca key and allowed to generate dynamic certs with it, so that a workstation with your organizational CA trusts them, but nobody on the regular inter webs will.
It's a really, really shitty way to do things, and effectively violates the trust of every user on your corporate network, but hey, they signed an agreement.
Websense is used in organizations that distribute their own root ca key to the workstations behind it. The Websense machine is then given that root ca key and allowed to generate dynamic certs with it, so that a workstation with your organizational CA trusts them, but nobody on the regular inter webs will.
It's a really, really shitty way to do things, and effectively violates the trust of every user on your corporate network, but hey, they signed an agreement.
Yes, if you don't check certificates you can subvert TLS. Also if you key your ciphers with zeroes. Don't do those things.
Use case 1: 60 year old man wants to access his bank online from his home. He has been using computer for 10 years, but only been using the internet actively for 5, and still requires help from IT for basic issues at work.
Use case 2: 40 year old man wants to use his laptop from starbucks for email. He has used computers for much of his life, but doesn't really understand how it works. He is on the road working 60-80 hours a week. He is taught to VPN in to work, but that is the extent of his understanding of security.
We're not talking about the use case 3: activist in Iran needs to communicate with compatriots. That is a much harder problem for which SSL is insufficient.
How do we set up a sufficiently easy system for use cases 1 and 2? Charging them $1,000 for a 2 day class in security is not going to work in scale, and nobody has yet written a security primer for dummies past the most basic of "don't give people your password and don't use your dog's name."
Use case 2: 40 year old man wants to use his laptop from starbucks for email. He has used computers for much of his life, but doesn't really understand how it works. He is on the road working 60-80 hours a week. He is taught to VPN in to work, but that is the extent of his understanding of security.
We're not talking about the use case 3: activist in Iran needs to communicate with compatriots. That is a much harder problem for which SSL is insufficient.
How do we set up a sufficiently easy system for use cases 1 and 2? Charging them $1,000 for a 2 day class in security is not going to work in scale, and nobody has yet written a security primer for dummies past the most basic of "don't give people your password and don't use your dog's name."
This is not true. There is no cryptosystem we know of that is more suited to "User Case 3" than TLS. There is a problem with the way activists in Iran are using TLS: to wit, they are trusting Mozilla, Microsoft, Apple, or Google to make decisions about who they trust. But TLS does not require them to do that. They are a point-and-click HOWTO away from not being in that position.
If Iranian activists want to trust Google for their sensitive email, all they have to do is track down Google's authentic certificate (by asking anybody outside of Iran to fetch it) and add it to their browser. Iran does not have the ability to break RSA. All they (apparently) have the ability to do is to con incompetent CAs into making new RSA signatures that some browsers are configured to believe.
If Iranian activists want to trust Google for their sensitive email, all they have to do is track down Google's authentic certificate (by asking anybody outside of Iran to fetch it) and add it to their browser. Iran does not have the ability to break RSA. All they (apparently) have the ability to do is to con incompetent CAs into making new RSA signatures that some browsers are configured to believe.
SSL was never decentralised. It was always centralised with CA's which is the issue.
We need a reputation based, distributed public key architecture.
We need a reputation based, distributed public key architecture.
So build one. Your preference actually has very little to do with the X509 CA architecture. Today we have a complex little forest of fiat CAs. No part of the TLS architecture prevents you from replacing that with an even more complex and more full-featured web of smaller CAs.
I'm not being sarcastic. Your decentralized reputation scheme could very well be better than our severely compromised system of central CAs.
I'm not being sarcastic. Your decentralized reputation scheme could very well be better than our severely compromised system of central CAs.
And the solution is? Getting everyone on to PGP/GPG? Explaining to the general public what a web of trust is and actually get them to use it in the correct fashion (rather then clicking 'trust' the same way they click through all dialog boxes)?
The irony here is, if you want "web of trust", you already have it; just remove all the certs from your browser and trust sites selectively.
Where's the "web" in that? Web of Trust is supposed to be a system where users 'tell' each other what they trust, forming a 'web' of trust links.
So when the certificate error comes up, ask your friends whether they trust it. You are talking about a web application that is almost "hello world" in Django or Rails.
So, build it. Then make it secure enough that any schmuck won't be able to hack it and serve fake 'trusts'. Then decentralize it so that governments like Iran's can't MITM it. Then solve the problem of having a single organization deploying thousands of fake nodes and poisoning the data.
After you've done that, yes, it'll exist.
After you've done that, yes, it'll exist.
[deleted]
DNSSEC is an alternative.
(Edit: Well, not really—have a look at the thread below.)
(Edit: Well, not really—have a look at the thread below.)
In what sense? DNSSEC is also a PKI which also has roots that can be compromised. Not only that, but it only works server-to-server (late in the game, we've decided "that's OK, everyone will just be a server!). And DNSSEC relies on HTTPS/TLS to actually protect content.
With DNSSEC when you request google.com you can verify the answer is actually google.com. (Edit: You can verify the validity of the DNS answer.)
No cryptographic system is perfect.
No cryptographic system is perfect.
This comment is tautological. The verification you're talking about works on the same principle as X.509 (SSL/TLS) does; all it does is attempt to give individual DNS zone holders the ability to sign their own names. But every zone has a parent zone upon whose security it depends.
The reality is that DNSSEC is a lot more fragile than even that. Even on paper (DNSSEC hasn't been deployed in the large successfully) it has gaps. For instance, did you know that as conceived in the standards, your browser isn't even meant to speak DNSSEC? Your browser doesn't run a full recursive cache --- in other words, your browser isn't a full DNS name server, which is why your computer has to be configured with the address of a name server. DNSSEC doesn't secure the leg between your computer and its name server.
"No cryptographic system is perfect" is a worthless sentiment. Only in the rarest instances do we know whether any system, from "hello world" to the Tacoma Narrows, is absolutely sound. Our job as engineers is to make determinations about which system is sounder. DNSSEC takes approximately the same architectural problems that X.509 has, rebuilds them from scratch in the context of a protocol that has for 20 years been riven with security flaws, and then still requires HTTPS/TLS to function. It is less sound than HTTPS/TLS.
The reality is that DNSSEC is a lot more fragile than even that. Even on paper (DNSSEC hasn't been deployed in the large successfully) it has gaps. For instance, did you know that as conceived in the standards, your browser isn't even meant to speak DNSSEC? Your browser doesn't run a full recursive cache --- in other words, your browser isn't a full DNS name server, which is why your computer has to be configured with the address of a name server. DNSSEC doesn't secure the leg between your computer and its name server.
"No cryptographic system is perfect" is a worthless sentiment. Only in the rarest instances do we know whether any system, from "hello world" to the Tacoma Narrows, is absolutely sound. Our job as engineers is to make determinations about which system is sounder. DNSSEC takes approximately the same architectural problems that X.509 has, rebuilds them from scratch in the context of a protocol that has for 20 years been riven with security flaws, and then still requires HTTPS/TLS to function. It is less sound than HTTPS/TLS.
What I meant was there are mechanisms that let you determine that a DNS answer is correct.
I won't say more regarding this matter because you know a lot more about cryptography than I do. What do you think the best solution for this kind of problem is? PGP?
I won't say more regarding this matter because you know a lot more about cryptography than I do. What do you think the best solution for this kind of problem is? PGP?
I literally think 99.999% of the problem with HTTPS/TLS is UI. The UI for certificate management and validation is virtually unchanged since the 1990s. More importantly, Mozilla, Google, Apple, and Microsoft --- however well they mean --- are not appropriate stewards for the security of the whole fucking Internet. We need the secure UX required to outsource CA management to trusted third parties that unskilled users can reasonably choose among.
Back to DNSSEC:
What we do not need to do is take this extremely complex policy problem and bake it further into the Internet's infrastructure, so that only the greybeards at the IETF and the product managers at the five largest software companies in the world get to make choices about the Internet's security model.
Today's HTTPS debacle was brought to you by a policy mistake. When we originally deployed HTTPS/TLS, we did not understand enough about the forces acting on us to make totally safe policy decisions. What we need is more flexibility and more thought, not the exact same system we have now baked into one of the core protocols on the Internet.
Back to DNSSEC:
What we do not need to do is take this extremely complex policy problem and bake it further into the Internet's infrastructure, so that only the greybeards at the IETF and the product managers at the five largest software companies in the world get to make choices about the Internet's security model.
Today's HTTPS debacle was brought to you by a policy mistake. When we originally deployed HTTPS/TLS, we did not understand enough about the forces acting on us to make totally safe policy decisions. What we need is more flexibility and more thought, not the exact same system we have now baked into one of the core protocols on the Internet.
Have you written about possible solutions? I'd be interested to hear them.
Wouldn't it be neat if there was a dialog somewhere in your browser that gave you the option of trusting anything Colin Percival trusted, or anything that the EFF trusted?
I had thought about something like this, sort of a combination of karma scores and netflix/pandora-style recommendations for ranking user content on sites like HN. I could say 'I like what tptacek has to say' and give your content a higher precedence for ME, rather than for the whole of the site user base. Others could say 'I dislike what tptacek has to say', and you get a corresponding drop for THAT USER, not everyone. Now add a chain - if I 'like' you, all that you 'like' gets a smaller, but significant bump for me, and so on. Add in 'OSCP' style repudiation if the source of your trust for someone changes their mind for any reason.
Moving this into authentication/trust - how do you 'start' something like this at an Internet scale, assuming actively hostile, nation-state level players, such as in this article? It seems very chicken-and-egg for something as critical as encryption and protection of important content.
Just thoughts - it seems there's some big issues I'm missing though, such as initial seeding for 'new' users en masse. I can also see the code to keep track of all the trust vectors, etc. becoming VERY complicated...
Moving this into authentication/trust - how do you 'start' something like this at an Internet scale, assuming actively hostile, nation-state level players, such as in this article? It seems very chicken-and-egg for something as critical as encryption and protection of important content.
Just thoughts - it seems there's some big issues I'm missing though, such as initial seeding for 'new' users en masse. I can also see the code to keep track of all the trust vectors, etc. becoming VERY complicated...
Seems like an awesome plan, but making it scale requires a lot of work. In this system, how do banks ensure their site shows up as secure in people's browsers? How do random sites of varying popularity?
Actually, for many people their bank seems like a good start for the trust chain; visit them in person and get the information you need for your trust root. And unlike the certificate companies, banks have end-users as their customers, not people who want certificates.
Actually, for many people their bank seems like a good start for the trust chain; visit them in person and get the information you need for your trust root. And unlike the certificate companies, banks have end-users as their customers, not people who want certificates.
So start with the CAs, and then allow your friends and their friends and the EFF to subtract from that set.
Startup opportunity?
I'd consider subscribing to a few services that provided plausible claims to properly curate lists of ssl cert fingerprints for at least the majority of my security-critical domains. Even if it were just limited to the major internet properties (start with google/yahoo/amazon/paypal/twitter/facebook/etc), and add in major (and minor) banks, government institutions... If someone started up a service claiming to have telephoned the appropriate security people at those places and confirmed the cert fingerprints via non-internet/real-world-confirmable means, I'd certainly consider paying a few tens of dollars a year for that... Especially if it integrated nicely with a browser/os plugin.
I'd consider subscribing to a few services that provided plausible claims to properly curate lists of ssl cert fingerprints for at least the majority of my security-critical domains. Even if it were just limited to the major internet properties (start with google/yahoo/amazon/paypal/twitter/facebook/etc), and add in major (and minor) banks, government institutions... If someone started up a service claiming to have telephoned the appropriate security people at those places and confirmed the cert fingerprints via non-internet/real-world-confirmable means, I'd certainly consider paying a few tens of dollars a year for that... Especially if it integrated nicely with a browser/os plugin.
And, hopefully, a way for Colin, the EFF, your friends, or Hacker News to say "Ummm, looks like the EFF trust list might have been compromised sometime in the last $n weeks..." and for you to be able to audit/rollback changes in that trust list, and/or compare changes with unrelated sources...
DNSSEC may have a lot of the same design limitations as HTTPS PKI, but it could still be an improvement if it represented a parallel, redundant piece of security.
But what we see is CAs authenticating cert applicants based on DNS (the ability to receive email verifies your "control" of the domain) and DNSSEC rooting to a Verisign-managed registry, just like the early days of SSL PKI.
But what we see is CAs authenticating cert applicants based on DNS (the ability to receive email verifies your "control" of the domain) and DNSSEC rooting to a Verisign-managed registry, just like the early days of SSL PKI.
Only if that parallel, redundant piece of security (a) isn't relied upon as a single point of failure by any component of the rest of the system (note how many DNSSEC advocates seem to want DNSSEC as a replacement for the X509 PKI), and (b) doesn't have 15 years of its own security vulnerabilities in store for us.
Yup.
a) a rare opportunity missed
b) I'd like to think we know more than we did 15 years ago, but compatibility with the existing DNS brings new challenges too
"With SSL when you make a request to google.com you can verify the answer is actually from google.com."
That's exactly what SSL is supposed to do, and tptacek is saying DNSSEC has the same problems as any PKI, including SSL.
And more importantly, using DNSSEC without SSL, even if you know you have the right IP address you don't you're not being MITM'd.
That's exactly what SSL is supposed to do, and tptacek is saying DNSSEC has the same problems as any PKI, including SSL.
And more importantly, using DNSSEC without SSL, even if you know you have the right IP address you don't you're not being MITM'd.
That may be true, but you have no guarantee that the IP that is returned actually routes where it should, or that a resulting connection is to one of google's actual servers.
note: Nothing against dnssec. I think it is an improvement, but I don't see how it would have helped in the situation in question.
note: Nothing against dnssec. I think it is an improvement, but I don't see how it would have helped in the situation in question.
I don't think DNSSEC is an improvement. I think that when you take a fragile and problematic security model, reimplement it from the bottom up in a setting that's even more restrictive than HTTPS, bake the result into the core of the Internet (or rather, the fraction of the core of the Internet that knows how to be a full-fledged DNS server), cause untold disruption the network as a whole and incur tens of millions of dollars in administrative overhead that could have gone to other security objectives, you are very likely looking at a measure that maybe just maybe might be a tiny step backwards.
[deleted]
SSL leads them into that already but clicking the "trust" button automatically.
We need a reputation based, distributed public key architecture.
We need a reputation based, distributed public key architecture.
As I understand it, SSL (or TLS more properly) is fine, it's the HTTPS system and it's trust model that are broken.
</pedantic>
</pedantic>
Chrome users should be protected from this by the public key pinning feature [http://www.imperialviolet.org/2011/05/04/pinning.html], right?
Sounds like it. But this isn't an architectural solution. All this does is layer an additional level of "trust" requirements onto the existing protocol. The "pinning whitelist" is isomorphic to the root CA list and can be compromised in exactly the same way.
Do we actually know how many SSL certs Google uses, and for what?
From what I can see:
- Google Search & Google+ (https://encrypted.google.com/ https://plus.google.com/) are using a *.google.com from GeoTrust/Google Internet Authority
- Google Mail (https://www.google.com/accounts/) is using a www.google.com from VeriSign/Thawte
Ofcourse I'm also afraid that this is indeed a MITM attack against Iranian users.
With SSL certs that costs less than $15 you can expect that things cannot be thoroughly checked, however a Wildcard DigiNotar SSL cert is costing you € 750 a year (in a 4 year contract http://diginotar.nl/OnlinePrijsindicatie/tabid/1417/Default....), you would expect that these things would not be possible.
If they however hacked the root CA, it's even more scary, also Vasco (the mother company) makes virtually every Two-factor authentication used for Dutch Banking..
From what I can see:
- Google Search & Google+ (https://encrypted.google.com/ https://plus.google.com/) are using a *.google.com from GeoTrust/Google Internet Authority
- Google Mail (https://www.google.com/accounts/) is using a www.google.com from VeriSign/Thawte
Ofcourse I'm also afraid that this is indeed a MITM attack against Iranian users.
With SSL certs that costs less than $15 you can expect that things cannot be thoroughly checked, however a Wildcard DigiNotar SSL cert is costing you € 750 a year (in a 4 year contract http://diginotar.nl/OnlinePrijsindicatie/tabid/1417/Default....), you would expect that these things would not be possible.
If they however hacked the root CA, it's even more scary, also Vasco (the mother company) makes virtually every Two-factor authentication used for Dutch Banking..
Scary indeed. Also responsible for authentication of DigiD, online taxes, pension funds, Chamber of Commerce, Ministry of Security and Justice, local governments, etc.
Didn't check it myself, but apparently DigiD for instance is on a different CA/root. DigiD is the Dutch "unified account" for all online government services: you can take out student loans, submit taxes, etc.
http://www.diginotar.nl/Aanvragen/Lopendeprojecten/DigiDMach... They have this listed as an active project, so they are definitely involved. Could still be on a different CA though. And of course _if_ they were hacked.
if root is compromised it sounds promising :
http://www.vasco.com/company/press_room/news_archive/2011/ac...
"...DigiNotar is an official Dutch certification authority, capable of issuing, validating and registering certificates (identities) of Dutch nationals and entities that are recognized throughout the European Union and are used to authenticate government applications. As such, DigiNotar provides VASCO with a strong foothold in the Dutch eGovernment market with the potential to expand the product line to government applications in other countries. Currently, DigiNotar’s market scope for its CA activities is limited to the Netherlands. VASCO may decide to introduce DigiNotar as a certification authority in other EU countries...."
all that security was riding on 10M euros (with such [meager] amounts in play, one would think that it would be easier for a player like Iran just buy an authority than to crack/hack it, though seems like VASCO was faster (if of course VASCO isn't in the game as well) :) :
"...VASCO acquired DigiNotar in stock and asset purchase for aggregated cash consideration of Euro 10.0 million..."
what is the cost in Netherlands to have a reasonably secure office building with some access controlled areas suitable for CA authority core operations? Sounds like very cheap.
http://www.vasco.com/company/press_room/news_archive/2011/ac...
"...DigiNotar is an official Dutch certification authority, capable of issuing, validating and registering certificates (identities) of Dutch nationals and entities that are recognized throughout the European Union and are used to authenticate government applications. As such, DigiNotar provides VASCO with a strong foothold in the Dutch eGovernment market with the potential to expand the product line to government applications in other countries. Currently, DigiNotar’s market scope for its CA activities is limited to the Netherlands. VASCO may decide to introduce DigiNotar as a certification authority in other EU countries...."
all that security was riding on 10M euros (with such [meager] amounts in play, one would think that it would be easier for a player like Iran just buy an authority than to crack/hack it, though seems like VASCO was faster (if of course VASCO isn't in the game as well) :) :
"...VASCO acquired DigiNotar in stock and asset purchase for aggregated cash consideration of Euro 10.0 million..."
what is the cost in Netherlands to have a reasonably secure office building with some access controlled areas suitable for CA authority core operations? Sounds like very cheap.
> to expand the product line to government applications in other countries.
... and so they have
... and so they have
You forget their possible debt...
nope. VASCO is a NASDAQ-ed "Inc" and would have mentioned any additionally assumed materially important liabilities in the official press release.
Posting from Iran, Im really worried about the current security status. Iran's opposition mostly exists on internet these days and its very seriously flawed.
Man In The Middle attacks are increasing and users usually ignore error messages about them. (Firefox throws an error dialog but it has an 'I understand the risks' button. People just ignore the error).
Also, last year many Iranian FriendFeed users were arrested and the goverment knew about all their private discussions on FriendFeed. (FriendFeed has been censored since the beggining. But it suddenly became uncensored for a day or two. On the other hand, FriendFeed generates an 'auth' key for each user and lets him see his RSS feed using that key. And puts the auth key in every page: goverment probably collected auth keys and used it to read discussions of people they arrested)
Goverments using internet to spy on their civilians is not a myth. Anonymity, trusting the cloud and related issues seem far more important when you suddenly find out a friend of yours has been arrested and his location and charges is unknown.
Man In The Middle attacks are increasing and users usually ignore error messages about them. (Firefox throws an error dialog but it has an 'I understand the risks' button. People just ignore the error).
Also, last year many Iranian FriendFeed users were arrested and the goverment knew about all their private discussions on FriendFeed. (FriendFeed has been censored since the beggining. But it suddenly became uncensored for a day or two. On the other hand, FriendFeed generates an 'auth' key for each user and lets him see his RSS feed using that key. And puts the auth key in every page: goverment probably collected auth keys and used it to read discussions of people they arrested)
Goverments using internet to spy on their civilians is not a myth. Anonymity, trusting the cloud and related issues seem far more important when you suddenly find out a friend of yours has been arrested and his location and charges is unknown.
"Man In The Middle attacks are increasing and users usually ignore error messages about them"
Note that the reported MiTM attack should not result in a popup warning, because the CA certificate used in the MiTM is supposedly technically valid. Does anybody know which browsers include this CA? Browser vendors should consider removing it based on ethical concerns, especially if this MiTM attack is being performed very broadly, at the country level.
Note that the reported MiTM attack should not result in a popup warning, because the CA certificate used in the MiTM is supposedly technically valid. Does anybody know which browsers include this CA? Browser vendors should consider removing it based on ethical concerns, especially if this MiTM attack is being performed very broadly, at the country level.
Mozilla is spinning up new releases to remove the cert.
See http://blog.mozilla.com/security/2011/08/29/fraudulent-googl...
Instructions on how to delete it yourself are available at http://support.mozilla.com/en-US/kb/deleting-diginotar-ca-ce...
See http://blog.mozilla.com/security/2011/08/29/fraudulent-googl...
Instructions on how to delete it yourself are available at http://support.mozilla.com/en-US/kb/deleting-diginotar-ca-ce...
They really ought to add a search field to that list view.
[deleted]
Under such conditions it is obviously unsafe to trust any private communications on the open internet (including sites that use SSL to encrypt data on the wire). You should ONLY use systems that ensure your content is encrypted for a key that YOU (not your browser) explicitly trust. This means using GnuPG and exchanging keys in a reliable offline medium with anyone with whom you want to communicate, basically.
Alternatively, you can use i2p and i2p outproxies, but i2p may be vulnerable to similar poisoning attacks if the government had an interest in perpetrating them. That said, it's probably much safer to use an i2p outproxy for your browsing anyway, and definitely much safer to use eepsites.
Alternatively, you can use i2p and i2p outproxies, but i2p may be vulnerable to similar poisoning attacks if the government had an interest in perpetrating them. That said, it's probably much safer to use an i2p outproxy for your browsing anyway, and definitely much safer to use eepsites.
How could one technical individual protect himself is one thing, having a secure-by-design communication channel is another thing. Whole country is being spied like that and most people dont even know/care about it. They just want to use Facebook or some 'cool' service.
Security and convenience will always be at odds with one another. If you aren't going to take the precautions, your alternatives are to watch what you write or go to jail. Anything that relies upon any unencrypted traffic for bootstrapping, etc., is unreliable when you're against a state-level player like this, because they can do just what they're doing now and replace the real response with a fake one.
As such, the only way to ensure your electronic communications are safe is to get the information necessary to bootstrap the crypto from a medium where the government has no ability to poison, which means offline transmission (CDs/USB disks). And then you still have to be careful because if the government gets the private key of your compatriot all of your conversations will be readable.
The only way to provide security for the people of Iran in a reasonable manner is to educate them on PGP and key exchange. This is not the time to talk about fairy dust, because it's not going to help anyone at this point. When you're transmitting information that will get you thrown in jail or worse, you don't dink around -- they need something tried and true, and need to understand the risks and costs associated with the communications platforms they're using.
As such, the only way to ensure your electronic communications are safe is to get the information necessary to bootstrap the crypto from a medium where the government has no ability to poison, which means offline transmission (CDs/USB disks). And then you still have to be careful because if the government gets the private key of your compatriot all of your conversations will be readable.
The only way to provide security for the people of Iran in a reasonable manner is to educate them on PGP and key exchange. This is not the time to talk about fairy dust, because it's not going to help anyone at this point. When you're transmitting information that will get you thrown in jail or worse, you don't dink around -- they need something tried and true, and need to understand the risks and costs associated with the communications platforms they're using.
[deleted]
If you want to dork with Facebook and see pictures of your neighbor's cat, that's fine, but in my opinion, it's not worth the risk (if any), and it's useless to want/expect meaningful security. I don't even know if seeing pictures of cats is a problem in Iran. :-)
If you want to communicate with other people securely, then, in my opinion, then everyone in that communications group needs to consider learning information security and operational security, and then applying it. It's not simple, it's not easy, but if you want to be secure, you're going to have to plan to be serious.
If you want to communicate with other people securely, then, in my opinion, then everyone in that communications group needs to consider learning information security and operational security, and then applying it. It's not simple, it's not easy, but if you want to be secure, you're going to have to plan to be serious.
It's a catch 22 when it comes to repressive regimes. You've swapped keys and are communicating with all your friends on a perfectly secure network. Now you and your friends are in jail on charges of conspiracy.
The only solution I can think of is a false door method, where you send some fake communication over one channel and somehow hide the encrypted channel.
The only solution I can think of is a false door method, where you send some fake communication over one channel and somehow hide the encrypted channel.
>The only solution I can think of is a false door method, where you send some fake communication over one channel and somehow hide the encrypted channel.
That's steganography, and there are some open source programs for that. Steghide[1], for example, can hide encrypted data in JPEG images.
[1]: http://steghide.sourceforge.net/
That's steganography, and there are some open source programs for that. Steghide[1], for example, can hide encrypted data in JPEG images.
[1]: http://steghide.sourceforge.net/
An alternative to steganography is 'chaffing and winnowing'. Ronald Rivest describes the technique in this paper: http://people.csail.mit.edu/rivest/Chaffing.txt
Stego's actually great here. Stay on the insecure or 'fake-secure' (ala this MITM) links and put out a cover story for yourself. Then communicate for realsies on stego.
And.. if your cover gives reason for you to put out a lot of data in forms that are easily stego'd, you're in good shape.
And.. if your cover gives reason for you to put out a lot of data in forms that are easily stego'd, you're in good shape.
I assure you, I don't pretend to have a guide to security in this sort of situation. But I am utterly certain that you have to take it seriously.
edit: You refer to something that is either steganography or something in that class of communication.
edit: You refer to something that is either steganography or something in that class of communication.
Azizam, unless you actually know the players involved in every hop of the loop, do not put your precious life in danger. If you are looking to organize, like a smart bache Terani you should go asymmetric on the the goons. Think sneaker nets, etc. I further suggest that you do not put your trust in superficially maintained hostilities between the west and the flea ridden mullahs. Remember those two brothers handed to Iran from US embassy. In one of those Persian Gulf states. They were hanged if you recall. Stenography, never signaling overt use of crypt, etc. are recommended. Qorbanat.
Arrested people werent organizing anything. They just had lots of political talks like analyzing Iran's current situation.
Goverment isnt trying to spy specific people for specific reasons. They are trying to spy everyone.
Goverment isnt trying to spy specific people for specific reasons. They are trying to spy everyone.
http://www.cabinetmagazine.org/issues/40/sherman.php
Communicate in the open free from the molestations of ahrimanan.
Communicate in the open free from the molestations of ahrimanan.
If you expect that you would only get targeted if you actively communicate about things your government doesn't like, but not just because you use a VPN or similar, then you should get a VPN in a country somewhat less likely to cause you problems.
If you expect that the use of secure encryption at all would get you disappeared, you're screwed. And the previous situation can turn into this one on a whim.
Either way, the long-term solution does not involve technology; it involves emigration.
If you expect that the use of secure encryption at all would get you disappeared, you're screwed. And the previous situation can turn into this one on a whim.
Either way, the long-term solution does not involve technology; it involves emigration.
I don't know how is in Iran, but I can tell you how it was in Romania before 1989 (and I guess that's pretty close to what is happening there).
It was close to impossible to emigrate legally, they would use anything to stop you. They would make you lose your job (or even do that to members of your family), they would interrogate you and members of your family (and don't think about any human rights).
A friend of my father was shot on the spot when they saw he was using a boat to cross the Danube to Yugoslavia.
It's not that simple to escape, especially with your family. You're living in a different world.
Edit: spelling
It was close to impossible to emigrate legally, they would use anything to stop you. They would make you lose your job (or even do that to members of your family), they would interrogate you and members of your family (and don't think about any human rights).
A friend of my father was shot on the spot when they saw he was using a boat to cross the Danube to Yugoslavia.
It's not that simple to escape, especially with your family. You're living in a different world.
Edit: spelling
I certainly would assume the same holds true, yes; I didn't intend to imply otherwise. It still seems like the right long-term solution, just a very difficult one.
And longer term, revolution.
They all look so similar :
http://www.toptenz.net/top-10-most-notable-national-revoluti...
yet some of them are (as of 17:25 PST 08/29/2011 AD) classified as "bad" and some as "good"
http://www.toptenz.net/top-10-most-notable-national-revoluti...
yet some of them are (as of 17:25 PST 08/29/2011 AD) classified as "bad" and some as "good"
Since you are posting from Iran, can you verify this certificate is indeed being presented?
Also, how are people sure this is being perpetuated by the Iranian government? I'm asking because I see no evidence in the pastebin dumps, yet many people here seem sure the Iranian government is behind this.
There was another indecent earlier this year for which Iran was assumed responsible. This turned out to be false (http://www.computerworld.com/s/article/9215245/Solo_Iranian_...)
Also, how are people sure this is being perpetuated by the Iranian government? I'm asking because I see no evidence in the pastebin dumps, yet many people here seem sure the Iranian government is behind this.
There was another indecent earlier this year for which Iran was assumed responsible. This turned out to be false (http://www.computerworld.com/s/article/9215245/Solo_Iranian_...)
I can confirm it, too.
My brother works in a company that produces spying software for government. Days ago, he told me he himself has written several programs to spy on yahoo, hotmail and gmail but he thought they couldn't deploy the gmail program because of https. I guess, he should think again.
I am scared. My only hope was SSL and I can't trust that anymore?
My brother works in a company that produces spying software for government. Days ago, he told me he himself has written several programs to spy on yahoo, hotmail and gmail but he thought they couldn't deploy the gmail program because of https. I guess, he should think again.
I am scared. My only hope was SSL and I can't trust that anymore?
You should tell your brother not to do that, very sternly. Your brother is killing people. This is not a joke.
Yes. I can confirm that without using a proxy, DigiNotar's CA is being used.
Who might/could do this except for the goverment?
Who might/could do this except for the goverment?
Thanks for checking. Could you run the following? Thanks in advance.
tracert mail.google.com
tracert mail.google.com
I did traceroute google.com/mail.google.com. nothing unusual happened:
[1-7 are ISP routers]
8. 78.38.255.89
9. 78.38.245.17
10. 213.248.76.5
11. 80.91.248.94
12. 80.91.253.118
13. 213.155.130.243
14. 213.248.83.94
15. 72.14.238.232
16. 209.85.251.88
17. 209.85.255.234
18. 209.85.255.231
19. 64.233.175.98
I used mtr and the route to google is changing every several seconds, but I thinks it's normal.
All I know is that internet blocking happens in LCT [78.38.255.] or KAMYARAN [78.38.245.].
[1-7 are ISP routers]
8. 78.38.255.89
9. 78.38.245.17
10. 213.248.76.5
11. 80.91.248.94
12. 80.91.253.118
13. 213.155.130.243
14. 213.248.83.94
15. 72.14.238.232
16. 209.85.251.88
17. 209.85.255.234
18. 209.85.255.231
19. 64.233.175.98
I used mtr and the route to google is changing every several seconds, but I thinks it's normal.
All I know is that internet blocking happens in LCT [78.38.255.] or KAMYARAN [78.38.245.].
What are the implications of this? It is potentially unsecured to visit gmail.com from anywhere? Is this web-interface only, or is IMAP/POP access also vulnerable?
The consensus seems to be that Iran is poisoning intra-country connections to attach this certificate to gmail.com instead of the real certificate, so this would only be occurring where Iran controlled the network infrastructure. Since the certificate is signed by a trusted CA, no warning is provided to the user that the certificate may be unsafe.
GMail still shows a certificate issued by Thawte for me (in the USA).
GMail still shows a certificate issued by Thawte for me (in the USA).
>The consensus seems to be that Iran is poisoning intra-country connections
more precisely they can poison any traffic (CA-ed by Diginotar) that passes through the routers/wires under Iran's control, that can be anything what they have already hacked into before as well as just redirected traffic using BGP similar like this
http://www.washingtontimes.com/news/2010/nov/15/internet-tra...
Btw, aren't China and Iran collaborating usually? There is potential for synergy.
more precisely they can poison any traffic (CA-ed by Diginotar) that passes through the routers/wires under Iran's control, that can be anything what they have already hacked into before as well as just redirected traffic using BGP similar like this
http://www.washingtontimes.com/news/2010/nov/15/internet-tra...
Btw, aren't China and Iran collaborating usually? There is potential for synergy.
I'm confused about how this was detected. The original report provided this screenshot:
http://i.imgur.com/hs0H4.jpg
If it is a case of a root CA signing a cert for someone else, this shouldn't have actually produced an error. What did the MITMers screw up here?
http://i.imgur.com/hs0H4.jpg
If it is a case of a root CA signing a cert for someone else, this shouldn't have actually produced an error. What did the MITMers screw up here?
Chrome feature, as noted here: https://news.ycombinator.com/item?id=2938905
This attack could of hit people in other countries as well. Small well places malicious BGP updates can reroute traffic into Iran.....
If your communications can land you in jail or get you killed don't use the internet (or even a computer, keystroke loggers are easy to install and very hard to detect), no matter how clever you think you are, and no matter how many 'lock' icons appear in your browser.
In such cases paranoia is perfectly justified.
It's a real pity this requires a code update because that means that the change will take long to propagate and will likely never be really complete, at the same time I'm sure there are good reasons for that and that an automated process to revoke just any certificate could itself probably be used as an attack vector.
What would happen if they simply revoked the root certificate that was used to sign this fake?
In such cases paranoia is perfectly justified.
It's a real pity this requires a code update because that means that the change will take long to propagate and will likely never be really complete, at the same time I'm sure there are good reasons for that and that an automated process to revoke just any certificate could itself probably be used as an attack vector.
What would happen if they simply revoked the root certificate that was used to sign this fake?
I am no hacker so I have almost no idea what's going on.
MITM = Man In The Middle.
Does this mean that Iran is eavesdropping on gmail users IN Iran? Or outside their country too?
Does anyone mind sharing what this means to the end user?
I did block the certificate on my Air as wxs mentioned. http://news.ycombinator.com/item?id=2938755
MITM = Man In The Middle.
Does this mean that Iran is eavesdropping on gmail users IN Iran? Or outside their country too?
Does anyone mind sharing what this means to the end user?
I did block the certificate on my Air as wxs mentioned. http://news.ycombinator.com/item?id=2938755
http://translate.google.com/translate?tl=en&u=http%3A%2F...
Fraudulent certificates were given out for:
().mozilla.org (backdoored software?)
().wordpress.com
().torproject.org
().yahoo.com
And Baladin (an Iranian social network)