Perfect MITM Attacks With No-Check SSL Certs 300
StartCom writes "In a previous article I reported about Man-In-The-Middle attacks and spotlighted an example showing that they really happen. MITM attacks just got easier. In the attack described previously, untrusted certificates from an unknown issuer were used. Want to make the attack perfect with no error and a fully trusted certificate? No problem, just head over to one of Comodo's resellers. Screenshots and disclosure provided at the link."
Don't do this at home (Score:5, Insightful)
While the link is already being slashdotted ...
I hope the article author understands that unless he's really lucky, he is in deep legal trouble already. It's not the first time that the messenger was slaughtered, although the message was honorable.
Gotta think over the SSL certs one more. I never really liked the mechanism behind it, i like it even less now.
Re:Don't do this at home (Score:5, Informative)
source of the slashdotted page :
----
In a previous article I reported about Man-In-The-Middle (MITM) attacks and if they really happen. Unfortunately it does happen as some testimonials confirm. Now itâ(TM)s even easier because in the attack described previously, untrusted certificates from an unknown issuer were used. Want to make the attack perfect with no error and fully trusted certificate? No problem, just head over to one of Comodoâ(TM)s resellers.
In an unrelated event which was briefly mentioned at the dev.tech.crypto mailing list of Mozilla, something strange happened. During my attempt to verify and understand who stands behind the sending of fraudulent âoereminderâ email messages tricking our customers, I created a certificate from the source I was following. And my certificate was issued without any further questions.
This prompted me to create another certificate through them, but this time by using a domain name which should never be issued to me. For the purpose of testing, I selected the domain mozilla.com (Iâ(TM)m certain they will forgive me). Five minutes later I was in the possession of a legitimate certificate issued to mozilla.com - no questions asked - no verification checks done - no control validation - no subscriber agreement presented, nothing.
With the understanding about MITM attacks, the severity of this practice is obvious. No encryption is worth anything if an attacker can implant himself between the client and the server. With a completely legitimate and trusted certificate, the attack is perfect. No warning and no error.
--
there you go, have a nice xmas and slashdot less
Re:Don't do this at home (Score:5, Insightful)
Oh, dear. So who certifies the certifiers?
Re: (Score:3, Insightful)
The suppliers of web browsers - Microsoft, Mozilla, Opera, Apple (Safari), KDE (Konqueror), Google (Chrome).
Re:Don't do this at home (Score:5, Interesting)
And they don't care about security (nor do the users).
That's why self-signed certs aren't really more risky than CA signed certs in practice.
http://it.slashdot.org/comments.pl?sid=1041927&cid=25890305 [slashdot.org]
http://ask.slashdot.org/comments.pl?sid=534356&cid=23199022 [slashdot.org]
I've probably posted others, but I bet "everyone" is still going to leave the dozens of CA certs in their browsers, and Mozilla and friends aren't going to do the SSH style thing - warn user if the cert changes for whatever reason- even if it's a valid cert.
I'd like to know if my bank's cert suddenly changed from the old cert to some cert signed by some CA in Elbonia. :)
Re:Don't do this at home (Score:4, Interesting)
Which would be the most sensible thing. Especially if the old certificate was nowhere near due to expire and the details on the new one are very different.
even if it's a valid cert.
"Valid" in this context meaning somehow connected to a CA trusted by the browser. Which in this kind of case may be less trustworthy than a self signed certificate. But guess which one Firefox 3 is going to make a song and dance about...
Re: (Score:3, Insightful)
Firefox is right to warn. (Score:5, Interesting)
The company that I worked at used a MITM attack with self signed certificates to read everyone's HTTPS stuff during the financial crisis. I was quite surprised to find that my bank and my broker's certificates were rejected by my Firefox, and that, upon inspection, the issuer was actually my company. IE, company issued, didn't warn me, and neither did Chrome, and I have to confess that when Firefox complained, I would often switch to Chrome, because it didn't. Then, one day I looked at the certificate in Firefox, and I discovered just what that warning meant. My company was spying on me.
Re:Don't do this at home (Score:4, Interesting)
I made a variation of this point to management where I worked a couple of years ago. My purpose was to promote the idea of building a corporate PKI rooted in our own Certificate Authority. You can think of this as a self-signed cert with structure.
The initiative had particular value for us because we deploy and remotely manage a large population of network appliances at customer sites. It's far more efficient for a web client to install a single CA cert than to request trust for each of the hundreds of server certs individually. Moreover, if a rogue cert ever does pop up, the chain will not silently resolve to our CA cert. (It might, as the article points out, resolve to some careless CA, whose reputation, I hope, will diminish accordingly. But I wasn't trying to improve certificate practices worldwide.)
Anyway, management was fine with the part about server authentication for our internal operations. Management was much more hesitant about giving out our CA cert to customers and partners in order to connect to our portals.
Why? The answer, as best I could understand, was the risk of a perception by customers that installing our CA cert would somehow weaken the security of their browsers. And so, because of this perception, we instead sent cert requests to a commercial CA, which as far as I can tell performed no verification whatever on the requests, apart from billing for whatever that may be worth. This was for the "industrial grade" certs, no less, the ones which were supposed to trigger identity checks on the requestor.
So it seems that perception trumps reality just as commercial CAs would wish in their wildest dreams. A CA cert explicitly given to you out of band by a known entity is perceived as less strong than a preinstalled CA cert from a completely unknown entity with questionable practices. Hmm. We have a way to go.
Re: (Score:2)
no, they only trust the root certificate authorities, who in turn trust their partners, who in turn trust their resellers, who in turn trust their friends, who in turn trusts Vladimir 'the violator' Ilvymich.
So, how long before someone buys a Microsoft.com certificate and supplies some critical 'updates'?
Re: (Score:3, Interesting)
I've been following the mozilla cacert bug for years. They've held off on including them as a trusted root because they haven't passed an expensive audit. However, their automated checks at least ensure that you have control of the domain that you're requesting a certificate for.
I've always thought that this would be a good approach for issuing free or dirt cheap certificates: When somebody applies for a certificate they are given some file to serve up from their webroot. Every week for three weeks a ne
Re: (Score:3, Funny)
I have a much bigger concern. Who certifies those who certify the certifiers?
Re: (Score:2, Funny)
Simple. We give the MITM attackers the power to certify the certifiers. That way we have a system of checks and balances.
Re: (Score:2, Funny)
Re: (Score:3, Funny)
Nobody. They don't have an HTTPS site.
Re:Don't do this at home (Score:5, Informative)
Folks who are surprised should definitely check out the list of Certificate Authorities. In Firefox Prefences -> Advanced -> Encryption -> View Certificates -> Authorities Tab
The first one is TÃoeRKTRUST Elektronik Sertifika HizmetSaÄYlayıcısı.
And its much worse in IE -- Internet Option-> Certificates -> Trusted Root Cert. Autho. I have not heard of 25% of the Authorities.
As the wise put it, security is only as strong as the weakest link.
Re:Don't do this at home (Score:4, Interesting)
Well, I have to admit I was surprised. I hadn't looked at the list of CAs in a while; it seems like the last time I went in there, it only had a handful of entries in it. (Verisign, Thawte, maybe a couple of others.)
I'm giving some very serious thought right now to just deleting every company on that list that I haven't heard of, or that I don't think has enough of a profile to be seriously harmed by allegations of sloppy issuing. Although from some other comments in the thread it sounds like even the big-name CAs have been lazy for years and haven't gotten called on it.
Having a bunch of Turkish CAs in my trusted root doesn't seem like it adds much in the way of security; the chances of me accessing a site that's legitimately using a cert from them -- near zero -- seems significantly lower than someone taking advantage of them to create a fake cert for my bank. (Not necessarily because their security is worse than a US-based CA, but just because while there's a chance someone at the US CA might have heard of my bank and think that it's funny someone's requesting a CA from their domain, I doubt anyone at the Turkish CA would have heard of it. If I were going to get a forged cert, I'd definitely go to a CA where they'd be unfamiliar with the target, just to stack the odds that much more in my favor. So it would seem that only having "local" CAs, ones you're likely to encounter legitimate certs from, in your trust chain is probably a good idea. Someone in Turkey might want to get rid of the minor US certifiers if they don't use them, too.)
Perhaps at some point during the browser-installation process, users should be prompted to select what countries, regions, or jurisdictions they're interested in installing CA certs for. The question could be phrased as "in what countries do you regularly do e-business or use secure web sites?" or something similar. Sure, this would eliminate much of the international market for CAs -- US-based ebusiness sites couldn't shop around for certificates quite as much as they perhaps do now, and vice versa -- but I think that would be significantly better than allowing the whole idea of certificates to be undermined into uselessness.
Of course, maybe that's just rearranging the deck chairs on the Titanic, and the safest thing to do is just throw away the whole paid Certificate Authority concept, blow away all the preinstalled CAs, and then have users build up trust on a per-site basis. This assumes users won't be stupid about what they accept, though, so it's probably doomed from the start.
Re: (Score:2)
Actually, the certifiers should be setup to police themselves. Make it public that any verify that screws up gets dropped from your browser. Giving incentive for verisign or comodo to try to compromise their competitors.
Re:Don't do this at home (Score:4, Insightful)
Gotta think over the SSL certs one more. I never really liked the mechanism behind it, i like it even less now.
The current mechanism is that the site owner pays a particular CA to identify them, and end-users/browsers trust any CA to identify any site (they can't know which CA the site owner actually paid). Site owners (the ones paying the bills) have no incentive to demand that the CA be competent.
A better system would have the end-user pay someone they trust to identify the site; they are directly paying for the identification service and can take their business elsewhere if they get crap service. This would also mean that the site owners don't have to pay someone who, really, can't actually provide any assurances to the end-users (because all CA-signed certs are treated the same). Better to just have everyone go self-signed, and then let someone (paid by the end-users) keep records of who used what cert when as seen by what network routes.
Mapping to real-world identities is a separate issue (only provided by "extended validation" or whatever certs due to browser UI issues), and is (1) rather expensive because you need people involved to look at paperwork and such and (2) mostly isn't needed, because you'll generally find IRL groups' sites by communication from those groups (eg, my electric bill has the electric company's URL printed on it, I don't need to look them up in google and then verify that I got pointed to the right place).
Re: (Score:2)
(they can't know which CA the site owner actually paid)
Isn't that what the 'issued by' field is for in a certificate?
Re: (Score:2)
(they can't know which CA the site owner actually paid)
Isn't that what the 'issued by' field is for in a certificate?
No, that says which CA issues that particular cert. Which may not be the same CA that the site owner paid, for example if I pay Verisign for a cert for my site and when you visit you get a cert from "one of Comodo's resellers", you really have no way to know that I didn't buy a cert from them and you shouldn't trust it.
Re: (Score:3, Informative)
Unless you've already decided that you don't trust Comodo, for this reason, and have struck them from your list of trusted authorities.
Re: (Score:2)
Most people just look for the padlock. Do they even know how to inspect a certificate?
Re:Don't do this at home (Score:4, Insightful)
Pesronally I'd like VISA and Mastercard to give me Root CA certs to use for purchasing on line - then if they foul up and someone gets a dodgy cert then they pick up the bill.
As it is, I don't think anyone would be liable (except yourself) to pick up the cost of shenanigans
Re: (Score:2)
Pesronally I'd like VISA and Mastercard to give me Root CA certs to use for purchasing on line - then if they foul up and someone gets a dodgy cert then they pick up the bill.
Hey, I like that idea. But it would need a way for the site to have multiple certificates where the user chooses which one they want (does SSL/TLS permit this?), and support for this in the browser UI... I suppose the root cert would probably come on a mini-CD or USB stick when they mail your card.
Re: (Score:3, Insightful)
Or just make users choose their card type before you present an input box for the number and redirect to the appropriate domain.
Alternatively you could take a PayPal approach, where the retailer directs me to visa.com and I input secret data there, authorizing payment back to the retailer without giving the retailer any secret information or trusting their certificate at all (other than to hide my purchasing/browsing history from snooping).
I know Visa et. al don't want to be in that business, but it's a sig
Re: (Score:3, Informative)
It depends on the country. Two friends of mine were mugged, and their wallets stolen. The one with a US credit card made a call, got the charges reversed, and a new card in the mail. No pain. My other friend from South America was on the hook for the thousands of USD that the crooks rang up, and couldn't even cancel it until the next morning.
Re:Don't do this at home (Score:5, Insightful)
From a security standpoint, the current system is pretty much the best you can hope for. People who presumably know what they are doing select your CA roots for you; a mistake there is equivalent to a buffer overflow that allows an attacker to install a key logger. The CAs, wishing to remain in business, have an incentive to do some level of checking on who they issue certificates to: if it became known that a CA was just signing any CSR, with no checks whatsoever, software makers would stop shipping their public key, and legitimate users would not pay for a signature. This, by the way, is the incentive for site owners to buy signatures from competent CAs: an incompetent CA is likely to not have their public key shipped with popular software, so their signatures are worthless.
It's not common for a CA public key to be removed from a software package, because of the ruckus it would create (potentially thousands of websites suddenly having untrusted certificates), but if a CA has truly incompetent practices, then yes, their public key will be removed. In general, software makers try to hold CAs to high standards to get their public key shipped with the software in the first place, so unless the CA itself allows its practices to worsen, it is unlikely that they would find themselves in that position.
Trusting a third party for security is tough, but if you are smart enough to be aware of that, then you should also be aware that you can personally add or remove CA public keys from any software that you use. If you feel that Comodo is untrustworthy, remove their public key, and every time you get a warning, report it to the owner of the website you were trying to visit.
Re: (Score:3, Insightful)
Clearly not the case, since Comodo is still trusted.
The browser maker (or someone else - the government security agency?) would need a team of people constantly testing the certificate issuers, trying every ruse possible to get bogus certificates issued. If any issuer fell for it then they would be struck off the list of trusted issuers (and the updated list would be pushed out as a security update). I don't see this happe
Re: (Score:2)
They really should use self signed certs for things like banks, and provide you a copy of the root cert in the branch so you can be certain the two match up... No third party involved.
Re: (Score:2)
Site owners (the ones paying the bills) have no incentive to demand that the CA be competent.
What do you mean they have no incentive for competent CA's? They have every incentive, since without competent CAs the security of the system will collapse. The site owner presumably cares about the security of the communication. If they didn't, why use SSL at all?
The real problem with the current system is that ALL the common CA's have to be trusted, not just some or one. A better system would involve only the
Re: (Score:2)
What do you mean they have no incentive for competent CA's? They have every incentive, since without competent CAs the security of the system will collapse. The site owner presumably cares about the security of the communication. If they didn't, why use SSL at all?
As a system, yes. Individually, no way. They want the cheapest CA = the one cutting the most corners that doesn't throw a nasty warning when visited by their customers. If people lose faith in the padlock, all the site owners are equally screwed no matter who they bought their cert from.
Re: (Score:2)
What do you mean they have no incentive for competent CA's?
The security of my site's users doesn't depend on the competence of whichever CA I choose, it depends on the competence of the least competent CA trusted by their browser. So there's no incentive for me to pay extra for a more competent CA, because their competence (or lack thereof) doesn't really affect anything.
A better system would involve only the CA who the site owner contracted with has to be trusted for that sites security.
I don't think that's possible, how do you know which CA that is?
Re: (Score:2)
So there's no incentive for me to pay extra for a more competent CA, because their competence (or lack thereof) doesn't really affect anything.
This is true. My point is really that shifting the burden of proof from one entity to the other doesn't really address the real problem. The problem isn't that one party has more interest in security than the other (sometimes true, sometimes not), it's that the weakest CA ruins it for everyone else.
I don't think that's possible, how do you know which CA that is?
Wit
Re: (Score:2)
My point is really that shifting the burden of proof from one entity to the other doesn't really address the real problem. The problem isn't that one party has more interest in security than the other (sometimes true, sometimes not), it's that the weakest CA ruins it for everyone else.
So make it so that you don't need multiple authorities, or can use multiple authorities with AND instead of OR for combining individual results. The way to do this is to make there be only one business relationship, end-user <-> verifier. The verifier can check that a site consistenly presents the same cert across time and network paths, and does not need a relationship with the site owner to do this. If a verifier proves to be incompetent, there's no collateral damage from dropping them. I can use mu
Re: (Score:2)
be only one business relationship, end-user verifier.
So how does the end-user know they're talking to the verifier, and not a MITM?
Re: (Score:2)
There are plenty of situations where the CA couldn't do much in the way of verification in the first place. e.g. they are separated by several thousand miles.
and end-users/browsers trust any CA to identify any site (they can't know which CA the site owner actually paid).
Which is another weakness in the scheme as it now stands.
Mapping to real-world identities is a separate issue (only provided by "extended validation"
OK, which CA must leave the trusted list? (Score:5, Interesting)
There's only one way the CA system can work: Responsibility and repercussions. If a certificate authority signs forged certificates, then it can no longer be trusted and must be removed from the list of trusted CAs. To trust an untrustworthy CA is a security bug and should trigger updates from all browser developers which remove the offending CA. Make the CAs work for their money.
Re: (Score:2)
The problem with that is IE.
Suppose Mozilla, Google, Apple, Gnome, The KDE Team, and Opera all remove untrustworthy CAs from their browsers.
Microsoft can leave the untrustworthy CAs in IE, and there are automatically a bunch of sites that are, for most users, IE only.
Re: (Score:2)
Maybe they could display a warning for that CA.
Or just go to the CA, tell them they need to do a better job or 20% of the web users will see a message saying : "this website has obtained a certificate from CA XXX which has very poor security checks".
Of course, such an update would make good headlines for the New York Times and others, so the CA could not take the risk of ignoring the threat. They would need to address the issue to avoid the bad press.
Re: (Score:3, Insightful)
Re: (Score:2)
Perhaps.
Or perhaps they need to get their CRL in order, which is the mechanism for dealing with certificates that have been revoked or compromised.
Re: (Score:2)
True. I guess at that point it's just bad luck for the genuine certificate holders that (probably) make up the majority of their customer base.
But yeah, they picked an untrustworthy provider.
Re: (Score:3, Insightful)
So, who will step forward and remove such authorities from the CA list? Mozilla? Opera? Microsoft even?
Something tells me that no one will and nothing will happen. The dust will settle, the offending CA will, at best, adjust their practices slightly but not effectively - and within 6 months we'll see more CAs pop up left and right using the same broken procedures.
There's just too much money involved in this game. Owning a CA authority is effectively a license to print money and the beancounters everywher
Re: (Score:2, Insightful)
As a user of Firefox, that's fine with me (the entire point of the certificate system is to provide security; in that context, features and convenience are lower priorities than actually providing security).
Basically, my neighbor's paper house is not a good reason for me to leave my doors unlocked.
Re: (Score:2)
That just moves the problem one rung up the ladder. How can we trust that the list of trusted CAs is valid and up to date? Who maintains this list? Me? You? The Scam Artists? A central trust agency? The Government?
Re: (Score:3, Informative)
Re: (Score:2)
Re:OK, which CA must leave the trusted list? (Score:5, Insightful)
Go ahead and accuse me of not being libertarian, but yes, I think making and enforcing standards for CAs is a good role for the government. I would never put my money in an unregulated bank, or send premiums to an unregulated insurer, or go to a back-alley doctor.
Re:OK, which CA must leave the trusted list? (Score:5, Insightful)
but yes, I think making and enforcing standards for CAs is a good role for the government.
Which "the government" are you talking about here? You might have noticed the internet is worldwide, and there's no single authority to control it. Browser makers are also free to put whatever CA's root certificates in their browsers that they wish (along with all anyone else who distributes software that uses an x509 certificate).
Re: (Score:2)
Re: (Score:3, Funny)
but yes, I think making and enforcing standards for CAs is a good role for the government.
Which "the government" are you talking about here? ...
I nominate Canada. They seem to be a respected world power. Everyone will be willing to listen to them.
Re:OK, which CA must leave the trusted list? (Score:4, Insightful)
I really don't think that the evidence supports your assertions. There is a difference between "are not" and "shouldn't be".
Re: (Score:2)
I am not suggesting that the US govt would regulate CA's around the globe. Only that it should be easy to tell with certainty if I am doing business with somebody regulated by the same government as myself (which the CA infrastructure, or something very similar, can accomplish). Why? Does not wanting to send my CC# to Russia or Nigeria imply I think t
Re:OK, which CA must leave the trusted list? (Score:5, Interesting)
Re: (Score:2)
What's wrong with the mechanism?
The problem (IMHO) is that the implementation is sucky and too many roots are put into browsers by default.
The actual mechanism works really really well, but you have to make sure you restrict your circle of trusted roots to orgs you *really* trust, for anything that's at all important.
Re: (Score:2)
I hope the article author understands that unless he's really lucky, he is in deep legal trouble already.
How? Was someone defrauded? Was their money lost? Was someone unjustly damaged? I just don't see the law broken here.
From what I can tell, what happened is the author found a way to get a signed SSL cert from a CA for mozilla.org. He doesn't mention that he tried to pass it to anyone, or even released the cert to anyone. The only party that might claim injury is the CA, and if they're smart they'll
Really now. (Score:5, Funny)
The example cited is "RESOLVED INVALID". The link to the "perfect attack" seems to be slashdotted. And at the time I started writing this comment, there have been no comments whatsoever.
Does this mean that Slashdotters have all swarmed the link trying to find out how to execute the perfect attack? Are we seeing a new trend here, with people actually reading TFAs?
Or is it that too many people have Greasemonkey scripts filtering out kdawson's posts?
Re:Really now. (Score:5, Funny)
Re:Really now. (Score:5, Insightful)
The example cited is "RESOLVED INVALID"
That's because the behaviour reported in the bug (the actual MITM attack) is *not* a problem with Firefox as suspected by the reporter: Firefox was behaving correctly by identifying the SSL certificates as invalid. It is however an interesting report of a MITM attack.
Re: (Score:2)
Being among the first to read all about the "perfect attack" is by definition "stuff that matters". The slashdot effect is proportional to the headline and proportional to the amount of damage that potentially can be done [sorry, no citations available]. Therefore, reading TFA is merely a function of headline and potential damage.
BTW, I decoded your .sig, will you please sue me now?
Re: (Score:2)
BTW, I decoded your .sig, will you please sue me now?
Absolutely. My lawyers will call your lawyers and arrange everything.
Re: (Score:2)
Re: (Score:2)
don't show some confusingly complicated dialog, just give some error message.
And that's exactly what firefox 3 does. You get a blank screen with a message that the SSL certificate is invalid and that the site cannot be trusted, and a tiny little link to open the dialog to add an exception if you really want to go to that site anyway.
Pisses everyone with self-signed certs off.
Re: (Score:2)
And is perfectly backwards, as far as I am concerned.
Browsers should display a warning dialog for *every* cert that is encountered for the first time, something along the lines of "This site wants your trust, please check the cert details carefully before accepting".
Being issued by VeriSign or Thawte doesn't make a cert any more trustworthy in my eyes.
They have issued forged certs for microsoft.com and such before and it will keep on happening. It can happen to my
Re: (Score:2)
Re: (Score:2)
Looks like DDOS beats all (Score:3, Funny)
Re: (Score:2)
That's called "slashdotting".
Re: (Score:2)
More like "/. subscribers seeing articles 30 minutes early" (but with comments disabled)...
np: Tocotronic - Gegen Den Strich (Pure Vernunft Darf Niemals Siegen)
SSL/TLS need more info (Score:2, Informative)
I never liked the notion of "trusted" certs. I have always built my own certs. While I can't read the article, I would say it is an obvious vulnerability in host naming.
SSL/TLS is mathematically secure. I mean, yes, it really is. You can trust that aspect of it. It breaks down in practice where secrets need to be kept secret or in areas where strict adherence to good practices are vital but not done.
Re: (Score:2)
Re: (Score:2)
So you tell your browser to only trust those certs you manually accepted?
Kind of a big hassle, don't you think? You really expect the average web user to go through that process?
How often do you visit completely new secure sites? Not that often unless you're a crazy shopaholic who likes to try out new online stores every day. He didn't say that the average user should do it though, just that he himself prefers that method. Me, I think I'll drop COMODO from my trusted certs for the moment..
Re: (Score:2)
So you tell your browser to only trust those certs you manually accepted?
Kind of a big hassle, don't you think? You really expect the average web user to go through that process?
Well, its more complicated than that. The mechanism is broken because the process by which you get a cert is the same process in which you use one.
In a "secure" environment, you install the cert. Then you use it.
That being said, it is rather irrelevant to the encryption scheme if it's mathematically secure, but vulnerable to a break
Re: (Score:2)
Re: (Score:2)
How is $15 per year too expensive for a small site or special project?
That's actually pretty cheap, I'd seen them for $250 and high per year. Still, I'd rather see a non-profit organization instead.
Re: (Score:2)
Re: (Score:2)
Like this one [cacert.org]?
Their root certificate needs to be installed first though.
Re: (Score:2)
That would introduce another point of failure, and be rather expensive. Giving people or browsers a way to at least check the cert's fingerprint would be cheaper and afaik just as effective.
Yes and no. Say it is mozilla.org. A single TRUSTED source for certs separate from the actual site makes it very difficult for a MITM to spoof.
Self signed certs suck, they just educate the user to simply accept whatever SSL warning their browser throws at them.
That's precisely my point, self-signed certs are far more sec
Re: (Score:2)
"That's precisely my point, self-signed certs are far more secure in theory, but there is no mechanism to use them securely."
This is a confusing use of terminology.
Strictly speaking, a self-signed certificate is one that has been used to sign itself. Using one of these for a server is not supported by all SSL implementations and is, IMHO, "a bad thing"(TM) to do simply from the angle of conventions.
However, if you mean that creating your own private CA certificate and using it to sign a server cert, then ge
Another reference (Score:4, Informative)
Sensationalist - reroute & self signed certs (Score:4, Interesting)
What's so perfect about the attack listed? It clearly shows up that the certificate is not trusted. With the new and improved, (and for me, irritating) screens of Firefox, where you are clearly warned, this should not be such a big problem.
What I don't get is that they do not try and locate the idiot trying to do this. Because that is one of the problems with these kind of man in the middle attacks - a single person that does actively goes after you can do some damage. This makes such attacks harder to perform, even if they are technically feasible.
Maybe they should make it even clearer that you should not use self signed certificates for banks and such, but this is far away from the IE bug that let leaf certificates (with some missing key usages) sign other certificates with any URL.
I've created one of those attacks on a corporate LAN (just for show, using a proxy) ages ago. Guess that made me a script kiddie :)
Re: (Score:2)
This is a very old, already solved IE bug, sorry if that's confused anyone.
Re:Sensationalist - reroute & self signed cert (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)
From the link (firefox bug report):
ALL web pages I have to sign in to (or sometimes just visit) say this and I
have to manually add the certificate by:
1. Clicking on the blue wording at the bottom
2. clicking on the add exception button
3. click get certificate
4. confirm the certificate
Once I do this, it does not pop back up for that specific page, but it is quite
annoying! I am using the firefox 3.1, but it did this with 3.0 and before. I am
using wireless internet (over an unsecured wireless network - basicall
Re: (Score:2)
Seems that the "perfect" attack would be a combination of a bad CA and this attack. Of course, that you can reroute traffic from access points is not new. So what *is* actually new? Maybe the notion that it is too easy to get certificates from some CA's, but the article is not directly about that It's a bit of a shame that I still cannot read all the articles, maybe there is more information in there. But the Firefox bug report does not show a perfect attack, so why is it referred to?
Oh well, disabled the c
Re: (Score:2)
It's referred to as an example that MitM attacks against SSL sites do actually occur in real life, and it's not just a theoretical vulnerability that nobody actually tries to exploit.
This probably isn't news to many people, but it might be, and so is probably worth pointing out.
The fact that it does actually happen combined with the fact that Comodo apparently issue certificates without any validation checking whatsoever is what prompts the "Perfect MITM attacks" headline. i.e. it's trying to make it clear
Use your OWN certs... or use CACert.org's (Score:3, Interesting)
CAcert certificates are pretty nice because they are FREE!!! even if they need to become a little more responsible in the near future. The cool thing about "Free" is the value is in innovation, because it's the only way to survive being free in the first place. Maybe tie CAcerts to an OpenID??? Honestly, you get what you pay for... friends... hookers... etc.
Who trusts the trusters? (Score:4, Insightful)
If a CA doesn't properly validate who you are and cuts you a cert for anyone else, its a problem with CA, not the underlying codebase(s).
So, what's the big deal (Score:3, Interesting)
The dude found out that you can have self-signed certificates or certificates signed with whatever CA you want. Here's another MITM angle: you can set up your own root CA (http://www.onlamp.com/pub/a/onlamp/2003/02/06/linuxhacks.html) and you can even become an intermediary (Secondary) CA authority by paying Verisign, Equifax or Thawte. Heck, if you pay enough money to Microsoft, Mozilla or Opera and adhere to certain standards they will include your servers in their set of root certificates.
SSL is not supposed to be preventing MITM nor is it supposed to be for identifying purposes. We have other technologies for that like PGP but the internet relies on anonymity so you're never 100% sure that you're going to talk to the correct persons. Even with PGP, your initial communications will have to be trusted (eg. you personally hand over or get a key) or any subsequent communications will be compromised. SSL doesn't even go that far because every communication is viewed as an initial communication. If the certificate is re-signed or changed to another CA the next day, your browser will not complain as long as that CA is in it's trusted root certificates.
I personally think it's the government's fault that PGP didn't break through as a good authentication scheme because of their export limitations on firearms and it took a while before it was circumvented by opening up the standard. It's the browsers fault and the CA's as well (with VeriSign the biggest) by asserting that SSL certificates can be used to authenticate an entity rather than a communications. Lately there came to be the SSL-extensions but it's a) too little too late b) bolted on c) not a solution since that information can also be falsified using the exact same methods as described in the article since all it takes is a 'rogue' SSL signer that doesn't do it's job (or somebody impersonating the entity)
Big trouble at PositiveSSL. (Score:5, Informative)
The article is confusing, and the author declines to name the certificate issuer that's the problem. But the screenshot [startcom.org] gives the details. It's PositiveSSL [positivessl.com]. He really did get PositiveSSL to issue him a Comodo-authorized cert in the name of "www.mozilla.com". Try this link [192.116.242.23] and look at the certificate details.
It looks like certificates with this issuer information need to be rejected:
I loaded all current Comodo certificate revocation lists, and this bogus certificate has not been revoked.
Some Comodo CA root certificate needs to be removed from the approved list.
Addtrust, and Comodo. (Score:5, Informative)
Looking at this cert further, it's a very wierd certificate. "Issuer" of ""www.mozilla.com" has "O=Comodo CA Limited". That's descended from "Positive SSL CA", for which "Issuer" has "O = The USERTRUST Network". That's descended from "UTN-USERFirst-Hardware", for which Issuer has "O = AddTrust AB". That's descended from "AddTrust External CA Root". Why is a Comodo cert being issued under AddTrust? Comodo is a root CA itself, with its own root certs in major browsers. Something is not right here.
So who's AddTrust [addtrust.com]? Their web site says "Under Reconstruction". This does not look good. Checking the Internet Archive, we find "JOIN THE ADDTRUST FAMILY Gain an edge over your competitors by providing co-branded PKI services" [archive.org]
AddTrust went beyond using resellers. They apparently allowed subordinate CAs to issue certs in AddTrust's name: AddTrust's rapid Trust Service Provider (Licensee) start-up package allows you to deliver cutting-edge public key infrastructure (PKI) services cost-effectively and in a way that best complements your business model. Literally within months you can start selling pre-packaged outsourced PKI services allowing your customers ...
AddTrust's globally recognized PKI brand is designed for co-branding with companies recognized for high-quality IT services and products. ... Rather than relying on external certification authorities, you can easily provide high-end certificates yourself by becoming an AddTrust-licensed Trust Service Provider. This allows you to decide how much of the underlying secure infrastructure you want to run and invest in yourself.
The relationship between Comodo and AddTrust is mentioned in this email. [markmail.org] Robin Aldin of Comodo wrote: There is no ongoing relationship with AddTrust AB, Sweden. I'm not even sure if AddTrust AB still exists as a company. I think AddTrust may exist now only as a brand of ScandTrust AB. Sweden - although Comodo does have the right to continue using the root CA certificates which we purchased from them and which bear the AddTrust name.
So the party ultimately responsible for this certificate is out of business?
Efforts underway to resolve problem. (Score:4, Informative)
This subject is being discussed by Firefox developers, Comodo CA people, the person who reported the problem, and somebody named "Patricia" from CertStar, the issuer, here. [markmail.org]
Robert Alden of Comodo says they "have suspended Certstar's reseller activities until our investigation has been completed." [markmail.org] The CertStar site [certstar.com] now says "Due to technical issues we are unable to process orders at this time. We are working hard to resolve the issue and apologize for any convenience caused. Please check back later."
The Mozilla team is discussing revoking some root CA keys. [mozilla.org]
Re: (Score:2, Informative)
Should have tried paypal.com, but I guess he didn't want too much legal trouble.
Re: (Score:2)
With a certificate for mozilla.org and a knowledge of security procedures couldn't he release his own patch to install back doors into a very significant number of browsers and thereby have access to the username and password for millions of paypal, online shopping and banking accounts?
Re: (Score:2)
Re: (Score:2)
I was thinking more that he sends out a fake update message and pretends to be mozilla.org, nothing to do with the real repositories necessary? Probably would require DNS cache poisoning and such too though, I'm no expert on security.
Re: (Score:2)
But if the author doesn't own the domain mozilla.org, the user is still going to get a warning in their browser about the domain mismatch between the cert and the domain visited. How is this any more dangerous than a regular self-signed cert? In this case the evildoer still doesn't control the domain, even though he or she has a renegade cert for it.
Re: (Score:3, Informative)