Perfect MITM Attacks With No-Check SSL Certs

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."

Comments

Don't do this at home

[moro_666]

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

[Anonymous Coward]

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

[Timothy Brownawell]

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:Don't do this at home

[cp.tar]

Oh, dear. So who certifies the certifiers?

Re:Don't do this at home

[somersault]

(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:Don't do this at home

[Timothy Brownawell]

(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:Don't do this at home

[jonbryce]

The suppliers of web browsers - Microsoft, Mozilla, Opera, Apple (Safari), KDE (Konqueror), Google (Chrome).

Re:Don't do this at home

[jonbryce]

Most people just look for the padlock. Do they even know how to inspect a certificate?

Re:Don't do this at home

[Anonymous Coward]

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:Don't do this at home

[betterunixthanunix]

The problem with the system you described is that it relies on end users to understand what is happening. Most FF or IE users have no understanding of what a certificate even is, how it works, or how a MITM attack works. If you told end users that they would pay for identification services, every scam artist on earth would be setting up their own CA and charging users for the root signing certificate, which would then be used for MITM attacks. Worse, the idea that end users could try and verify self-signed certificates is preposterous also, and again, scam artists would be all over it.

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:Don't do this at home

[Bert64]

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:Don't do this at home

[Anonymous Coward]

I have a much bigger concern. Who certifies those who certify the certifiers?

Re:Don't do this at home

[iammani]

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

[Nursie]

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:Don't do this at home

[Vellmont]

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 CA who the site owner contracted with has to be trusted for that sites security.

Re:Don't do this at home

[Nursie]

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:Don't do this at home

[Anonymous Coward]

>>Oh, dear. So who certifies the certifiers?
>The suppliers of web browsers - Microsoft, Mozilla, Opera, Apple (Safari), KDE (Konqueror), Google (Chrome).

Duh.. you do.

Re:Don't do this at home

[TheLink]

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

http://ask.slashdot.org/comments.pl?sid=534356&cid=23199022

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

[Ed Avis]

if a CA has truly incompetent practices, then yes, their public key will be removed.

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 happening.

Re:Don't do this at home

[Timothy Brownawell]

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:Don't do this at home

[Kjella]

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:Don't do this at home

[Vellmont]

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 try to keep this as quite as possible. (Because they're the giant incompetent boobs here, and a lawsuit would only draw attention to that fact).

Re:Don't do this at home

[Timothy Brownawell]

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:Don't do this at home

[Anonymous Coward]

https://mastercard.example.com/
https://visa.example.com/

maybe? I dunno. Maybe trust paths could be established from intermediate CAs to your card issuer - just click the padlock icon and check there is a path back to your preferred root depending on what task you are doing.

Re:Don't do this at home

[Anonymous Coward]

And who certifies me?

Re:Don't do this at home

[gomiam]

...your local psychiatrist?

Re:Don't do this at home

[ScreamingCactus]

Simple. We give the MITM attackers the power to certify the certifiers. That way we have a system of checks and balances.

Re:Don't do this at home

[gbjbaanb]

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:Don't do this at home

[Vellmont]

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?

With the current x509 based certs, it's not. The whole thing was based on all the CAs being "trusted".

I guess I'm starting with an idea I know to be secure (or at least doesn't have a single point of failure), and then find a way to implement that. I don't know if it's possible to implement such a system or not.

Re:Don't do this at home

[mpe]

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

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:Don't do this at home

[mpe]

The current mechanism is that the site owner pays a particular CA to identify them,

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" 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).

It would make sense to link this with existing DNS or business registration.

Re:Don't do this at home

[Timothy Brownawell]

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 multiple verifiers without site owners needing to care or even knowing.

Re:Don't do this at home

[Actually, I do RTFA]

As it is, I don't think anyone would be liable (except yourself) to pick up the cost of shenanigans

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

[Vellmont]

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:Don't do this at home

[Anonymous Coward]

And, at least in the United States the American Psychiatry Association certifies your local psychiatrist.

But who certifies the American Psychiatry Association?

Re:Don't do this at home

[Anonymous Coward]

Racist much?

Re:Don't do this at home

[johny42]

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 is as if you said that a shopping center should not pay for the security guards, but the customers that visit this shopping center should.

The web site provides services to its users (usually not for free - even if only for the revenue from advertising), and security is just one of these services. End users do end up paying for that (either by directly paying the site owners, or by clicking on the advertisements), but there is absolutely no reason for end users to want to pay for security to a 3rd party.

If some CA doesn't do a good enough job at verifying what it signs, then this CA is (or should be?) removed from the lists included in browsers, thus making all the certificates it issues worthless and forcing web site owners to purchase services from a different CA - which is exactly how it should be.

If there is a problem with this system, it is not a design problem, it's a problem with implementation. If users are ignoring the warnings, then they should be more persistent and explanatory (like the Firefox warnings are now, though I'm not so sure about the "explanatory" part). If the CAs sign keys without verifying their owners, then they should be punished. If there is no authority that regulates the CAs (checking whether their verification processes are thorough enough, etc.), then maybe there should.

Re:Don't do this at home

[online-shopper]

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

[techess]

My credit card company does something similar. They give virtual numbers. You generate the number via an app or the web. They are usually one use, but you can set it for intervals also. You can even decide how much can be spent on it. If the site isn't legit or they let the number get stolen no biggy. Generally I have it expire in a month and be only good for the exact amount I need.

I know Citibank and Bank of America provide this service, but not on every card they offer. I guess it would be more like a one time pad than a Root CA, but effective.

Generally though if their are shenanigans on your card I believe the credit card company tries to stick the vendor that approved the purchase. Which is why business tend to check ID's and handwriting more during the high theft season of Christmas.

 

Re:Don't do this at home

[Rich0]

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 new file is provided. The domain is randomly checked over that period of three weeks to ensure that all the provided files are being served. After this, the certificate is issued. Renewals would follow a similar process (but with a reminder sent out well in advance so that the checks could take place well before expiry).

It is unlikely that somebody could exercise this level of control for an extended period of time simply via DNS spoofing or advertising bad routes. However, the issued certificate would only include the domain, and would not certify owner details (name/address/phone/etc). To obtain a cert with these credentials I think that a more intensive check would be prudent.

The current system basically amounts to a tax on SSL, and little more. If you pay some money to some auditor you can get into the SSL certificate business.

Also - SSL should allow certificate-less operation. Sure, that is vulnerable to MITM, but at least it is better than unencrypted http. Perhaps we should have more than two tiers of security (completely insecure, and "completely" secure).

Re:Don't do this at home

[Timothy Brownawell]

This is as if you said that a shopping center should not pay for the security guards, but the customers that visit this shopping center should.

The web site provides services to its users (usually not for free - even if only for the revenue from advertising), and security is just one of these services.

The site cannot provide (this kind of) security, it can only be implemented on the user's system. Because of this, it should be the responsibility of the user (or realistically, the browser maker) rather than the site owner.

If there is a problem with this system, it is not a design problem, it's a problem with implementation. If users are ignoring the warnings, then they should be more persistent and explanatory (like the Firefox warnings are now, though I'm not so sure about the "explanatory" part). If the CAs sign keys without verifying their owners, then they should be punished. If there is no authority that regulates the CAs (checking whether their verification processes are thorough enough, etc.), then maybe there should.

The "need" for punishment (which would have collateral damage) and regulation is how you should know that the system is broken. The built-in incentives do not align properly to make the system work on its own, so external forces must be imposed. That makes it a bad design.

Re:Don't do this at home

[QuoteMstr]

I hope the article author understands that unless he's really lucky, he is in deep legal trouble already.

What law, exactly, has he violated? We are a society of laws. Not every "bad" action is automatically illegal because some powerful person doesn't like it. That's what makes us a free country and not a despotic nightmare land.

Re:Don't do this at home

[Actually, I do RTFA]

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.

Exactly. That's why everyone uses Linux. And why no one has to worry about net neutrality. And why Ma Bell never was an issue. And why the credit rating bureaus never let their customers down; after all three of them compete!

Re:Don't do this at home

[blhack]

Whoever has the largest gun.

Or bank account, they're really the same thing.

Re:Don't do this at home

[kabloom]

Nobody. They don't have an HTTPS site.

Re:Don't do this at home

[something_wicked_thi]

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.

Well, you just need to warn if the cert signer changed. However, that doesn't help if the first time you access the page, you get the fake cert. But neither does your proposal.

Re:Don't do this at home

[Zeinfeld]

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.

Kind of hard to make that scale. And how does the chosen third party authenticate the site? Is the site going to co-operate with umpteen different checks by different providers? Seems something of a hassle to me.

When the CA business started the general complaint was that the authentication checks required were too onerous. So a group of CAs came into the market offering ever weaker authentication criteria until the point was reached when some certificates recognized by the browser were worthless. Which is precisely why we developed the Extended Validation program.

EV is the result of a committee process and may be fairly criticized as been somewhat over-engineered. But that was inevitable, an auditable and effective means of validating accountability will inevitably be more cumbersome than one that is merely effective. But it does work.

One side effect of EV is that every browser now supports certificate revocation checking and increasingly revocation checks are the default. So even if there is a failure in a Domain Validated cert, it is more likely to be shut down.

Re:Don't do this at home

[cbiltcliffe]

Why, SSL certificates, of course!

Re:Don't do this at home

[cbiltcliffe]

What law, exactly, has he violated?

Fraud. He claimed to be Mozilla. He is not.

Should laws make exceptions for cases like this? Of course they should. However, for the most part, they don't.

It's not that I think he should be prosecuted for breaking the law, because what he did was the right thing to do from a moral standpoint. But he undoubtedly will be prosecuted, by some political moron with an axe to grind, and no understanding of security whatsoever.

Re:Don't do this at home

[Winged]

Why do you think Microsoft stopped trusting external CAs for its updates in Vista? It runs its own in-house CA at this point, and that's the only CA that can issue certificates that can sign updates for Windows.

Re:Don't do this at home

[Winged]

SSL (now TLS) does allow certificate-less operation, and has since SSLv2. In that case, the key agreement is done via ephemeral Diffie-Hellman (DH without any static/attested key).

Re:Don't do this at home

[Winged]

I wish you'd put your two cents in on the dev-tech-crypto@mozilla.org mailing list.

Right now, they're avoiding removing the trust bits because that would essentially mean 3 months of not being able to authenticate Comodo certificates. They claim that it's because they don't want to inconvenience the end-users, but I tend to think that they're doing it because they've been paid not to.

Re:Don't do this at home

[Winged]

Mozilla and MS have made it as difficult as possible to inspect the certificate. Safari (and Apple's Keychain Manager) make it easier, but it's still a lot of information to try to digest.

Re:Don't do this at home

[starfishsystems]

That's why self-signed certs aren't really more risky than CA signed certs in practice.

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:Don't do this at home

[drspliff]

The guy who found this out (Eddy Nigg) is the founder of another CA who participates in the Mozilla root program aparently. So far from being just some random hacker, it's in his interest not to have vendors like CertStar issuing certificates without validation because it hurts every CA's reputation.

Last time I got a certificate from Comodo we had to go through company identity checks, and it's enraging that some people could be issuing certificates without any form of checks, especially for such a large organisation as Mozilla.

Re:Don't do this at home

[ToasterMonkey]

Site owners (the ones paying the bills) have no incentive to demand that the CA be competent.

I completely disagree. SSL is all about trust, and the CA you trust for your site's cert does matter. There's only so much a CA can practically do to establish your (corporate) identity, but that's what you trust them to do every time they are asked to issue a certificate in your name. It's not rocket science, this is a basic level of trust that everyone needs. We expect, and trust ANYONE who handles our personal information to properly, consistently verify our identity.

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.

What?? Let me get this straight... you want to pay for a whitelist(s) of the Internet? OK, while you're shopping, I have a nice bridge you might be interested in.

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).

1. The whole point of a CA is for them to verify who you (site owner) are. People are already involved to look at paperwork. To change a POC in our existing system even requires you to fax paperwork to them on company letterhead. If they didn't do that already, then what is the point of requiring end users to trust them? If they fail to do this, then fire the CA, delist them, stop trusting them. Are CA's perfect, no. Could we use some better standards, or maybe regulation to ensure they enforce certain security best practices, possibly. We got EV certificates without regulation.. a small UI improvement (somewhat standardized at least), better checks, legal ID, physical presence (they have a better method than the phone book reverse lookup check I guess?), URL ownership, etc, BUT only for a new, more expensive, OPTIONAL class of certificates. Are Internet users clamoring for more regulation, hell to the fsck no. It will eventually be required to properly tie up loose ends in a trust based system I think though.
2. I will repeat again what you said, so it has more time to sink in.
"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)."
Everyone will use a search engine for the dumbest things you can possibly imagine at some point in their life.
Getting to the right URL is already assumed when dealing with MITM attacks.
Going to the wrong URL is NOT something a CA is in a position to prevent. - EV helps, but if normal certs are still trusted then bad URLs with normal certs still are too, so WTF is the point? Well.. besides CAs wanting more money.

If browser vendors adopted an EV type UI for all certificate "tiers", then our current system could help against fraudulent URLs with valid SSL certs.
The problem then is we'd then have no way of distinguishing the extra checks CAs are doing for EV without over complicating the UI. WHY do we need to distinguish those extra checks you ask? Because CAs want mo' money, and part of that is driving end user demand for expensive certificates.

The MITM is just a UI issue with our current certificate system.
The problems we have with the UI are because CAs use inconsistent identity verification and we stupidly tied the UI to that. We SHOULD be able to use self signed c

Re:Don't do this at home

[profplump]

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. :)

Parts of the problem here is the reliance on third-party trust when no such abstracted trust is necessary.

Is there some reason my bank couldn't just give me the fingerprint of their CA cert and a link to download it when I open an account? Or provide a copy of it on a CD/flash drive? I don't understand why my bank needs a third-party CA in the first place, other than current OSes make it more complicated than necessary to install new CAs.

Certainly there are people who need trusted third-party introducers -- I've never been to a physical Amazon.com store, so there's no good way to get me a certificate or fingerprint. But even there I think some manual verification would be a good plan -- warn users the first time they visit and on any certificate change. I'm glad to have someone claim to authenticate the certificate, as opposed to being issued against an unknown CA, but there's no reason my browser should simply accept all those "known" CAs as 100% trusted with my manual input.

Re:Don't do this at home

[profplump]

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 significantly more secure approach -- I can trust the CA issued by Visa for purchases I make with Visa and I can avoid giving my secret data to anyone that doesn't already have a copy.

Re:Don't do this at home

[Anonymous Coward]

I call BS to the kneejerk assumption the author is in danger of legal trouble. Who is going to pursuit this matter?

If the reseller or comodo even think it they are up shits creek big time with Mozilla. Comodo has nothing to gain and a lot to loose by pursuing the matter. The reseller is in no position to do squat.

There are too many people in position of power over FF and CRLs who are not clueless amateurs involved in this already -- none of them accepting of this sort of nonsensical behavior.

Re:Don't do this at home

[online-shopper]

Feel free to copy me there. I can't see any other way to effectively do it than to force the companies to do it themselves.

Unfortunately, they may decide to pull a stunt where neither rats the other out.

Re:Don't do this at home

[node 3]

Clearly not the case, since Comodo is still trusted.

Yet. It's not like such a thing would happen instantly. I highly suspect that there will be browser updates from MS, Apple and Mozilla that rectify this shortly.

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 happening.

It's happening right now. The first step is identification. We've just identified what appears to be an untrustworthy CA. Next step is to remove them from the list. We'll see how that goes. If it doesn't happen, then there's definitely something wrong with the system. Presently, however, it's too early to tell.

Re:Don't do this at home

[Kadin2048]

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:Don't do this at home

[zonky]

So all you'd need is some sort of sql injection or exploit?

Re:Don't do this at home

[zonky]

The problem is people will blame the browser, not the certificate issuers when 'their browser stops working with XYZ.corp's https webite'

Re:Don't do this at home

[Anonymous Coward]

Take a look at the list of certificate authorities in your browser.

Re:Don't do this at home

[bunratty]

In Firefox, I click the site icon when I'm on an https site, click More Information, then click View Certificate to view the certificate. Could it be any less difficult to inspect the certificate?

Re:Don't do this at home

[bunratty]

And, of course, that's why the certificate has been revoked already. Because they don't care. You can read the comments near the bottom of this page for the details.

Seriously, if you think that a certificate authority is not performing due diligence in verifying the identity of the individuals who it's issuing certificate to, make some noise about it, and the problem will be quickly resolved.

Re:Don't do this at home

[Kadin2048]

This is quite true. What you have is a pretty classic collective action problem, both at the level of Certificate Authorities, and at the level of e-business companies (banks, retailers, etc.).

If a CA acts badly, by issuing certificates sloppily, then eventually the public will lose faith in the CA system and move to something else. All CAs will probably perish. Thus it would seem to be in the best interest of each CA to be careful about certificate issuance, and carefully verify all applicants. In the long run this may be true, but in the short run a 'lazy' (or just plain corrupt) CA will profit handsomely by being the easiest Authority to get a certificate from.

Similarly, if you're running a e-business website, you just want to get the cheapest browser-approved certificate you can. All that matters to you, specifically, is that the padlock icon comes on in the user's browser. While the overall security of e-commerce may affect you in the long run, in the short run you just need that icon so that users will trust you as much as they trust your competitor who has one.

The combination of these two incentives is what we have right now: there are a ton of low-cost CAs, who apparently will apparently spit out a certificate with just about anything you want on it, for a few bucks. Although their existence hurts the electronic-commerce ecosystem as a whole, they make out like bandits at everyone else's expense. Or, to put it a little differently, they profit individually while the loss or harm is distributed broadly.

The solution is to eliminate the perverse incentive, by making it less profitable to act in an antisocial (in the sense of 'being harmful to the community at large') way. This would be accomplished if browsers were much more aggressive about pulling CAs from the trusted roots if they were issuing certificates sloppily. Browser developers -- or if they're not interested, some third party that produced a list of "trusted" CAs for them -- should be engaged in continuous, highly adversarial audits of CAs, essentially testing them to ensure they're following issuance guidelines. If they're not, they need to be immediately dropped from browser roots via security updates. Short of that, I can't see much way of saving the CA system.

Re:Don't do this at home

[tkw954]

Who polices the police? The police police police the police. Who polices the police police? The police police police police the police police. Wash rinse repeat.

Re:Don't do this at home

[u38cg]

The problem is the economic incentives. Do the roots have an economic incentive to verify all the parties it certifies? No, they have an incentive to sell as many certificates as possible. Browsers should not include certificates and users should pay for a subscription to a certificate authority *they* choose to trust. That would put the incentive boot on the other foot.

Re:Don't do this at home

[HeronBlademaster]

You jest, but in reality the root CAs certify themselves. That's why we have this whole trust model in the first place. If we don't trust the root CAs, who can we trust? Of course, if a root CA is misbehaving, then we need to make them untrusted...

Re:Don't do this at home

[HeronBlademaster]

Since when were Visa and friends interested in security? It's cheaper for them to just refund fraudulent charges than it is to try and stop the charges from occurring in the first place (which of course means they did it wrong in the first place, but that's beside the point).

Re:Don't do this at home

[u38cg]

I was pretty shocked too. Some of the people on that list I definitely do not trust. I suppose it's inevitable; getting on to the list of trusted roots is a license to print money. The answer is pretty simple: browsers should stop shipping with certs preinstalled, and we the end-users should be paying for a subscription to a root certificate we trust.

Re:Don't do this at home

[HeronBlademaster]

Do you really think Joe Sixpack is smart enough to know how to do that, even if he is given step-by-step instructions? You appear to be overestimating the intelligence of the average person.

Re:Don't do this at home

[jonbryce]

It's not difficult if you know what you are looking for.

Re:Don't do this at home

[HeronBlademaster]

Agreed - the article author didn't do anything with his fraudulently obtained certificate, so he did nothing more than point out flaws in the system.

It's similar to the journalist who recently successfully transferred ownership of the Empire State Building to himself using forged documents. Sure, using forged documents was illegal, but he was able to obtain legal ownership of the building until he returned it. The journalist did nothing more than point out flaws in the system.

Re:Don't do this at home

[Tumbleweed]

Oh, dear. So who certifies the certifiers?

The Watchmen.

Re:Don't do this at home

[phayes]

It doen't appear to be possible to remove cert autorities in firefox 3.0.5 ("Tools=>Options" then Advanced tab & click on "View Certificates" then choose the "Authorities" tab). While you can select certificate authorities and click on "Delete" to erase them, this does not stick. Exit & then reenter the certificate manager and the "deleted" certificate authority will be back.

Re:Don't do this at home

[Anonymous Coward]

so you're securely talking to someone, you have no idea whom, but you're confident that you're talking to someone, who might be blabbing to everyone else, or transparently changing the content that you get from the content you really should get.

Re:Don't do this at home

[Bert64]

They will have no choice but to learn if the bank makes them...

Re:Don't do this at home

[Onymous Coward]

I just edited the certs. Removed all their authorizations. Haven't tried removing them completely.

I did this for all USERTRUST, AddTrust, and Comodo certs.

Re:Don't do this at home

[Onymous Coward]

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.

Any bad certs reduce the value of having a cert. Buying a shoddy cert from a crap company encourages the existence of bad companies and bad certs, thereby reducing the value of your cert.

Re:Don't do this at home

[xenocide2]

The browsers do. I think it was Mozilla who told CAcert they needed to up the level of inspection, and so on.

Re:Don't do this at home

[Anonymous Coward]

Oh, dear. So who certifies the certifiers?

Oh, you think you're tricky, eh? Well I have news for YOU...

It's certifiers ALL THE WAY DOWN!

Re:Don't do this at home

[Anonymous Coward]

Visa already does something like this. The implementation is sloppy and looks like a phishing attempt, though: the transaction is redirected to some host under arcot.com, which then proceeds to ask you to input financial and personal information.

Re:Don't do this at home

[Timothy Brownawell]

SSL is all about trust, and the CA you trust for your site's cert does matter. There's only so much a CA can practically do to establish your (corporate) identity, but that's what you trust them to do every time they are asked to issue a certificate in your name. It's not rocket science, this is a basic level of trust that everyone needs. We expect, and trust ANYONE who handles our personal information to properly, consistently verify our identity.

The reason it doesn't matter, is that there's nothing to prevent some other CA from also issuing certs for your site. Even when you have absolutely no contact with or trust in that other CA.

What?? Let me get this straight... you want to pay for a whitelist(s) of the Internet?

CAs are already a whitelist mechanism, the only difference is who pays. I think it should be whoever benefits from the list being accurate, so the list maintainers have an incentive to do their job properly.

The whole point of a CA is for them to verify who you (site owner) are.

And yet somehow, nobody cares. If people did care, the UI would reflect that (like it does for EV certs).

Re:Don't do this at home

[anthonys_junk]

You are dead right. Perhaps it's time to start educating them?

Re:Don't do this at home

[phayes]

Have you verified that they are gone? I removed comodo immediately then discovered that it was still there when I went in to clean out the others that I do not recognize.

I'm on FF 3.0.5 on windows. You?

Re:Don't do this at home

[the_womble]

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

If they did the SSH style thing, there would there would be little reason to use real CAs. Self signed would be good enough for most purposes.

Where higher security is really needed, confirmation of the cert could be sent on physical media, or some check could be made in first login.

Re:Don't do this at home

[TheLink]

It's each person's responsibility.

Whether they know it or not.

Re:Don't do this at home

[TheLink]

How does that prove they care about security? All that shows is they care about wiping the egg off their face.

If they really cared, they'd have caught it before it happened.

For example: they could get the CA's to deposit $$$$$$ every year, and then have 3rd parties try to subvert the CAs. If the 3rd party succeeds, the CA loses the deposit and the 3rd party gets some of the $$$$$. If at the end of the year everything is ok, the CAs get 75% of their deposit back. Then list the audit results and track record of CAs on their website. If a CA keeps failing audits, the CA and the bosses of the CA are banned (basically if the same crappy people are involved in starting another CA, that CA will also be banned).

Another thing, just look at the Mozilla CA cert management UI.

If you try to delete a cert, it doesn't delete it. It disables its use for stuff (which is OK I guess) BUT you can't tell from the main UI page.

The next time Mozilla updates the certs, you have to select each cert and go to "edit", one by one to see what changed.

I've tried suggesting security improvements to the Mozilla/Netscape bunch before, but it was a big waste of time.

Re:Don't do this at home

[TheLink]

Edit the CA cert you "deleted"- you should see all the checkboxes deselected.

Then test to see that you get a warning/error when visiting the relevant sites.

The UI needs a bit of improvement :).

Re:Don't do this at home

[atraintocry]

Serious answer: AFAIK practicing medicine without a license is illegal in most places. I'm sure it's the same with psychiatry.

So who validates the law?

Sylvester Stallone.

Re:Don't do this at home

[atraintocry]

...which they won't, at least not in the US, unless the government gets involved. BoA has the balls to call SiteKey two-factor authentication. I guess their logic is that your account number is one factor and the password is another, or something like that.

Re:Don't do this at home

[Onymous Coward]

I JUST EDITED THE CERTS. I changed what they could be used for (from various allowances to nothing at all.) I did not remove them.

FF 3 series on Windows, FF 2 series on NetBSD.

I edited the cert trusts for each user, too. Don't forget that it's per-profile.

Re:Don't do this at home

[Burz]

Do you really think Joe Sixpack is smart enough to know how to do that, even if he is given step-by-step instructions?

I do.

But the real problem is that keys and certs are very crucial entities in computing, and today's desktop systems do not represent them properly to the user. A key or a cert sitting on a desktop or a flash drive just looks like a text file or nothing at all.

There needs to be a class of descriptive icons that people will come to associate with keys (which will encrypt) and certs (which will identify and/or encrypt) - along with proper associations to utilities that will handle them. As with storage devices, text documents and such there are many examples of general ways to represent objects and actions that are standard across platforms. Key/certs don't have this and is the primary reason why average users don't bother with them: Users literally have nothing recognizable to grab onto.

Beyond that, the idea of these not-like-physical-keys security objects have a private and a public part really won't be hard to grasp for most people (esp. since most users at this point have grown up with computers).

In short, proper and robust GUI representation (with animation) is required, and long overdue as today's systems are easily up to the task. For instance, have a standard "control" (class with display component) that any app can embed into its GUI, and that shows something being done to the data during encryption, decryption, signing and verification would be ideal.

Re:Don't do this at home

[Rich0]

And this is different from regular http how?

Right now browsers don't complain at all when you submit all kinds of personal information to who-knows-who when SSL is not in use. I'm suggesting that at the very least we ought to be able to encrypt these connections.

Basically I see several layers of security:
1. Well-confirmed certificate issuance that protects an SSL connection.
2. Encryption, but without a well-confirmed certificate.
3. No encryption at all.

I'd suggest that these are ordered in accordance with the security provided. However, many browsers complain about #2, but not about #3 (which is LESS secure). My proposal is that browsers treat #2 as less secure than #1, but more secure than #3. What's wrong with that?

Re:Don't do this at home

[Rich0]

Well, if a site is vulnerable to exploits that give an attacker almost complete control over the content of the site, then the ability of an attacker to get an SSL certificate for that site isn't much of an additional concern. They can already have the site in question serving up viruses or whatever to all their customers. They can also have the site in question redirect their login screen to the attacker's own servers (which might be on a different domain that the attacker would have no difficulty obtaining an SSL cert for in the first place).

My argument is that certificates should be linked to whoever controls a domain (for a lengthy period of time). That person is the de-facto domain owner in any case. If your domain is completely open to hacking then forged SSL certs are the least of your troubles.

Re:Don't do this at home

[BZ]

> Mozilla and friends aren't going to do the SSH style thing

There's a small problem with doing that in the PKI world: PKI certs, unlike SSH keys, have expiration dates. It's pretty common to have certs that are only valid for a year, renewed yearly. The problem is that "renewal" is just the issuing of a different cert for the same entity.

It's as if the SSH key of every server changed every year. Users would just learn to click through the "something changed" warning and move right on with their stuff.

Re:Don't do this at home

[BZ]

How is "encryption if you don't know who you're talking to" better than "no encryption at all" for the typical web browser, exactly?

Heck, I can't think of any cases where I'd think it's more secure, even outside web browsing. Care to mention one?

Re:Don't do this at home

[Rich0]

Sure - when your threat model is somebody with the ability to intercept network traffic, but not modify it. In that threat model, an encrypted but unauthenticated transmission is secure. An unencrypted transmission is not secure.

And if an encrypted but unauthenticated and a non-encrypted connection are equally insecure, then why does firefox complain about the former and not the latter?

Don't get me wrong - I see the value in PKI and all that. However, the current SSL certificate issuance system is flawed - it is more a measure of willingness to pay cash and not authenticity. Granted, just charging money is going to defeat a number of attacks (you can no longer create millions or billions of attack domains with valid SSL certs). However, the status quo isn't exactly a bed of roses.

Encrypted communications should be the norm on the internet - nothing should be sent in the clear. Granted, I can make some allowance for devices that don't have sufficient CPU to perform AES, but over time that should dwindle. Authenticated communications may not be needed 100% of the time, but if somebody comes up with a good way to make it work I'd be happy to see every TCP packet encrypted and signed.

Re:Don't do this at home

[BZ]

> when your threat model is somebody with the ability to intercept network traffic, but not
> modify it

Unauthenticated implies that you have no assurance that the other end is who you mean to be talking to. Your threat model is assuming that DNS is not lying to you and that the IP address maps to the right entity; in that case you're actually assuming (out of band) authentication.

> And if an encrypted but unauthenticated and a non-encrypted connection are equally
> insecure, then why does firefox complain about the former and not the latter?

Because the former shows security indicators that users have been trained to look for: "https" in the url bar and a lock icon. It's been argued that the browser should just not show those and treat these connections as unencrypted, but the counterargument is that in the case of a MITM against a site the user expects to be encrypted it's better to alert the user than downgrade to unencrypted.

> However, the status quo isn't exactly a bed of roses.

Oh, absolutely agreed.

> Granted, I can make some allowance for devices that don't have sufficient CPU to
> perform AES

Given that there are hardware AES implementations, and that the cost is coming down, I'm not even sure that we should make those allowances a few years out. I agree that having everything encrypted by default would be quite nice.

Re:Don't do this at home

[ArsenneLupin]

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 your customers would be right. Who tells that you wouldn't use your CA to sign a fake bank certificate and use it to spy on your customers' transaction? So from the customer's point of view, it does indeed weaken their browsers.

Re:Don't do this at home

[starfishsystems]

Valid point. That hadn't occurred to me, but of course you're right.

I see dead links...

[Nabeel_co]

All the links are down... One of the down sides of seeing a story when it is new I guess.

Looks interesting though! Might get more interesting when their web server stops spitting out flames...

Really now.

[cp.tar]

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.

[ghmh]

Apparently the perfect attack is actually 'Slashdot in the Middle'

Re:Really now.

[daveewart]

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:Really now.

[BSAtHome]

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:Really now.

[bunratty]

The reason for the "RESOLVED INVALID" is that the bug reporter thought they were reporting a bug in Firefox causing all those annoying SSL popups. What was actually happening was that the user was being attacked with a man-in-the-middle attack. Therefore, this shows how Firefox protects you from the attack. As annoying as those dialogs may be, they are necessary to warn the user of a potential attack.

Re:Really now.

[cp.tar]

BTW, I decoded your .sig, will you please sue me now?

Absolutely. My lawyers will call your lawyers and arrange everything.

Re:Really now.

[neumayr]

Sure, because users are so prone to pay any attention to annoying dialogs.
Not that I have a better idea, except maybe to do away with user interaction concerning SSL all together - block invalid certs by default, don't show some confusingly complicated dialog, just give some error message.
Radical, yes, but I don't see any other way.

Re:Really now.

[Qzukk]

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:Really now.

[Anonymous Coward]

It really shouldn't. If they're remotely competent (okay, I know that's asking a lot), they'll have set up their own mini CA with something like TinyCA and have installed that CA's cert in the browser's CA list. If you're using truly self-signed certs rather than certs issued by your own mini CA, you're retarded.

Re:Really now.

[neumayr]

I'm not familiar with TinyCA, but if you still need to add the CA you created to the browsers list manually, how does that help?
You still need to tell your users what to do, and it's probably as much work as just accepting you selfsigned cert.

Re:Really now.

[bunratty]

Because you need to add only one CA instead of many self-signed certs?

Re:Really now.

[Kent Recal]

Pisses everyone with self-signed certs off.

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 or your online banking site just later today, who knows?

What I want from my browser is to warn me when a site that I previously added to my trust-list suddenly *changes* its cert. None of the major browsers do that as far as I know. As long as the new cert is signed by one of the so called "authorities" it'll just happily let me send my data to whatever phishing site without the smallest warning dialog...

Re:Really now.

[bunratty]

The problem with your approach is that users get so many warning dialogs they get used to clicking through quickly, and therefore miss the important warnings for when a cert changes. You need to save warning messages for truly important events, so the user does not become desensitized to them.

Re:Really now.

[neumayr]

Somebody who's making his own CA will most likely not have that many certs, I'd say most of the time it's just one.

Re:Really now.

[Gollum]

Yes, the example cited is "RESOLVED INVALID", because the bug reporter thought there was a problem in FF, which really turned out to be a real live MITM attack, which is exactly what the link was provided as.

Re:Really now.

[Anonymous Coward]

Greasemonkey? Talk about insanity. You can exclude stories from kdawson on your prefs page.

Re:Really now.

[Wodin]

If you read the bug and the comments you will see that the submitter was complaining about having to click through the "yes I really want to add this dodgy cert" process for every HTTPS site she visited. She thought this was just Firefox 3.0 being stupid. What was actually happening was that she was the victim of a MITM attack and the certs were actually bad. i.e. Firefox was working as it should and was doing everything it could to warn her of this possible MITM attack.

Since there was a MITM attack and no actual Firefox bug it was closed as RESOLVED INVALID.

I can't comment on the lack of comments at the time you posted, though :)

Looks like DDOS beats all

[00_NOP]

It had "0" comments when I started and I still could not RTFA

Re:Looks like DDOS beats all

[cp.tar]

That's called "slashdotting".

Re:Looks like DDOS beats all

[Briareos]

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

[mlwmohawk]

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:SSL/TLS need more info

[neumayr]

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?

That being said, it is rather irrelevant to the encryption scheme if it's mathematically secure, but vulnerable to a breakdown of the way it's organized. It's broken either way.

Re:SSL/TLS need more info

[rhsanborn]

SSL/TLS is secure for encrypting data between two known, trusted entities. It's using these as a form of identification that is an issue. Even that may not be so much an issue as the policies that cert issuers use to identify domain holders isn't very thorough and is a pretty poor foundation on which to base a global internet trust system.

Re:SSL/TLS need more info

[somersault]

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:SSL/TLS need more info

[mlwmohawk]

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 breakdown of the way it's organized. It's broken either way.

This is true. There needs to be a mechanism by which "certificates" are downloaded separate and individually and securely.

I would like to see a non-profit organization that allows people and companies to register downloadable certs for free or at a minimal cost.

Each site can create its own certs and register them with, say, mozilla.org, and browsers go there for certs rather than download them rather than from the potentially spoofed site.

Right now self signed certs are problematic because there is no mechanism for trusting their download, and the companies in charge of managing certs are too expensive or too restrictive for small sites or special projects.

Re:SSL/TLS need more info

[neumayr]

Yes well, encryption loses much of its appeal if it doesn't also correctly authenticate the communicating entities.
Those policies cert issuers use or, as it seems, sometimes ignore, are a part of the encryption scheme's organization. Which is broken, breaking the scheme.

Re:SSL/TLS need more info

[bunratty]

A few months ago, I got a certificate signed by a CA that is trusted by essentially all browsers. The cost was $15 per year. They even bothered to check that I had access to the admin's account on the server I was requesting the cert for. How is $15 per year too expensive for a small site or special project?

Re:SSL/TLS need more info

[neumayr]

I would like to see a non-profit organization that allows people and companies to register downloadable certs for free or at a minimal cost.

Each site can create its own certs and register them with, say, mozilla.org, and browsers go there for certs rather than download them rather than from the potentially spoofed site.

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.

Right now self signed certs are problematic because there is no mechanism for trusting their download, and the companies in charge of managing certs are too expensive or too restrictive for small sites or special projects.

In the case of special projects, I think they ought to have secure communication channels they could use to distribute their certs.
I don't know about small sites though. If they don't have a limited audience and therefore no way of distributing their certs securely, but absolutely must encrypt/authenticate their traffic, I guess there's no real way short of actually paying for their cert.
Self signed certs suck, they just educate the user to simply accept whatever SSL warning their browser throws at them.

Re:SSL/TLS need more info

[mlwmohawk]

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:SSL/TLS need more info

[mlwmohawk]

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 secure in theory, but there is no mechanism to use them securely.

In thinking about it, it should be the job of ICANN or the top level domain registrar to host certs for your domain. That way, there is a TRUSTED mechanism for obtaining self-signed certs.

Re:SSL/TLS need more info

[bunratty]

Well, there's CAcert, but they are not listed as a trusted CA in any browser. StartSSL, which is a commercial company, issues certificates for free and they are trusted by Mozilla browsers currently. But as far as I know, if you want a cert that's trusted by default in all modern browsers, you'll need to pay a few bucks.

Re:SSL/TLS need more info

[Nursie]

"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 getting the user to import the CA cert public key rather than the self-signed cert itself, that's fine, and just as secure.

Re:SSL/TLS need more info

[cjb658]

Like this one?

Their root certificate needs to be installed first though.

Re:SSL/TLS need more info

[neumayr]

That's precisely my point, self-signed certs are far more secure in theory, but there is no mechanism to use them securely.

Why would they be more secure? Because there's no third party involved? That would change if there is a keyserver for SSL certs.

Assuming SSL is mathematically secure, what you're asking for seems to be equivalent to a single, trusted, non-profit CA.
I'm all for it.

Re:SSL/TLS need more info

[Anonymous Coward]

Your post is the definition of redundant.

Re:SSL/TLS need more info

[Anonymous Coward]

SSL/TLS is secure for encrypting data between two known, trusted entities.

True.

But it is much more useful for securely encrypting data with an UNKNOWN entity provided that a responsible entity that you trust (the CA) has issued a signed certificate to the unknown entity.

The problem here is that the "responsible" entity isn't being responsible and doing any diligence before issuing a signed certificate to the unknown entity.

Re:SSL/TLS need more info

[webmarin]

A few months ago, I got a certificate signed by a CA that is trusted by essentially all browsers. The cost was $15 per year. They even bothered to check that I had access to the admin's account on the server I was requesting the cert for. How is $15 per year too expensive for a small site or special project?

I got one also recently for $15/yr. Seems they raised the price to $79 for the basic 128 cert. That may keep kiddies away... Also my boss...

Re:SSL/TLS need more info

[raju1kabir]

Each site can create its own certs and register them with, say, mozilla.org, and browsers go there for certs rather than download them rather than from the potentially spoofed site.

Cool, so I manage to compromise mozilla.org and suddenly I can spoof every bank web site on the planet. Wouldn't want to be mozilla.org's security guy.

Re:SSL/TLS need more info

[thePowerOfGrayskull]

Not necessarily. I've never assumed that anyone I've a secure connection to is who they are supposed to be. I do, however, assume that nobody with a packet sniffer in the right place is going to know what I'm talking about when the communication is encrypted.

Encryption and identification are two independent concerns; attempting to force them into one model like we've done is what leads people to think that the combined service can be trusted for more than it really can.

Re:SSL/TLS need more info

[Onymous Coward]

Doesn't the user then subsequently trust every other signature your CA makes?

What if they only wanted to trust the one server?

Re:SSL/TLS need more info

[Nursie]

What happens when the private key on that server gets compromised and you need to revoke it (with CRL) and issue a new one? Or the server certificate expires? You have to use a secure, preferably offline, method of getting another public key out there again.

The idea here is trust. You import my CA details because you trust that I'm going to play fair. In the example I think we're talking about, we aren't talking huge companies doing thousands or even millions, just an individual (or single company) setting up a CA for their own servers. Doing it on an individual server basis makes the system just too brittle.

For instance, if my bank issued their own certificates, I'd be happier. They could mail me out their public key and I could set up a browser profile for important stuff like money and identity with only my bank's cert in it, maybe my credit card's etc. Then I *know* that I'm connecting to the exact right party. Not only that, but I don't actually care which one of their load-balancing web servers I actually connect to, just that I'm using genuine HSBC.

Re:SSL/TLS need more info

[Onymous Coward]

What happens when the private key on that server gets compromised and you need to revoke it (with CRL) and issue a new one?

Dunno. Can't you also issue a revocation using the cert itself?

You have to use a secure, preferably offline, method of getting another public key out there again.

Yes, that's right. There are certain cases where this is perfectly fine.

It's good you bring up usage scenarios, because all this talk about the effectiveness of methods is entirely dependent on what we're trying to do.

If I meet some random guy who wants to share some secret information via his website, I should have no trouble accepting a self-signed cert (As long as I am more interested in the secret information than his authorship of it), but I should refuse to accept his CA. Generalized, the idea is that there exists situations where I can trust a person to share information but not to authenticate every website I visit. Analogously, if you give me an account on your system and an SSH server key fingerprint it shouldn't equate to you being able to tell me whether other folks' SSH server keys are correct.

I don't have a lot of familiarity with SSL certs in particular, but this all seems pretty straightforward to me. Am I missing something? Perhaps everyone is assuming specific usage scenarios. That must account for over half the misunderstandings in discussions about SSL.

Re:SSL/TLS need more info

[Nursie]

Yup, your scenario is also good. I guess I hadn't considered that sort of thing. It's not an aspect/use-case I've come across in my professional dealings with SSL. I'm sure a CRL location could easily be built in to a self-signed server certificate, as it is with a CA cert, but then you have the problem of trusted comms with the CRL server too. Not that you don't anyway, but if you have layers then perhaps compromise of your root cert is less likely, allowing you to report certificates as broken from servers with non-broken certificates, so there's still a chain of trust? Tricky...

I think the main usage scenario people discuss is the internet one -

"I want some way of having secure, authenticated communications with someone I've never met before."

This is a minefield, because you end up with these nebulous authorities who authorise all comers and do a varying amount of checking (some do little to none). Then, because this is a complex subject, we want to keep it easy and transparent so people with no understanding of what's happening can use it. And so we get to where we are now, with browsers needing to have lots of authorities preconfigured, or else clueless users will complain that their internet is broken, or that this firefox/opera/safari thing doesn't work.

I don't really know how to solve that, but IMHO (I guess I'm repeating myself here) it would be good for banks and other important things to distribute a private CA cert and for browsers to have some sort of lockdown mode that could be switched on for talking to your financial institution only.

nothing new

[Anonymous Coward]

Getting your own certs isn't hard. My test firm has both SSL Certs and Code Signing Certs.

Re:nothing new

[neumayr]

The author's point was that he could get a signed cert the says mozilla.org.
Should have tried paypal.com, but I guess he didn't want too much legal trouble.

Re:nothing new

[somersault]

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:nothing new

[bunratty]

I suppose it would be possible to get the username and password of someone who has write access to the source code repository. On the other hand, it's open source, so many would notice the backdoors being put into the source code. If any builds were created that had the backdoors, they would be quickly deleted.

Re:nothing new

[somersault]

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:nothing new

[sricetx]

The author's point was that he could get a signed cert the says mozilla.org.

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:nothing new

[QuoteMstr]

Yes, but SSL certificates also protect against DNS spoofing and other man-in-the-middle attacks. "Control of the domain" is a far fuzzier concept than you think.

Re:nothing new

[rwhiffen]

Why bother mucking with the real source tree? Just make a clone on your mozilla.org-impostor site with an update that has all the appropriate back doors in it.

Just deliver a DNS spoof/change (like dns cache poison, etc) via another exploit, get the browser to self-update (and clean up your previous exploit tracks) and then sit back and wait to spring your trap. The only code change you need to insert at first is to get future updates from the impostor site.

Later on you can 'update' the browser to proxy all $MONEY web traffic through you and your proxy farm. You could even add a new trusted CA to your code base to make it all the more convincing and to cover tracks from the 'imposter-mozilla.org' cert in case it's discovered and revoked.

Re:nothing new

[thePowerOfGrayskull]

This just requires access to someone's inadequately-secured wireless network, which is increasingly easy to get.

OK, which CA must leave the trusted list?

[Anonymous Coward]

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:OK, which CA must leave the trusted list?

[characterZer0]

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:OK, which CA must leave the trusted list?

[Anonymous Coward]

If it doesn't happen too often, they could flag the CA as untrustworthy and warn users that, even though the certificate checks out ok, it was signed by a CA which is known not to perform proper identity checks, so it might be forged. Make it one of those FYI bars at the top of the browser window, so that the user doesn't have to do anything to continue. If the situation gets worse, unlist the CA. Then it's Microsoft's problem if it doesn't follow suit and IE doesn't protect the users from fraud.

Re:OK, which CA must leave the trusted list?

[glop]

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:OK, which CA must leave the trusted list?

[camperdave]

If a certificate authority signs forged certificates, then it can no longer be trusted and must be removed from the list of trusted CAs.

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:OK, which CA must leave the trusted list?

[bunratty]

Telling them to do a better job now does no good if they've been issuing valid certificates to bad guys already. If they were not doing the proper validation of individuals who were requesting certificates, we need to consider all certificates issued by that CA to be untrusted.

Re:OK, which CA must leave the trusted list?

[bunratty]

Microsoft maintains the list for IE. Mozilla maintains the list for Firefox. And so on. Use a browser from a company you can trust, or you may just regret it one day.

Re:OK, which CA must leave the trusted list?

[timeOday]

Plus, decertifying a CA would nuke thousands of websites that did nothing wrong; even for this lax CA I'm sure most of the companies registered there are legit.

Re:OK, which CA must leave the trusted list?

[timeOday]

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?

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?

[Nursie]

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:OK, which CA must leave the trusted list?

[Kent Recal]

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 everywhere will just keep on repeating their mistakes over and over in order to "streamline" the process for "optimized revenues". I would even go as far to suspect that this *might* be a PR stunt to drive more people into the horridly expensive "green addressbar" certs (and wait for it, we'll see more colors in the future, for even more security!).

The only technically correct way out of this would be to abandon this broken and tainted system altogether.
But it's not gonna happen, VeriSign and friends will make sure of that with all their weight.

Re:OK, which CA must leave the trusted list?

[maxume]

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:OK, which CA must leave the trusted list?

[giorgiofr]

I would never put my money in an unregulated bank, or send premiums to an unregulated insurer, or go to a back-alley doctor.

But you have no problems forcibly preventing me from doing so, should I wish to. That's not even close to not being a libertarian. It's being a dictator.

Re:OK, which CA must leave the trusted list?

[Vellmont]

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:OK, which CA must leave the trusted list?

[moose_hp]

No, it's their fault to do bussiness with an untrustworthy CA, they should be the first ones asking for more security in the registration process or move their certificates to another CA who do things right.

Considering that they used the same registration method, they should had noticed that the process did not protect them from forgery.

Re:OK, which CA must leave the trusted list?

[Anonymous Coward]

Who's goverment? China's? Mexican? French? Australian? Where the server's are? Where the bussines central is?

Silly americans and their megalomaniatic view of the world, (mod me flamebait) you guys are not the center of the world, nor the policemen of the nations.

Re:OK, which CA must leave the trusted list?

[Anonymous Coward]

Revocation lists are (supposed to be) used for certificates where the private key has fallen into the wrong hands. Although you could argue that technically this is the case here, the underlying problem is different and justifies a different solution: The CA issues certificates without checking the identity of the recipient. The sole purpose of a CA is to see if the identity of the recipient matches the certificate and to certify the relationship with a cryptographic signature. The trust relationship between the user and the SSL site operator depends on the CA's responsible behavior and is empirically justified by looking at the policies and procedures for acquiring a certificate from the CA and the actual track record of the CA. This evaluation is performed by the browser maker and codified by putting the CA on the list of trusted CAs if it satisfies the requirements put forth by the browser maker. The user indirectly trusts the CA by trusting the browser maker to make the right decision (just as he trusts the browser maker to make the right decision regarding other security issues.) A CA which does not check identities does not deserve our trust and can not regain our trust by revoking individual certificates.

Re:OK, which CA must leave the trusted list?

[timeOday]

Actually I don't think that's such a huge problem. For me, anyways, my bank web access and (almost?) all my online purchases are still from here in the US. Sending my credit card number overseas is not something I do very casually, regardless of anything to do with ssl.

Re:OK, which CA must leave the trusted list?

[Nursie]

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:OK, which CA must leave the trusted list?

[Wonko the Sane]

Silly americans and their megalomaniatic view of the world, (mod me flamebait) you guys are not the center of the world, nor the policemen of the nations.

I really don't think that the evidence supports your assertions. There is a difference between "are not" and "shouldn't be".

Re:OK, which CA must leave the trusted list?

[timeOday]

I guess this is my fault for mentioning libertariansm in the first place. For the record, I think it's a great idea in an imaginary perfect world where everybody has complete access to all information, dishonesty is abolished, natural resources are infinite (so each of us can breathe our own air, etc), and everybody starts life on equal footing (access to education, proclivity to illness, etc). Which is to say, it's exactly as practical as Communism and every other idealization that never seems to get fully proven or disproven because it can never actually exist.

Re:OK, which CA must leave the trusted list?

[Anonymous Coward]

You get what you pay for.

If they bought a certificate from one of the top 3 certificate vendors ( VeriSign, Thawte or Geotrust, all of them VeriSign companies ) then they would pay a lot more for it, but they would also have a lot more trust in it.

VeriSign had (as of 2007) 57.6% market share for SSL certs. Comodo, the 2nd largest had under 9%. VeriSign has publically stated that they are divesting all business except for DNS, SSL and identity protection. ie, they are staking a large part of their ( $billion+/year ) business on their ability to provide SSL. Their reseller processes include checks that the applicant owns the corresponding domain registration.

Even if you hate VeriSign because of the 3 weeks of SiteFinder that you had to endure in 2003, it's hard to disagree that the market leader in SSL is the best choice. They've got too much to lose.

You pay your money and you make your choice. The difference between $100 and $600 a year for most companies is negligible given what they are staking on this trust mechanism.

This really hurts those who can't justify $600 on a cert from a reliable vendor, such as those turning a hobby into a small business.

Disclaimer - I'm an ex-VeriSign employee. I didn't work in DNS or SSL though.

Re:OK, which CA must leave the trusted list?

[timeOday]

Silly americans and their megalomaniatic view of the world, (mod me flamebait) you guys are not the center of the world, nor the policemen of the nations.

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 they are all crooks? Of course not. But I am wary of dealing with people when I would have no recourse if they rip me off. That is, at a very basic level, what regulation is good for.

Re:OK, which CA must leave the trusted list?

[Anonymous Coward]

Libertarians do have an answer to how pollution is dealt with (breathe our own air, etc).

Not that I know what it is exactly.

Re:OK, which CA must leave the trusted list?

[Panaflex]

Nobody forced you to choose Lehman Brothers!!! Man... some people? You have a choice!

Re:OK, which CA must leave the trusted list?

[QuoteMstr]

The issue here is a conflict of interest. I've been screaming that something like this would happen, but I was treated like Cassandra. Look - it's in the CA's financial interest to sell as many certificates as possible, and competitive pressure will invariable reduce the verification process to joke unless there is a balancing force.

I sincerely hope that the Mozilla project and everyone else removes the Comodo CA from the trusted list and pushed out an urgent security update. Doing anything else would set a terrible precedent and only encourage this kind of behavior.

That said, it's not necessarily in the browser's best interest to remove the CA. (It's the right thing to do, but that's beside the point.) Nobody wants to "break the web", and browser creators are concerned that if major sites fail to work, users won't blame the sites: they'll blame the browsers. Therefore, corporate management types may very well decide to not remove flawed CAs.

However, if there were a third party that verified certificate authorities, and all the major browsers consulted this organization instead of their internal CA lists, sites would fail across all major browsers simultaneously, giving no competitive advantage to ones with lax security.

I cannot see how such an organization could make a profit, however. Money changing hands for verification would only lead to exactly the same corrupting effect we see in the primary CA market. (Or Moody's, for that matter.) The rating organization ought to be a government agency that simply publishes a list, signed with a well-known public key.

There could be more than one of these organizations, perhaps run by several independent national bodies, non-profits, and so on. A web browser would check all the CA verifiers and if a majority of them reported that a CA is problematic, would disable that CA. That way, no one body can extort CAs by threatening to revoke their accreditation, but collective, bad CAs will be rooted out.
 

Re:OK, which CA must leave the trusted list?

[Anonymous Coward]

In this case it wouldn't help no matter who you brought your cert from. Since the malicious party will buy it from the not so secure party and the browser will still accept the certificate without raising a warning provided that not so secure companies root certificate is in it's trusted list.

I can't see any way to make it 100% bullet proof. the only improvement which I can see is for the browsers to keep a log of a sites certificate in it's history and to raise a warning if it's found to suddenly have changed even if the new certificate is from a trusted CA.

Re:OK, which CA must leave the trusted list?

[Anonymous Coward]

You missed the point, which is what will happen if an untrustworthy CA is removed from the trusted CA lists inside major browsers. If you bought your certificate from the same untrustworthy CA, then your users will from that point on see the same warning dialog that you could have gotten for free with a self-signed certificate. If however you bought your certificate from a CA which has not lost the trust of the browser makers, then the delisting of the offending CA will not affect you or your users. As usual with the "you get what you pay for" mantra, the assumption is that a more expensive CA is likely more diligent than a cheap CA, so the likelihood of being caught up in the delisting of "your" CA is supposedly inversely related to the price of the certificate.

Re:OK, which CA must leave the trusted list?

[Sloppy]

Banks are a great example where no CA is needed at all. Banks should be self-signed, because you actually meet your bank. You don't need an introducer; they could print their signature at the bottom of their mailed statements, have it on a sign in the lobby, etc.

Re:OK, which CA must leave the trusted list?

[Wannabe Code Monkey]

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.

Well, the system seems to be working... at least now. This is what I get when I try to navigate to the fake mozilla.com:

Secure Connection Failed

An error occurred during a connection to www.mozilla.com.

Peer's Certificate has been revoked.

(Error code: sec_error_revoked_certificate)

The page you are trying to view can not be shown because the authenticity of the received data could not be verified.

* Please contact the web site owners to inform them of this problem.

Re:OK, which CA must leave the trusted list?

[dubbreak]

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?

[Anonymous Coward]

Plus, decertifying a CA would nuke thousands of websites that did nothing wrong; even for this lax CA I'm sure most of the companies registered there are legit.

Certs aren't about who is legit and who isn't. What you just said isn't merely wrong; it doesn't even make sense. Nobody is saying those other companies aren't legit; they're saying we don't know who they are. And it's correct to say that; if the CA doesn't check identities, then we really don't know who they are. And their sites wouldn't be "nuked," the cert would merely be untrusted. Is that as bad? Perhaps. But it means something very different.

Re:OK, which CA must leave the trusted list?

[professorguy]

"So, who will step forward and remove such authorities from the CA list?"

.

I will. I just removed COMODO from my trusted CA list in my browser.

Now we have the situation that is analogous to firewall rules per site. I don't trust you, so I won't allow connections to you. But what if the infraction has long since been cleaned up? What mechanism is there for a site to contact every network admin on earth to beg for forgiveness?

Now that thousands of people like me no longer allow their browser to trust COMODO, how can they ever erase the stain? Good question....

Re:OK, which CA must leave the trusted list?

[Sloppy]

That said, it's not necessarily in the browser's best interest to remove the CA. (It's the right thing to do, but that's beside the point.) Nobody wants to "break the web", and browser creators are concerned that if major sites fail to work, users won't blame the sites: they'll blame the browsers. Therefore, corporate management types may very well decide to not remove flawed CAs.

That's why we need multiple signatures on an identity. If Comodo's trust suddenly drops to zero, then as long as an identity is also signed by someone else that is still trusted, nothing breaks. (And then the people who used Comodo start looking around for a new backup certifier.)

Re:OK, which CA must leave the trusted list?

[Svartalf]

I'd have to concur there. Each and every one of the CA certs associated with Comodo in Firefox 3 is being purged from my trusted lists on all my machines as I type this.

What they just did is bogus- this stuff only works when you follow the steps to the letter and everyone else does the same. I hope there's a CA cert revocation coming down the pike for Comodo and all it's affiliated CA's (There's about 5 of them in my list on my machine here...). Once you screw up like this, you honestly can't trust the current certs from them and it's difficult to trust them in the future.

Re:OK, which CA must leave the trusted list?

[Svartalf]

All of the Comodo related entries (there's about 5 or so of them in Firefox 3...).

Re:OK, which CA must leave the trusted list?

[Anonymous Coward]

That was the least they could do. It would be foolish not to revoke a blatantly forged certificate if the CA hears about it, especially when its existence has been widely published. It doesn't solve the issue though. In the meantime a forged certificate could have been used to install malicious software on thousands of computers or to intercept and modify online banking transactions worth millions of dollars, without anyone noticing. That the CA was able to revoke this certificate does not mean that they could even detect if any of their other certificates was issued to a third party. We trust CAs to check the identity of the certificate recipients. If it is so damn easy to get a certificate for a third party domain, then that trust is undeserved. (BTW, CRLs don't work in all browsers.)

Re:OK, which CA must leave the trusted list?

[Anonymous Coward]

With banks you need something like TLS-SRP to use common knowledge of credentials to establish the trust relationship with your bank.

Re:OK, which CA must leave the trusted list?

[Ironica]

Who's goverment? China's? Mexican? French? Australian? Where the server's are? Where the bussines central is?

As globalized as our world is, I very rarely conduct online transactions with non-US companies. A handful of times I've ordered from Canada, I think, and once or twice from the UK (from Amazon.co.uk to get books that aren't out yet here).

Globalization is something that's happened at a level higher than the individual consumer. It means that the goods I order from US vendors may have been made in some remote part of the world, but that's not where I'm buying them from.

So, it makes sense for companies doing business in the US to get their certificates from US CAs, who are regulated by the US government. Replace "US" with "country of your choice," with more flexibility for the EU where they share a common currency across national boundaries. Some countries will be unregulated, and their certificates will be cheap and nearly worthless internationally (but may be the best you can get if you're doing business in that country).

Some government will probably come up with a really brilliant regulation system that helps ensure a great product for the consumer, and then the top-end companies will all want their certs from those CAs. "They've got a Swiss certificate" or somesuch will become a hallmark of impeccable online business dealing. Competition will still exist, but between nations more than businesses.

It can work, it does work in other fields. Not sure what's so hard about the concept.

Re:OK, which CA must leave the trusted list?

[starfishsystems]

Jane Jacobs points out that the roles of government (guardians) and industry (traders) are difficult if not impossible to merge because they are based on different ethical premises. It's therefore not a great idea to put traders in charge of the public interest. Think of Verisign for some recent examples of how badly things can go wrong when you put the fox in charge of the henhouse.

As national governments are already responsible for identifying and defending their citizens and territories, for making and enforcing laws, for licensing, and for collecting taxes from identified individuals and corporations, it isn't such a farfetched idea to have governments function as certificate authorities for both individual and corporate requestors. They already have all of the requisite information and controls in place.

Moreover, national governments are responsible for administering their respective top level domains in the DNS. Here is a good example of how identity in the global Internet is already being managed by multiple authorities, in the form of national governments.

Re:OK, which CA must leave the trusted list?

[Lost Race]

Libertarianism is in essence a real-world pragmatic compromise solution for people who would prefer an ideal perfect imaginary world of peaceful anarchism. The typical Libertarian mantra is, "Utopia is not an option." The whole idea is to maximize individual liberty in a highly imperfect world full of jerks who won't cooperate. Libertarians hate being (mis)characterized as starry-eyed dreamers out of touch with the "real world" -- the "real world" is exactly what they are talking about.

I say this as a former Libertarian. Nobody seems to be interested in pragmatic compromise solutions, so I've given up and reverted to pure idealism, which is in practice just as effective (i.e. not at all). The vast majority are only concerned with sustaining a highly unsustainable status quo.

Re:OK, which CA must leave the trusted list?

[Anonymous Coward]

Are you sure? The test page is delivered with a certificate that is issued by the PositiveSSL CA, which in turn uses a certificate issued by the "UTN-USERFirst-Hardware" CA. That is the CA which is listed in the certificate store in Seamonkey.

Re:OK, which CA must leave the trusted list?

[timeOday]

The typical Libertarian mantra is, "Utopia is not an option." The whole idea is to maximize individual liberty in a highly imperfect world full of jerks who won't cooperate.

The annoying part is when they refuse to recognize that most everybody in Western democracies shares that goal. The REAL question is what to do when various rights of various people conflict - which is almost all the time. If our actions affected only ourselves, there would be no motive to control each other. But that's not reality.

Re:OK, which CA must leave the trusted list?

[HeronBlademaster]

Why do you assume Microsoft wouldn't fix it? I've seen root certificate updates in my Windows Update list on various occasions, so they do actually make changes and updates to the list.

Re:OK, which CA must leave the trusted list?

[HeronBlademaster]

Additionally, the sites with certificates from the revoked CA will still work - the browser will just say "I don't trust this CA, do you want to continue?"

So what we want to happen is what will happen - users will be warned that the site's certificate was not signed by a trusted CA, but the site will still work if the user wants to continue anyway. What exactly is the problem, timeOday?

Re:OK, which CA must leave the trusted list?

[HeronBlademaster]

I like your idea, but I think there are too many people scared of giving the government control over one more thing, so it won't ever happen :(

Re:OK, which CA must leave the trusted list?

[HeronBlademaster]

Like I've said elsewhere, sites won't fail to work - users will simply be informed that the certificate is not trusted, but that they can continue if they wish - the same as what happens right now when the remote site uses any self-signed certificate.

Let's drop this nonsense about "breaking the web", ok?

Re:OK, which CA must leave the trusted list?

[QuoteMstr]

From the point of view of the average used, they absofuckinglutely will break. And we sure are hell shouldn't be training users to bypass certificate warnings. That road leads to absolute disaster: what's the difference between a MITM attack and a self-signed certificate from the point of view of the user?

No. Comodo's trust needs to be revoked, and it needs to be revoked now, web breakage be damned, or a horrible precedent will be set.

Re:OK, which CA must leave the trusted list?

[HeronBlademaster]

Oh, I agree that Comodo's trust needs to be revoked, I was just clarifying that the web won't actually break, since sites using old Comodo certificates will still work, and they'll still be encrypted. The only difference will be that browsers will require user input before proceeding.

Re:OK, which CA must leave the trusted list?

[Lost Race]

Libertarianism is "not reality" only in that it's not the actual party in power. It's as realistic as any other political paradigm. My point is that libertarian political philosophers and Libertarian Party leaders really have worked through the "real world" details, and they make at least as much sense as Republicans or Socialists. My beef with the Party and the philosophy is not that they haven't absolutely perfected every response to every conceivable deficiency (which seems to be your beef) but that they haven't had any effect on the political landscape. If we're not going to be effective anyway, we may as well not bother with compromise.

Your critique of libertarianism, like most such critiques, is aimed much more squarely at anarchism than libertarianism; libertarianism is rather moderate in how it prioritizes individual liberty with respect to other requirements of civilized society. A more appropriate critique might involve the libertarian assumption that people are generally capable of rationally acting in their own best interests.

Re:OK, which CA must leave the trusted list?

[Anonymous Coward]

If they did that and ended up with major compatibility differences between Mozilla et al and MSIE, MSFT would immediately launch TV ads proclaiming that MSIE "works with more websites than any other browser!" "Now with flavor crystals!" "NEW! Less toxic fumes than ever!" "Experience the web the way it was made to be, with IE."

and so on.

That's how it would be played. Never mind that everybody else was making it safer. The average home user doesn't CARE about that. They just want it to work, and well, IE would work in more places like a slut in a trailer park chasing a $20 bill. Sold.

We're doomed. We just are.

Re:OK, which CA must leave the trusted list?

[Kent Recal]

Well, yes, you and a few hundred other nerds will do that.
Probably close to the number of certs that comodo issues per hour...

Nobody, not comodo nor anyone else will ever notice a "stain".
Mass effects just don't happen on such events. There have been much worse security bugs in Internet Explorer and Windows - people don't care.

As for "erasing the stain": There is no way. A revokation is final, they can beg for forgiveness all day.
And there is a damn good reason for revokes to work that way: Their CA is tainted now and can never be trusted again.

They could have issued certs for amazon.com, yoursite.com, citibank.com etc. and every browser in the world will trust these certs until they expire or until the certificate chain is broken by revokation. Do you know what the maximum expiry for these flawed comodo certs was? Me neither. Could be 3 years or 10 years. Plenty of time for some nice phishing.

But no worries, we won't see a revoke. Comodo would go out of business if they invalidate certs of millions of customers. They'll certainly spend some money to avoid that, if needed.

Re:OK, which CA must leave the trusted list?

[ABasketOfPups]

I did this. And then close Firefox. Then Reopen. THEY'RE BACK.

Re:OK, which CA must leave the trusted list?

[Anonymous Coward]

This is one way MS could try to show THEIR trustworthyness (and one of the few benefits of having a near monopoly) - by simply setting up a policy to certify/decertify and then making the default process to manually add in a decertified CA point back to the reason they failed as well as links to what can happen form an untrusted CA.
We suffer with the drawbacks of a mono culture all the time, it sure would be nice to get some of the befits once in a while.

Re:OK, which CA must leave the trusted list?

[atraintocry]

The sole purpose of a CA is to see if the identity of the recipient matches the certificate

Quoted for emphasis. That is the only damn thing they are supposed to do, their raison d'être. It is the thing that separates buying their product from self-signing. I wonder how plausible a class action suit is, given that they've caused all of the certificates they've sold to be worthless.

Re:OK, which CA must leave the trusted list?

[atraintocry]

I agree somewhat but I'm not sure I'd put all of the responsibility on the buyer. What I would say is that Comodo owes current customers their money back, since they've been sold snake oil. Buyer beware up to a certain point, but I don't know that someone should reasonably be expected to do the legwork the author did. Comodo advertised a legitimate cert, right? That's what they should be selling.

Buyer beware works when the product is too good to be true. Are all third-party certs too good to be true? Maybe. But we can at least say in this case that they have some value (1-prevents attack, 2-comforts visitors because of #1). In Comodo's case #1 was shown to be non-existent and #2 is greatly diminished.

Of course, I've never had to go shopping for a certificate but I always got the impression that Comodo was one of those backwater CAs. Buy cheap and buy twice :)

Re:OK, which CA must leave the trusted list?

[atraintocry]

Oxygen tanks for everyone?

Wait...no just a tax credit so people could choose whether or not to buy an oxygen tank.

Re:OK, which CA must leave the trusted list?

[atraintocry]

He'd be a dictator if there was also laws that said only banks can lend money and only doctors can give health advice.

Re:OK, which CA must leave the trusted list?

[atraintocry]

* were also laws, whoops

Re:OK, which CA must leave the trusted list?

[The MAZZTer]

Funnily enough, I just found out Google Chrome uses Microsoft's list of root certificates.

Re:OK, which CA must leave the trusted list?

[bill_mcgonigle]

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.

The US Government's done a bang up job of regulating the banks, eh? I think I want better of my SSL supplier.

Both situations lack independent auditors and certification bodies, which I think the the real problem. You don't need the government sending in guys with machine guns to keep your bank solvent, you need independent auditors who can show up on any random day and crack the books, or force de-certification on the spot. If it's important enough, you increase the number of certifiers to avoid potential corruption and use reputation-based feedback systems.

and then...

[Anonymous Coward]

slashdotted-and then you wonder why I don't RTFA :-)

Google Cache

[Anonymous Coward]

There isn't a whole lot of info.

Another reference

[Slite01]

While the original blog is slashdotted, please enjoy this link to Google Groups: http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/9c0cc829204487bf?pli=1

I call BS

[Anonymous Coward]

my guess it is either phishing, a router compromise, someone taken over their DNS or a transparent proxy somewhere that is redirecting to alternate sites with a valid cert. This is not news people if your upstream is compromised.

Sensationalist - reroute & self signed certs

[owlstead]

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:Sensationalist - reroute & self signed cert

[owlstead]

This is a very old, already solved IE bug, sorry if that's confused anyone.

Re:Sensationalist - reroute & self signed cert

[bunratty]

In the perfect attack, the certificate is issued by a trusted certificate authority, so no warning is shown. It truly is a perfect MITM attack. We do know exactly who is issuing certificates without verifying the identify of the individuals requesting them. It's time for browser makers to remove some trusted CAs from their lists so users can be secure.

Use your OWN certs... or use CACert.org's

[fibrewire]

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.

Re:Use your OWN certs... or use CACert.org's

[u38cg]

Umm, and how do you establish that you trust your OpenID provider? By, umm, encrypting your communications with them...using a key signed by a CA. Oops.

wrong - parent didn't read before commenting

[Anonymous Coward]

the response here is sensationalist and irresponsible; this is a real attack possible due to a CA that is violating contracts and trust

Re:wrong - parent didn't read before commenting

[owlstead]

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 - basically
bumming). I am also using Windows XP and I formatted my hard drive last night
because I got a bug. So it's like I'm using a brand new computer.
It did this for facebook, myspace, hotmail, my college's network, and more.

Am I missing something here?

Re:wrong - parent didn't read before commenting

[owlstead]

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 capabilities of the Comodo certificates, lets see which web sites use those.

Re:wrong - parent didn't read before commenting

[Anonymous Coward]

Am I missing something here?

Yes. Something is seriously wrong with that.

Re:wrong - parent didn't read before commenting

[totally bogus dude]

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 that this is actually a real threat. At least, for bums using other people's APs. ;)

Re:Sensationalist - reroute & self signed cert

[Anonymous Coward]

actually, simply 'removing' a ca isn't quite sufficient, i think we're better served by remembering the ca with a note that it is NOT trusted.

otherwise a user can just go back and add it again.

"Citation needed" LOL

[davidwr]

Mod parent +1 funny grandparent -6 loser.

Sounds familiar

[sy5t3m]

Something about being issued a certificate for a domain you don't own sounds real familiar.

Oh yeah, I got issued some fake certs by startcom last time there was a story about SSL and firefox. Certs that would have allowed a perfect MITM attack against FF users.

So perhaps startcom should be looking again at their free SSL certs instead of posting lines like this on the previous blog posting:
"Dear beloved Mozilla community and brave know-all, freedom-loving geeks, please get yourself legitimate SSL certificates for your sites - you can get them freely from StartCom without paying a dime."

Anyone pulling off MITM attacks in the first place could easily target the startcom servers so that emails to microsoft.com actually end up in the attackers inbox. They only need that one email to receive the fake cert. Not as easy as simply asking for the cert, sure, but it's hardly a secure way to issue certs.

Re:Sensationalist - reroute & self signed cert

[complete loony]

To make it a perfect attack you need to either compromise DNS / BGP or sit in the middle of the data stream. I'm guessing the authors example does not do these things, so firefox and any other browser should complain. But if you were to setup a server with the fake mozilla.org cert and then redirect mozilla.org to this server via your hosts file, your browser would not complain at all.

which

[Anonymous Coward]

Which CA is this, and how do I disable it in safari?

Re:which

[hawaiian717]

Based on this post, it looks like "AddTrust External CA Root" is the one in question.

To disable it in Safari (and anything else that uses the Mac OS X keychain, such as Mail.app), open the Keychain Access program, which should be found in the Utilities folder in you Applications folder. In the keychains box in the upper left, click on System Roots. Double-click on the AddTrust External CA Root certificate, click the triangle next to Trust to expand that section, and in the popup menu next to "When using this certificate", change it to Never Trust. Close the window, and if you're prompted for your Administrator password, enter it. You should see the little certificate graphic in the left column of the list next to the name get a red X on top of it, and the status near the top should change from "This certificate is valid" to "This certificate is marked as not trusted for all users".

Who trusts the trusters?

[Gothmolly]

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).

Re:Who trusts the trusters?

[John Hasler]

It also a fundamental problem with the entire CA system and its underlying assumptions.

Re:Who trusts the trusters?

[Anonymous Coward]

The bug is not in the code-base. The bug is in the package of trusted CAs that ship with the browser.

If a browser trusts a CA which doesn't correctly verify the identities of certificate holders, then the browser is severely flawed.

So, what's the big deal

[guruevi]

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)

Re:So, what's the big deal

[Anonymous Coward]

SSL is not supposed to be preventing MITM nor is it supposed to be for identifying purposes.

No. SSL is designed specifically to permit identification of both parties (not that any uses client side certs), with the aim of preventing MITM attacks. This is one if its intentional design goals and it's why we have certificates at all. PGP has exactly the same problems that SSL does with chain of trust and verification of public keys. For any trust system that's used on a large scale (like SSL is, and PGP isn't) you *must* have automatic verification of trust and you must "trust" some sort of authority - peer to peer isn't going to cut it.

Re:So, what's the big deal

[agwadude]

SSL is not supposed to be preventing MITM nor is it supposed to be for identifying purposes.

I disagree. Why else does SSL have certificate signing capabilities? SSL even has client-side certificates for client identification, though it isn't widely used in HTTPS. In order for any asymmetric cryptosystem to work you need to exchange public keys, and you always have to establish some kind of trust system for those keys.

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.

Hence the need for SSL.

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.

This is a fault of how the key management in SSL has been implemented in web browsers, but says nothing about the technology itself. Two examples of systems using SSL with better (but less convenient) key management systems are OpenSSH and OpenVPN.

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.

There's a middle ground between "entity" and "communications." Yes, it is very difficult to verify that a certificate is being issued to the entity "Bank of America," but it should not be hard to verify that you're issuing a certificate to the domain name www.bankofamerica.com. And the latter is all you need to protect against MITM.

Re:So, what's the big deal

[Anonymous Coward]

From the wikipedia page on SSL:
"TLS provides endpoint authentication and communications confidentiality over the Internet using cryptography."

Which part of "endpoint authentication" is not supposed to be preventing MITM and is not supposed to be for identifying purposes? What does it even mean to authenticate a communication, except to say that you have confirmed that it comes from a given entity?

Re:So, what's the big deal

[Winged]

There's a middle ground between "entity" and "communications." Yes, it is very difficult to verify that a certificate is being issued to the entity "Bank of America," but it should not be hard to verify that you're issuing a certificate to the domain name www.bankofamerica.com. And the latter is all you need to protect against MITM.

No, it's not. Mozilla knows of at least one instance where a user on a public wifi network had communications with a TLS-secured site MITM'd, and she allowed it by creating a security exception for an unknown CA that issued a certificate to CN=*.

Re:So, what's the big deal

[Antique Geekmeister]

I agree with much of what you said, but the export restriction is not on 'firearms'. It's on 'munitions', or materials of war. The Wikipedia article on this at http://en.wikipedia.org/wiki/Export_of_cryptography is pretty clear on the history, but not clear on the primary purpose of such regulation, which is to discourage robust encryption on *all* communications, both domestic and foreign. This is designed to preserve government access to private data: the legality or proper use of such access is irrelevant to the desire to preserve such access. And historically, it hasn't mattered whether such access is legal: access has been considered vital.

Put the certificate fingerprint in DNS

[Anonymous Coward]

Put the certificate fingerprint in DNS. I lookup a domain name and get an IP address and fingerprint, allowing me to be certain that I am talking to whom I think I am talking to. No CA needed. (Of course, we need DNSSEC for this to really work.)

How does it help for an organization in Africa to certify that a given certificate is "legitimate"? What does that mean, anyway?

Re:Put the certificate fingerprint in DNS

[Anonymous Coward]

because DNS is completely secure, otherwise we'd need some sort of verification protocol which didn't rely on DNS at all to cryptographically confirm identity

Certificate revoked already

[c_g_hills]

When I visit the SSL server with the "compromised" certificate at 192.116.242.23, Firefox tells me:-

Secure Connection Failed

Peer's Certificate has been revoked.

(Error code: sec_error_revoked_certificate)

Unfortunately, a lot of applications do not check for revocation by default, and there are even some CA's who do not provide an online certificate revocation service, which is another weak link.

Re:Certificate revoked already

[c_g_hills]

Update: a bug has been opened to handle this incident. It seems the offending company was spamming, and nowhere did they state that they were a reseller for Comodo, nor were there any ownership checks done before issuing the certificate.

Big trouble at PositiveSSL.

[Animats]

The article is confusing, and the author declines to name the certificate issuer that's the problem. But the screenshot gives the details. It's PositiveSSL. He really did get PositiveSSL to issue him a Comodo-authorized cert in the name of "www.mozilla.com". Try this link and look at the certificate details.

It looks like certificates with this issuer information need to be rejected:

• CN = PositiveSSL CA
• O = Comodo CA Limited
• L = Salford
• ST = Greater Manchester
• C = GB

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.

Re:Big trouble at PositiveSSL.

[raju1kabir]

Try this link and look at the certificate details.

Looks like it's been revoked now. Firefox won't let me view the page no matter how hard I click, Safari doesn't seem to mind though (other than the host name mismatch).

Re:Big trouble at PositiveSSL.

[LunarCrisis]

Firefox is telling me that the site is not providing identity information (check Page Info), so they are probably just not serving the certificate anymore.

Re:Big trouble at PositiveSSL.

[raju1kabir]

Maybe we have different Firefox versions? Here's what Firefox 3.0.5 tells me:

Secure Connection Failed
An error occurred during a connection to 192.116.242.23.
Peer's Certificate has been revoked.
(Error code: sec_error_revoked_certificate)
The page you are trying to view can not be shown because the authenticity of the received data could not be verified.
* Please contact the web site owners to inform them of this problem.

Re:Big trouble at PositiveSSL.

[LunarCrisis]

Hmm, yeah, I get that too, but when I look in Page Info under Security, it tells me that they did not provide identification information. I guess that's a glitch, though, and it's just saying that because the site didn't provide verifiable identity info.

Re:Big trouble at PositiveSSL.

[Winged]

Comodo's "authorityInformationAccess" only provides an OCSP responder URL, not a CRL. Apple's Keychain doesn't really handle OCSP by default (you have to go into Keychain Access, go to properties, go to the Certificates tab, and select OCSP: Best Attempt).

However, that's a "soft fail" mode, and if you block the OCSP responder host, it'll still allow it both in Firefox and Safari.

Re:Big trouble at PositiveSSL.

[Anonymous Coward]

Every CA is required to provide a "Certificate Practice Statement" or CPS.

Mozilla should file a formal complaint with Comodo that they have failed in their CPS (section 4.1.2) obligation to "validate information provided by each Subscriber on the Comodo enrolment form prior to issuing a Certificate containing that information using the methods set out in the table at Section titled "Validation of Certificate Applications" of the CPS." per their "Comodo Relying Party Agreement ("Agreement")", presented as a legal contract between Comodo and anyone relying upon certificates issued by their CAs.

So, what does their CPS say about "Validation of Certificate Applications"?
Comodo CPS - [PDF Alert]

The end-entity certificate itself indicates that it has been "Domain Control Validated", implying that the applicant has legal control over the domain for which the certificate is being issued. The author, in this case, clearly has no such control over the mozilla.org domain.

IMHO, Comodo gets a FAIL, is in breach of contract and their CPS assertions, and Mozilla Foundation should file a complaint and make a claim against the Comodo warranty.

It should be sufficient justification for removal from any widely used application providing pre-installed "approved" CAs (a default truststore) and asserting that their end-users can trust their decisions on what CAs can be trusted "by default".

Mozilla Foundation and Mozilla Corporation have ample grounds to remove these CAs from their products per their existing policies.

Furthermore, the Comodo CPS has this gem:

b) InstantSSL Pro
InstantSSL Pro Certificates are the midlevel Secure Server Certificates from Comodo. ... All InstantSSL Pro Certificate applications include an out of bands validation
of the applicant's submitted information.
The maximum warranty associated with an InstantSSL Pro certificate is $2500.

I would say that Mozilla has a case for a $2500 claim for wrongful issuance of a certificate for their domain.

And under their Validation section, the Comodo CPS states in "2.4.1 Comodo SSL Secure Server Certificates":

Comodo Secure Server Certificates are offered in the variants listed below.
a) PositiveSSL Certificate
PositiveSSL Certificates are low assurance level Secure Server Certificates from Comodo ideal for mail servers and server to server communications. They are not intended to be used for websites conducting e-commerce or transferring data of value.

In accordance with section 4.2.2 (Validation Practices) of this CPS, PositiveSSL Certificates utilize third party domain name registrars and directories to assist with application validation in order to provide increased speed of issuance. Where possible, the third parties will be used to confirm the right to use the domain name used in the application. If the directory cannot be used to sufficiently validate a certificate applicantâ(TM)s domain control, further validation processes may be used. These may include an out of bands validation of the applicantâ(TM)s submitted information.

However, they have a nice disclaimer here:

Due to the increased validation speed and the nature of how Comodo intends
PositiveSSL certificates to be used, the certificates carry no warranty.

While I'm not defending Comodo, they could argue that the author, in applying for a certificate, knowingly violated their terms by requesting a certificate for a domain that he didn't have control over (and thus, is not their "fault"). They could also claim that they say that their certificates carry no warranty, as above (contradicting their other CPS that there is one), even though both appear to cover InstantSSL certificates

Re:Big trouble at PositiveSSL.

[Anonymous Coward]

As of now, it has been revoked.

government-regulated CAs

[Sloppy]

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.

Governments have a vested interest in keeping things insecure; they want MitM to be achievable, and making CAs answer to government means you can't trust them as introducers. Go ahead and have government-regulated CAs, if you want, but we need the capacity to have multiple signers for any identity so that we don't depend on that inevitable single point of failure.

I would never put my money in an unregulated bank, or send premiums to an unregulated insurer, or go to a back-alley doctor.

Switch to OpenPGP and you have a situation analogous to using the best bank/insurer/doctor. If one is untrustworthy, the other signatures remain. No government can possibly match that level of integrity. But they could become a part of it.

Re:government-regulated CAs

[QuoteMstr]

That's why you grant the government the ability to accredit CAs, not be a CA. If multiple governments do the accreditation, then we gain all the benefits of a web of trust without disrupting our current infrastructure.

Addtrust, and Comodo.

[Animats]

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? 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"

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. 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?

I'm sick of CAs that do nothing

[Anonymous Coward]

WTF are we paying CAs for if they are going to sit on their fat asses and do nothing???

These CAs not only put their own customers in danger they put all CAs and the entire PKI infustructure in danager.

If Comodo does not immediatly add their reseller to the revocation list we should do it for them by operating our own recovation lists containing CA's that are known to not be trustworthy.

There need to be consequences. CAs that are not trustworthy need to be yanked from the trusted third party list at the very least. This is **serious business**.

If their community won't do it we should opperate a recovation list or browser plugins to show relevent incidents known for the CA so the end user can make an informed decision.

What we should really do is get away from the CA vendor racket completely - use the domain registration systems to automatically issue and accept CSRs from those authorized to manage a domain and all this crap goes away overnight.

Efforts underway to resolve problem.

[Animats]

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.

Robert Alden of Comodo says they "have suspended Certstar's reseller activities until our investigation has been completed." The CertStar site 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.

Firefox is right to warn.

[tjstork]

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:Firefox is right to warn.

[StartCom]

That's because your company distributed their root or server certificate with the active directory or domain controller. Chrome currently relies on the windows cert store so does IE obviously. Not so Mozilla Firefox and hence the error.

Re:Firefox is right to warn.

[Anonymous Coward]

Your company is likely using a proxy server that also scans HTTPS traffic. It takes too much effort to actually look at all that junk, although taking over the proxy server and dumping all the usernames/passwords would be a juicy target, wouldn't it?

Re:Sensationalist - reroute & self signed cert

[Svartalf]

That would be correct. The thing is, that you CAN compromise some of the other needed stuff as well (which would be the MItM part...) and this CA that isn't following official stated procedures would be all you'd need to cover up the fact that it'd been done.

Re:Addtrust, and Comodo.

[Winged]

Certifying Authority keys are assets, and thus capable of being transferred. The original name might be out of business, but the keys still exist.

I don't know if there's an ongoing audit requirement in that case, though.

Re:Addtrust, and Comodo.

[Animats]

Certifying Authority keys are assets, and thus capable of being transferred.

That in itself is an interesting question. A "signature" is not normally considered a transferable asset. Also, there's a "relying party" liability associated with certificates. Signing carries with it obligations. Did Comodo acquire that liability?

Why not integrate with DNS?

[donny77]

Here is my idea. Add an SSL record to DNS similar to the MX record. Have the browser check the DNS SSL record for authorized CAs for the domain. This way, I can set up my own CA server, but I can only issue certs for my domain. I could issue a microsoft.com cert, but if there is no SSL record for my server in Microsoft's DNS, the browser will tell you it is an unauthorized cert.

Re:Why not integrate with DNS?

[Anonymous Coward]

But DNS is insecure itself and you can just at easily get attacked with a false dns replay. You'd need something like DNSSEC or similar implement first. Actually as things are, your idea would be way worse since now your browser would trust the fake CA that your attacker sent you and you'd get no warnings about connecting to an untrusted site.

Re:Why not integrate with DNS?

[Anonymous Coward]

Thats not going to work. DNS in its current form is less trustworthy than SSL certificates.

Re:Why not integrate with DNS?

[John Hasler]

How would Verisign make any money from that?

If you think it's insecure, change it...

[Anonymous Coward]

Tools->Options-> Advanced Icon Tab, Encryption Sub-Tab, View Certificates.

Find the offending certificate and hit delete... not sure which so I just wiped them off the list completely, though I'm sure there higher value certificates are still fine.

Can you do that in practice?

[Kadin2048]

Is this widely implemented? I've never heard of it before, although I'm by no means claiming any expertise. How does one go about setting it up?

I did some Googling but perhaps I'm searching under the wrong terms; nothing seems to come up besides people mentioning that it exists in the spec. Or is that all that exists right now?

Re:Can you do that in practice?

[(Score.5, Interestin]

Is this widely implemented? I've never heard of it before, although I'm by no means claiming any expertise. How does one go about setting it up?

Most servers and browsers support it, but any browser that connects to a server doing this is going to flash up all manner of warnings of doom and destruction because you haven't paid the appropriate CA tax to be allowed to run your server.

Our governments should do it...

[coryking]

Or at least they should. SSL certs, I think, are one area best served by government.

SSL certificates are the online version of your drivers license or your passport. We entrust our governments to provide us with reliable, trustworthy forms of identification. We know that if we see a drivers license or a passport, we can be reasonably certain the person holding said identification is who they claim.

Not so with SSL certs as they exist to day. Since private industry issues them, there are no standards. A $20 SSL cert from Godaddy is just as valid of identification as a $500 one from verisign. What is the difference? You'd have to ask nerds like us for an explanation, it isn't something anybody can grasp. As far as most people are concerned, both make the "key" at the bottom of their browser lock.

Ideally you should be able to walk into your DMV or whatever state or federal agency you register your business with and for a modest fee, get a government issued SSL certificate.

Letting the government deal with this has many extra benefits. For starters, we could make SSL certificates fall under the same kinds of laws that govern passports or drivers licenses. If you forge one, or enter fake information, you could be charged under the same laws that faking a drivers license fall under. For second, if done right, good governments would issue these for virtually nothing and maybe protocols like S/MIME would finally get widespread adoption.

What about open source projects who currently cannot afford SSL certs? Well, if the government does it, they could file as a non-profit and get one for free (or reduced cost).

How would this work from a technical standpoint? How would browsers deal with a long list that has every countries certificate authority? Dunno, but it seems it wouldn't be a big problem.

What international agency would regulate this? Who regulates passports? Dunno, but seems to me we already have a long history of internationally recognized identification--both for business and personal use. Why not task those guys with SSL certificates?

Bottom line, I know we all seem to hate more government, but SSL certificates are one thing governments should be doing, not private industries.

Re:Our governments should do it...

[RebelWebmaster]

And those governments would certainly never think of abusing such authority by creating backdoors for themselves. No, of course not...

Yet somehow passports works

[coryking]

SSL certificates are a form of identification just like a passport is. Seems to me the passport guys figured this stuff out. SSL certificates can't be much different in terms of treaties or regulation.

What we need is "eGiro"

[Kadin2048]

The "push" method of financial transactions is definitely the way to go.

Outside the U.S., and particularly in German-speaking Europe, the push system is fairly common even for paper-based transactions. Instead of writing a check -- which is a "demand instrument," basically a pull-initiated transfer -- a merchant gives you a little slip with their account number on it, which you sign and is sent to your bank, which then transfers the money to them. It would not be hard to do this electronically.

Let's say you go to buy something online. On the checkout page, rather than being prompted for your financial information so the merchant can draw against your account, the merchant instead gives you their account info, and some sort of unique transaction identifier. You open a new browser window and go to your bank's page, and enter the amount and transaction ID, then submit the transaction. When the merchant receives the money, they execute your order; if they don't get it within some period of time (24 hours or so), it's simply dropped.

The backend infrastructure exists for this already, in the form of direct deposits. With an ABA routing and account number, you can send money into an account at most banks, but (in theory, if the bank isn't stupid) can't withdraw it; thus there's no harm to a merchant in exposing this information. It's an intrinsically safer model than one where knowing an account number lets you arbitrarily draw money from it, as credit cards do.

Re:What we need is "eGiro"

[QuoteMstr]

Interesting, but it's fundamentally the same as the Paypal-web-service model, except less convenient for the user. Also, users will want some kind confirmation that their orders "went through". Doing that asynchronously is problematic.

How do you mass remove CA certs in Firefox

[teridon]

I think this problem highlights in my opinion a related issue in the Mozilla/Firefox certificate authority mechanism.

There doesn't seem to be a way to mass deploy (or, in this case, remove) a CA from it.

If I'm wrong, please enlighten me. The closest thing I have found is a Firefox extension that you can install that adds the CAs you choose (which I can't find a link to right now :( )

Re:How do you mass remove CA certs in Firefox

[phr1]

In firefox 3.0.5:

Edit -> Preferences and select the "advanced" (gear) icon. From there, select the "encryption" tab. Under that tab, click "view certificates" and then "authorities". Select any CA that you want to remove and click "delete".

Re:How do you mass remove CA certs in Firefox

[teridon]

Thanks for trying to help, but I said "mass deploy/remove" -- not *individually* remove from every single profile on every one of the 1500 computers in my organization.

Re:How do you mass remove CA certs in Firefox

[phr1]

Oh I see what you mean. The following approach may be worth experimenting with, but no promises: 1) Configure one browser the way you like it, using the method described above. 2) Look in your .mozilla/firefox/(profile name) directory for a file called cert8.db 3) Push that file out to other desktops in your installation.

Re:How do you mass remove CA certs in Firefox

[Mojo66]

I couldn't find RapidSSL in the list. Can anybody confirm this?

Re:Addtrust, and Comodo.

[Onymous Coward]

Well, there's some acquired liability...

Now that I know Comodo is responsible for at least some of the certs coming from the AddTrust key, I'm disabling AddTrust and Comodo.

Re:Addtrust, and Comodo.

[Onymous Coward]

Hey, the bogus Mozilla cert I got from StartCom has the following chain of issuers, starting with the cert itself:

1. CN PositiveSSL CA / O Comodo CA Limited
2. CN UTN-USERFirst-Hardware / O The USERTRUST Network
3. CN UTN-USERFirst-Hardware / O The USERTRUST Network

So PositiveSSL's cert was issued by USERTRUST, and USERTRUST's cert was issued by USERTRUST. I don't see AddTrust in the loop.

Here's the bogus cert that I saw.

person to person model

[reiisi]

You should never trust anyone you haven't met.

And you should never trust most of the people you have met, except in specific contexts.

And you should not really want anyone to trust you, except in specific contexts (in other words, where you have made contracts, whether explicit or implicit).

There are some emergency conditions when you have to override the above statements of fact (not rules, statements of fact), but, if you think about it, there is an implicit social contract that covers emergency cases. The rarity or commonality of the good Samaritan in a society is just a reflection on that society's penchant for breaking contracts, rather than evidence that trust does not require contracts. (There is an implicit social contract that we enter at birth, although there are some who make that contract out to be broader than it is.)

This whole business is at the center of what I have against Bill Gates and his crowd, and against Microsoft. The enabled the global ponzi schemes, if you think about it. (And we can rest assured, there will be more of them uncovered in the next year or so.)

another way to authenticate: perspectives

[Onymous Coward]

For the entirety of today I forgot about this project. Only now did I remember after seeing some comments on Reddit.

Multiple "notaries" who report what key they've seen and when they've seen it.

Check it out: Perspectives

You don't even have to replace your oligarchy of trusted companies (keys, rather), you could just use this tool in conjunction.

Certificate inspection not necessary

[Burz]

The primary (and legitimately, the only) purpose of the certificate is to verify the site's Internet address. i.e. that the site you are now talking to is the one that successfully applied for that domain name or IP in the first place.

So checking for A) the lock and B) correct domain in the address bar at the same time should strongly validate in your mind that there is no MITM, even if DNS is being attacked. This is all providing that C) no cert warnings appeared. If any one of those three 'legs' is missing, then the security table falls down... you cannot trust the connection.

If CA's backing up the above process is not good enough for you, then consider contacting the site operator "out of band" such as over telephone (heck, maybe in person) and verify their certificate's fingerprint. If it matches then you can safely import their certificate into your browser and be assured of a secure connection.

The only thing more secure than the above is having the operator give you a copy of their certificate in person.

And all of the above is predicated on both yours and the site's systems not being compromised with malware or unauthorized access.

"Monopolies", greed, ideas: CA / domain / IP / ID.

[Anonymous Coward]

Frankly I'm disgusted by the all the layers of profit oriented bureaucracy involved in provisioning essential internet 'metadata' which really could just as easily be made freely available (and once was). Want a domain name? Pay a registrar, and not just once, but on a recurring basis annually though their action on your behalf is a quasi one time affair. It could just as easily be $0 or $10 one time fee for 50 years to cover the (minor) administrative costs for the typical basic cases.

Want IP address space like an actually routable, transportable (between ISPs) class C CIDR IP block? Good luck with that, and if you can get it, again, be prepared to pay dearly on a recurring basis. This, like domain name services was once (not long ago) free; AFAICT the only reason it now is 'expensive' is pure greed. A domain name registration, SSL cert, or CIDR block delegation costs nothing more than a few kilobits of space in a couple of database records, and a few kilobytes per month of internet traffic to serve out the records in response to queries. In contrast a typically free of cost email account like gmail / mail.live.com gives you GIGABYTES of storage space, gigabytes per month of free network bandwidth to access the content, and is even more complicated to administer in many ways than a DNS zone or IP delegation or CA. It's senseless that we have free email and such and uber expensive IP delegations, CA certs, domain registrations, et. al.

Getting to the point of my 'modest proposal', IMHO all accredited domain name registrars should also typically be accredited / trusted CAs who have authority (at least) to issue trusted certificates for all domains within the TLD pool they're registrars for. Further, I think that when they register a domain for a customer a basic "moderate validation" SSL / code signing / identity type signing certificate should be given out for any registered domain included in the cost of that domain registration. That is simple assurance that if you're actually allowed to have / maintain the domain name, you have the simple and affordable mechanism to use that domain for SSL or email or DNS or whatever you need to do that is typically backed up by a certificate based identity reassurance. If you don't pay for / renew the domain, transfer it, or get it legally taken away due to illegal actions on the part of the operators then the current certificates get revoked at the same time by the registrar; very simple. This would go a long way (in convenience, affordability, simplicity) toward getting people to use things like DNSSEC, HTTPS, digitally signed email / MTAs, et. al. which would be of immense benefit to the entire internet's security. Typically the registrar will have some kind of reasonable assurance of who their customer is since they've paid for or at least filed the domain registration, and there'd be no question of party A improperly getting a valid CA cert for party B's domain which they don't even own / control in this situation.

If someone wants truly extended validation of the certificate then of course it'd be reasonable to pay nominal costs for the non-automated administrative costs of validating the organization's credentials manually or in person or whatever.

Furthermore, it seems like a reasonable proposal that any financial processor doing commerce / e-commerce related functions (think bank, credit card company, credit card processor, et. al.) which maintains financial accounts for customers should also 'freely' (as part of the basic cost of having such an account at all) issue digital signing / OpenID / SSL whatever certificate signatures indicating that person / organization X currently has a commercial account in good standing with the provider. If they close the account, they can revoke their signature. Thus if you're processing e-commerce credit cards and receiving payments into your Bank Of America merchant account, you'd have a 'free' Bank of America CA signature to use on your site's SSL cert or whatever for however long you had that

I reported similiar issue back in 2003

[juraj]

I wrote a similiar article back in 2003 for 2600 magazine.

I copied it here to my blog right now (so you don't need to find it in paper edition of 2600 magazine):

http://jooray.soup.io/post/10105517/State-of-art-certificates-Whom-do-you

Seems nothing has changed in five years.

Maybe not spying on you but protecting you

[I)_MaLaClYpSe_(I]

They might not have been spying on you. Maybe they were much more interested in securing the corporate network by detecting threats like accidentally or intentionally downloaded malware and hack tools and/or drive by downloads via HTTPS. Because, if you want your corporate AV scanners at your perimeter to be able to detect such threats you have to break up the encrypted HTTPS traffic in order to protect against it.

Of course, they could also have been worried about "extrusion prevention" and feared that internal documents might get uploaded via HTTPS or that trojans might be able to phone home without the possibility of detecting them.

Corp spying or something more simple

[Anonymous Coward]

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.

There are some other uses too. De-encrypting at proxy and then re-encrypting it with own cert before passing to client gives you ability to run plain traffic through network protection tools like antivirus and attack-detection/prevention scanners. Iirc squid can do this almost out of the box.

Encrypted traffic is an efficient attack vector into corporate LAN and the attacker has to only penetrate the last line of defence, local antirus software running on workstation.

And yes, it can also be used for spying you.