Are Some CAs Too Big To Fail?

User ignorance by betterunixthanunix · 2011-09-07 08:15 · Score: 3, Insightful

Maybe we should do a better job of teaching people about computers and technology when they are in high school. CAs are able to get away with poor practices and poor security because most computer uses have no clue what a CA is. If people would start disabling Thawte's certificates en masse, Thawte would be forced to protect its business by regaining the users' trust.

--
Palm trees and 8

Re:User ignorance by jellomizer · 2011-09-07 08:25 · Score: 3, Interesting

The problem with CAs are that they never really do their job quite well. If you are paying hundreds or thousands of dollars for a Cert they really should do a lot more work to verify who you are and the browser should identify the level of security the Cert gives.
A cheap level (Under $50 per IP) for those B2B type of apps where you are connecting to a trusted source anyways but you don't want the error message or tell your customer to setup something new. A one note should suffice. Then you got a level good for online business (Under $500) this is for online stores, the CA needs to determine that it is a real store with the ability to sell the goods. However the browser should alert when ever there is a data stream that looks like a social security number or pushes a request for such non-merchant information. then you got the premium HIPAA level cert where it the CA needs to keep a close eye on its organization make sure the companies security is strong enough for the CERT this would be a full allow for the browser.

--
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Re:User ignorance by fuzzyfuzzyfungus · 2011-09-07 08:47 · Score: 1

I'm highly doubtful of the efficacy of that. There are numerous business areas, even well-known names, who do just fine despite public opprobrium.

A highschool course in IT taking down Thawte or forcing them to clean up their act would be about as likely as a highschool course in personal finance bringing down Goldman-Sachs or leading to the end of byzantine financial chicanery...
Re:User ignorance by Bert64 · 2011-09-07 08:50 · Score: 2

Self signed certs would probably be a better idea for businesses you already have a relationship with, like banks... You already have offline contact with the bank via mail or even walking into a branch, so they could use this to send you their certs and you won't have to trust anyone else.

--
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Re:User ignorance by Squeebee · 2011-09-07 08:52 · Score: 1

Oh yes, and while we're at it we'll teach them all how to fix a car so they can call out their mechanic if they recommend un-needed repairs, and teach them all construction so they can better review the work of the guy who builds their next home, and we'll put them all through medical school so they can better hold their doctors to best practices.
Honestly, there's a point where you have to get off your high horse and realize that we have specializations for a reason, and it behooves those in the know on a given subject to realize that it's not practical for every user of their output to be an expert in their field, so the onus is on the experts to make it easy for the non-experts.
Re:User ignorance by rabtech · 2011-09-07 08:56 · Score: 1

Any system that relies on users to know what is or isn't good is doomed to failure. Users don't check the address bar and don't know about certificates, nor should they.
All too often their machines are 0wned already by malware and spyware, probably because they saw some cute puzzle game and just kept clicking OK at that damn dialog box getting in the way of playing my game!!!

--
Natural != (nontoxic || beneficial)
Re:User ignorance by geekmux · 2011-09-07 09:07 · Score: 2

Maybe we should do a better job of teaching people about computers and technology...
Sorry, had to stop you right there, because the only thing that is ignorant here is thinking that users will actually learn to use the very device they rely on for damn near everything.
Just saying, if users haven't learned by now, they won't. Period.
And while we're on the topic of ignorance, can we please get the hell away from this "too big to fail" crap? Do images of the Titanic at the bottom of the sea paint enough of a picture? Does the word "Rome" ring a bell? I mean c'mon, seriously, let's at least try and pretend we're actually learning from history here.
Besides, the only way to truly answer that question in modern times is to actually let failure happen. Seems we don't have anyone around with the guts (or brains?) to allow that to happen.
Re:User ignorance by tlhIngan · 2011-09-07 09:23 · Score: 1

Self signed certs would probably be a better idea for businesses you already have a relationship with, like banks... You already have offline contact with the bank via mail or even walking into a branch, so they could use this to send you their certs and you won't have to trust anyone else.
Why not have the bank be the CA for the businesses it does business with? That way, any business needing an SSL cert can go to their bank and get one. The bank's reputation is on the line and there's a definite trust entity in that way - the bank has to know you and will have access to your real contact details. It could be just like their merchant accounts.
Of course, this only works for businesses, not those doing HTTPS because it's in general a Good Idea(tm).
Re:User ignorance by houstonbofh · 2011-09-07 09:29 · Score: 1

Not SELF SIGNS CERTS! I have seen the warnings in FireFox! SELF SIGNED CERTS will eat my babies, rape my dog, and make my hair fall out! Anything but that!

Yes, this is sarcasm in that FireFox will go apeshit over a self signed cert, but pass all these fraudulent ones for months until people actually run the update.
Re:User ignorance by X0563511 · 2011-09-07 09:31 · Score: 1

However the browser should alert when ever there is a data stream that looks like a social security number or pushes a request for such non-merchant information.
I'd love to see you try to implement that...

--
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Re:User ignorance by Zironic · 2011-09-07 09:37 · Score: 1

The term 'too big to fail' doesn't refer to being unable to fail but rather, not being -allowed- to fail because the consequences of failure would be too catastrophic.
Re:User ignorance by heypete · 2011-09-07 09:43 · Score: 1

CA-issued certs, even free ones from StartSSL and cheap ones from GoDaddy, have the advantage of being revocable. Nearly all the self-signed certs I've encountered lack a CRL or OCSP responder. This is a Bad Thing.
Re:User ignorance by pjt33 · 2011-09-07 09:46 · Score: 1

Are you saying that you want browsers to only work to spec in the USA? Or are you expecting browser developers to have regexes for social security numbers in every country in the world, and to keep up-to-date with the legislation which is the closest local equivalent to HIPAA?
Re:User ignorance by pjt33 · 2011-09-07 09:53 · Score: 1

Specialisation is for people who want to live securely in large communities. It's one thing to design a small hut for a temperate climate, and another to design a block of flats which can withstand a natural disaster. It's one thing to program a computer, and another thing to write robust software which handles exceptional cases well and doesn't let a script kiddie drive a bus through it. So by all means, attempt to eliminate specialisation, but only if you're happy living in a small hunter-gatherer community.
Re:User ignorance by 0123456 · 2011-09-07 10:18 · Score: 1

You already have offline contact with the bank via mail or even walking into a branch, so they could use this to send you their certs and you won't have to trust anyone else.
I would totally, TOTALLY, trust a self-signed cert for my bank that turned up on a CD in my mailbox over one that was signed by a CA.
Re:User ignorance by UnknownSoldier · 2011-09-07 10:23 · Score: 1

> The term 'too big to fail' doesn't refer to being unable to fail but rather, not being -allowed- to fail because the consequences of failure would be too catastrophic.
Which is a bogus term. "too big to fail" = "the general population gets fucked with the bill"
True Story:
Forest Ranges used to be anal about stopping _every_ forest fire. They eventually learnt that this makes the situation _worse_ in the _long_ run because all the decay that _would_ of been cleared when a big fire hits, is still there.
See: http://en.wikipedia.org/wiki/Controlled_burn
_Every_ government has collapsed. It is not just a matter of IF, but WHEN. Propping up entities artificially doesn't change that fact.
Re:User ignorance by vetman · 2011-09-07 10:31 · Score: 1

No problem, I will drop one in your mailbox or maybe just leave a USB flash drive on your driveway. You trust me er I mean local home town bank labeled CD right? (/sarcasm) We do need to BUILD the TRUST up with these CA's. I would not have trusted DigiNotar if I knew they were running vulnerable weak password Windows boxes. I do agree that self-signed certs are just as secure, but when dealing with unknowns on the Internet we need the trust to start somewhere. I think there are already way too many certs in my browser and they are already valid until 2040! Yikes.
Re:User ignorance by Lennie · 2011-09-07 11:34 · Score: 1

An man-in-the-middle attacker can just drop the packets to the OCSP (do browsers by default even download any CRL's anyway ? usually they are just to large like 700MB+) it will timeout and the browser by default will just continue.

--
New things are always on the horizon
Re:User ignorance by webnut77 · 2011-09-07 13:15 · Score: 1

I agree but you shouldn't stop there. Banks and insurance companies are not 'too big to fail'. Once you reach the 'too big to fail' status there is no disadvantage to taking adverse risk since someone else will foot the bill for your failure.
Re:User ignorance by lennier · 2011-09-07 15:20 · Score: 1

Do images of the Titanic at the bottom of the sea paint enough of a picture?
As they say, sometimes failure isn't an option - it's mandatory.

--
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
Re:User ignorance by heypete · 2011-09-08 05:40 · Score: 1

Sure, the revocation process could use some improvements (I'd really like to see browsers hard-fail if OCSP doesn't work, or at least display a warning to the user that the certificate's validity could not be checked and to treat the connection as suspicious).
That said, there are a number of scenarios where certificates need to be revoked where the CA itself was not compromised. Having a CA that's able to revoke certs is valuable in such situations.
Re:User ignorance by gsnedders · 2011-09-08 10:03 · Score: 1

Opera marks the page as insecure if it fails to get a response to the OCSP request (IIRC since 9.5), though everything else continues as if the OCSP response was such that the certificate is valid. Fail-secure seems like a rather dumb strategy, though is what the majority of the market does. :\

Notary Servers by slackergod · 2011-09-07 08:16 · Score: 1, Interesting

Just to provide some links to the "alternative approach" mentioned in the summary:

* The Perspectives Project spearheaded the concept of independant notary servers instead of a chain-of-trust.

* Convergence is another spin on the same concept, by Moxie Marlinspike in fact. (Not sure if it's compatible w/ Perspectives, but I think it is)

Re:Notary Servers by CommieLib · 2011-09-07 08:31 · Score: 1

I took a long look at Convergence, but it suffers from the old fax machine problem...until there are hundreds of notaries, we have the same "trust agility" problem that the system seeks to address.

Furthermore...I would hate to be the subject of a later video from Marlinspike about how all these users gullibly accepted his notarizations of these certs. The whole situation is a nasty, twisty problem...and the worst part is that hosts can't do a thing about it.

--
If your bitterest enemies are people who hack the heads off civilians, then I would say you're doing something right.
Re:Notary Servers by AliasMarlowe · 2011-09-07 08:40 · Score: 2

The whole situation is a nasty, twisty problem...
...and it is dark. And I smell a Wumpus...

--
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
Re:Notary Servers by CommieLib · 2011-09-07 09:51 · Score: 1

That was definitely kicking around in there somewhere...

--
If your bitterest enemies are people who hack the heads off civilians, then I would say you're doing something right.

Too big to fail... by houstonbofh · 2011-09-07 08:19 · Score: 4, Insightful

Too big to fail means too big to give a shit. Failure is the motivator for performance. With no cost for bad performance, there is no incentive for good. Just ask the "big" banks, or better yet, ask the customers...

Re:Too big to fail... by hierophanta · 2011-09-07 08:35 · Score: 2

Or our government, or better yet, ask the citizens.

F and i thought i was a dem
Re:Too big to fail... by Anonymous Coward · 2011-09-07 08:47 · Score: 2, Insightful

Both Democrats and Republicans (and even Tea Partiers, from what I've seen....) are for big government. The argument is what part of the government should be big.
We compromise by making both sides big.
Re:Too big to fail... by elsurexiste · 2011-09-07 10:01 · Score: 1

I'd say "Too big to fail := Too big to exist". ;)

--
I rarely respond to comments. Also, don't ask for clarifications: a brain and Google are faster, believe me!

Good point by houstonbofh · 2011-09-07 08:24 · Score: 3, Interesting

Time for a new plug in. Cert Blocker Plus. Automatically updates with a list of certs know to be compromised, questionable, run by governments, or members of the opposing party. :) (Actually, I can see this coming out soon, and if someone patents this, I call prior art!)

Re:Good point by master5o1 · 2011-09-07 09:20 · Score: 1

How would I trust that this plugin does the blocking of everything correctly and how I want it?

--
signature is pants
Re:Good point by thatbox · 2011-09-07 09:28 · Score: 1

Presumably by contributing to such a project. That's how this stuff tends to work!
Re:Good point by houstonbofh · 2011-09-07 09:33 · Score: 1

That is actually a problem with the basis for this, Add Block Plus. http://adblockplus.org/en/ Which is why, while I use it, I do not use the built in lists. Go figure that the feature I am promoting in my shameless ripp off is the one I do not use in the originator. :)
Re:Good point by cheater512 · 2011-09-07 11:56 · Score: 1

Perhaps we could sign it for authenticity with a certificate provided by a trusted third party.....oh wait.

Segmentation by mehrotra.akash · 2011-09-07 08:24 · Score: 1

I'm not too sure how CA's work, but if till this point we know, say "Thawte" is uncompromised.
Then, secure Thawte, issue new certificates using a different name, say "Thawte2"

Change this name every year or so, securing the previous certificates.

This way, in case of a compromise, only a max. of 1 year of certs are invalidated

Marlinspike's approach by AceJohnny · 2011-09-07 08:29 · Score: 5, Interesting

Marlinspike's approach, implemented in a Firefox extension presented at DefCon '11, is to do away with the notion of CAs altogether in SSL, replacing it with a distributed network that reports on the certificate they see. Basically, if the certificate you see agrees with the rest of the network, then you're not being spoofed.

He had previously explained the properties a replacement to the CA system had to demonstrate in order to be viable

--
Misleading titles? Inflammatory blurbs? Keep in mind that Slashdot is a tabloid.

Re:Marlinspike's approach by Piranhaa · 2011-09-07 09:27 · Score: 1

You don't think Google or Microsoft can make notaries? .. They have bots that scour and cache the internet already. Grabbing the ssl certificate of a site and caching it isn't that much more to deal with. Plus, I have the option of hosting a notary at home if I want.
The idea is to get a proof of concept out there, and a decent implementation of it I might add (I'm running it at work, home, and school). We just need to get the major browser vendors onboard (MS, Google, Apple), and then get it rolling.
The beauty of it is that the current https infrastructure doesn't need to change. If a certificate is signed, and it checks out at both the client and notary level, it's valid. Same goes for self-signed certificates.
According to these guys, there is already a convergence notary fork in the works using Google's help.
http://security.stackexchange.com/questions/6778/how-does-convergence-ca-replacement-prevent-its-notaries-from-being-mitmd-as-w
Re:Marlinspike's approach by vadim_t · 2011-09-07 09:52 · Score: 1

How do you authenticate the authentication server?
If I got it right, this system needs to contact some server that says "I cerfity this cert as valid, because the fingerprint was the same from the 50 different network paths we checked it". Ok.
But, that message has to be transferred securely as well, otherwise Mallory just spoofs that server, and you've got no security. And you can't do the checks yourself because you don't have 50 servers around the world you can use for testing.
Re:Marlinspike's approach by OverlordQ · 2011-09-07 10:26 · Score: 1

How do you authenticate the authentication server?
You dont. You are the authentication server, and you ask 50 servers.

--
Your hair look like poop, Bob! - Wanker.
Re:Marlinspike's approach by vadim_t · 2011-09-07 10:38 · Score: 1

That's not very useful if your ISP is doing the MITM, which is very much a reality in many places right now.
For instance, there have been several articles here on ISPs injecting content into the websites they serve.
Re:Marlinspike's approach by vadim_t · 2011-09-07 12:30 · Score: 1

But that's not very useful, because compromising one CA gets you back to the same situation again.
It's just lucky that the compromise is public this time, they don't have to be. The attacker could make the cert then spring the trap at a convenient time. By the time somebody figures it out, the damage will be done already.
Re:Marlinspike's approach by ewanm89 · 2011-09-07 13:21 · Score: 1

No, if the ISP is doing MITM, they won't be MITM all those 50 too. So all you have to do is check those cert fingerprints to check the first connect for them.
Re:Marlinspike's approach by ewanm89 · 2011-09-07 13:23 · Score: 1

EFF's SSL Observatory already has spiders crawling and collecting SSL certs.
Re:Marlinspike's approach by vadim_t · 2011-09-07 16:51 · Score: 1

How are you so sure of that? What would prevent it?
They're in between you and those 50, they can spoof everything they like.
Re:Marlinspike's approach by swillden · 2011-09-07 23:17 · Score: 1

But that's not very useful, because compromising one CA gets you back to the same situation again.
No, that's the whole point, compromising one notary does NOT get you back to the same situation.
A client should contact more than one notary when it sees a new site certificate, so a single compromised notary can't fool it. Even more important, if a notary proves untrustworthy browser makers can remove that notary's certificate from their list and push an update. Under the current system, removing a CA's cert means that all sites certified by that CA lose certification, which means that shutting off Verisign or Thawte would basically make SSL stop working. But removing one notary of many wouldn't have any impact, because the remaining notaries can still vouch for all certs.
One thing that people often miss about Marlinspike's approach is that it isn't necessarily a replacement for the CA system, it can simply be an augmentation. There's nothing preventing clients from using both and only accepting a site certificate if both systems show it as valid. That would make attacks nearly impossible.

--
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Re:Marlinspike's approach by OverlordQ · 2011-09-08 04:02 · Score: 2

That's not very useful if your ISP is doing the MITM, which is very much a reality in many places right now.
To add a notary you have to input the public cert for the notary, how do they MITM that without throwing warnings.

--
Your hair look like poop, Bob! - Wanker.

Already happened by robmv · 2011-09-07 08:29 · Score: 1

with Comodo, they only hardcoded some certificate signatures but did not revoke the entire CA. There is another problem: "your website is too small to care". I am not sure if a small business operator will receive the same treatment like they did with Comodo, patch their browsers to protect users of your small site

CAs should have to post a bond by Animats · 2011-09-07 08:29 · Score: 1

CAs should be limited to sets of domains, and this enforced in browsers. Country-level CAs should be limited to the country in which they operate. Government CAs should be limited to their domain (".gov", "mil.uk", etc.).

CAs for the open domains should have to post a big bond, which can obtained through a bonding agency if necessary, with a value of at least $10 million, to back up their "relying party agreement".

That's what "corporate responsibility" means - third party bonding.

Re:CAs should have to post a bond by vlm · 2011-09-07 08:45 · Score: 2

CAs should be limited to sets of domains, and this enforced in browsers. Country-level CAs should be limited to the country in which they operate. Government CAs should be limited to their domain (".gov", "mil.uk", etc.).
CAs for the open domains should have to post a big bond, which can obtained through a bonding agency if necessary, with a value of at least $10 million, to back up their "relying party agreement".
That's what "corporate responsibility" means - third party bonding.
Well, theres one thing I guarantee we are not going to do. Lets look at the american experience:
1) I trust my employer to give me a job for life in return for my loyalty. Whoops
2) I trust my bank to only loan me a mortgage I can pay off. Whoops
3) I trust my health insurance company to be there for me when I'm sick. Whoops
4) I trust my car insurance company to help me with my claim. Whoops.
5) I trust my hardware store (and China) not to sell me poisonous drywall. Whoops.
6) I trust my food store not to baby food full of melamine. Whoops.
7) I trust my toy store not to sell kids toys covered in lead paint. Whoops
8) I trust my gas station to sell gas that is free of sand and water. Whoops
9) I trust my govt not to sell me out for campaign contributions. Whoops
10) I trust my higher educational institution to train and/or educate me for a good paying job, so I can pay off spectacular student loans. Whoops
11) I trust my CA to operate securely. Hmm... I wonder how thats gonna turn out? Whoops
The business model of america for the past generation or so, is to find a trust, break it for profit, and move on to the next area.
If you're trusting a corporation, thats a pretty strong indication you're doin' it wrong. Come up with a different design.

--
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Re:CAs should have to post a bond by X0563511 · 2011-09-07 09:39 · Score: 1

6) I trust my food store not to baby food full of melamine. Whoops.
They accidentally the whole jar?

--
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Re:CAs should have to post a bond by houstonbofh · 2011-09-07 09:50 · Score: 1

I really hate how insightful that is.
Re:CAs should have to post a bond by Bucky24 · 2011-09-07 10:13 · Score: 1

2) I trust my bank to only loan me a mortgage I can pay off. Whoops
Why on earth would you trust that?

--
All the world's a CPU, and all the men and women merely AI agents

Re:No... by vlm · 2011-09-07 08:29 · Score: 1

We shouldn't have CAs at all, they have proven themselves irrelevant, untrustworthy and insecure.

... and highly profitable, which is why we'll never get rid of them, unfortunately.

--
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger

Re:No... by vlm · 2011-09-07 08:31 · Score: 1

So... you're saying he's qualified to run a CA? LOL

--
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger

There are more problems with SSL than this by rickb928 · 2011-09-07 08:32 · Score: 1

We regularly find Windows workstations that won't accept a valid certificate from any of several known good servers one of our applications use. Sometimes installing the root certificate solves it, but often it doesn't. Most of the time reinstalling Windows is the only solution.

Microsoft is of no use in these circumstances, as they avoid dealing with root certs at all. The CA also has no answer. Applying root updates, the specific certs, an all-encompassing cert, even removing and reapplying the CA in Windows doesn't always solve it. And yes, 90% of our users never have any trouble. Even clean Windows installs sometimes fail. It's not so simple as malware.

Several things are rotten in SSL. We need something better.

--
deleting the extra space after periods so i can stay relevant, yeah.

Re:There are more problems with SSL than this by Abalamahalamatandra · 2011-09-07 08:55 · Score: 1

This isn't related to an intermediate CA issue, is it?
For example, Entrust, as part of the switch to 2048-bit certs, starting using an Entrust L1C chain authority - and we've had to load that L1C intermediate certificate onto servers to get them to recognize the certs that Entrust issued. Until you load them, the UI is not terribly helpful - the certificate chain tab doesn't show the missing L1C certificate.
Re:There are more problems with SSL than this by rickb928 · 2011-09-07 09:14 · Score: 1

Our problem is that we have workstations that cannot negotiate connections despite having valid certificates. The certs install fine, just don't work.
Yes, i'm sure its our fault. understood.

--
deleting the extra space after periods so i can stay relevant, yeah.
Re:There are more problems with SSL than this by rickb928 · 2011-09-07 09:18 · Score: 1

One set of certs are Equifax, the other from GTE Cybertrust. Both have troubles.

--
deleting the extra space after periods so i can stay relevant, yeah.
Re:There are more problems with SSL than this by X0563511 · 2011-09-07 09:41 · Score: 1

Our problem is that we have workstations that cannot negotiate connections despite having valid certificates. The certs install fine, just don't work.
Yes, i'm sure its our fault. understood.
That's entirely Microsoft's shoddy implementation at fault. YOU think the certificate is valid. The OS disagrees. It's not the certificate's fault the OS won't listen to your instructions to trust it.

--
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Re:There are more problems with SSL than this by Kalriath · 2011-09-07 11:52 · Score: 1

Um, no. The plural of anecdote is not data, and the singular sure as hell isn't either. One person having issues with their SSL with no evidence of anyone else having that same problem is almost 0% likely to be an issue with the implementation which is the same as that of millions of other people without that problem.

--
For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
Re:There are more problems with SSL than this by X0563511 · 2011-09-07 13:09 · Score: 1

Interesting, so you're saying you have millions of data points behind you?
I can't be bothered to tally mine up, and I'm sure the same is true for you. That we're even having this conversation is proof enough that it's fucked enough to have an unacceptable rate of failure.

--
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Re:There are more problems with SSL than this by rickb928 · 2011-09-07 13:16 · Score: 1

Millions don't use these servers.
It still doesn't work.
It's SSL, the traces show SSL is refusing the connection.
Like I said, must be us.

--
deleting the extra space after periods so i can stay relevant, yeah.
Re:There are more problems with SSL than this by Lennie · 2011-09-08 00:46 · Score: 1

You don't by any chance have connection problems to Microsoft ?
As Windows comes with only a few root certs by default, the rest is checked on first-contact by contacting Microsoft to see if they think it is a good CA.
Even if the user has no administrator rights, it will still install the CA-root certificate on the machine-account.

--
New things are always on the horizon
Re:There are more problems with SSL than this by rickb928 · 2011-09-08 01:36 · Score: 1

This problem affects >40 of our users. It's not me. Our application uses Windows and OpenSSL. The network traces are definitive.

--
deleting the extra space after periods so i can stay relevant, yeah.
Re:There are more problems with SSL than this by rickb928 · 2011-09-08 02:55 · Score: 1

Not one person. >40 of our users across the US and oversease are having these problems.
And the network traces are definitive. We see the connection attempt, the server offers its certificate, we refuse it, server says 'goodbye' correctly.
And we see plenty of root certificates in these Windows installations. MS has expanded the Root CA program dramatically. Lots of national CAs are in there. I like the proliferation of Chinese authorities about as much as a stick in the eye.

--
deleting the extra space after periods so i can stay relevant, yeah.
Re:There are more problems with SSL than this by rickb928 · 2011-09-08 02:59 · Score: 1

And no, we are unaware of connection problems to Microsoft. We see good Windows Update sessions, we can download the rootsupd.exe when we ask for it, and we do NOT see any network call to Microsoft in response to the failed attempt.
I'm not professing to be an SSL expert, I just know what I see, and we see problems getting root certificates installed correctly and working, and there is literally NO help from MS or the CAs. MS is mute on the subject, even abandoning a support call without explanation.
My suspicion is that SSL is something they just don't want to explain or troubleshoot beyond what is publicly available, as if telling us how it works increases the possibilities of compromise. Like that horse isn't already gone.

--
deleting the extra space after periods so i can stay relevant, yeah.
Re:There are more problems with SSL than this by Lennie · 2011-09-08 11:02 · Score: 1

I would think if your CA does not give you proper support. You might be better of switching CAs ? I'm surprised Microsoft doesn't give you support. I would expect them to do so if you open a ticket and pay them for it.
I guess you could also switch operating systems ;-)
An other possibility is that you are getting infected with some malware, maybe ?

--
New things are always on the horizon
Re:There are more problems with SSL than this by Kalriath · 2011-09-08 12:56 · Score: 1

It doesn't work that way. When trying to claim something is at fault, the onus is on you to prove that's the case - and I guarantee you can't.

--
For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
Re:There are more problems with SSL than this by rickb928 · 2011-09-08 13:23 · Score: 1

We don't choose the CA's (there are 2), they are chosen by another party. We might be infected by malware, but our users are scattered over the U.S., Canada, and India. Switching OS is not an option. Microsoft was happy to take our ticket but could not answer any question.

--
deleting the extra space after periods so i can stay relevant, yeah.

Re:No... by Tasha26 · 2011-09-07 08:42 · Score: 1

However i play this certifcate game in my head, i find that we need CAs. The ones we got are simply not fit for the job and the govt needs to revoke their license.

$90,000+ by grimharvest · 2011-09-07 08:47 · Score: 1

Average pay for a server admin, and yet major sites getting hacked left and right, the Net steadily becoming more unsafe all the time: http://www1.salary.com/Client-Server-Database-Administrator-salary.html Must be nice to get paid to fail.

Re:$90,000+ by dkuntz · 2011-09-07 08:59 · Score: 1

Or it could be, as is often the case in the corporate world, that the server admin's hands are tied by their managers, and their manager's managers, etc. A sysadmin may have the best, most secure, idea ever though of, but if someone up the chain decides "we've done in this way for 10 years, we'll continue to do it this way", then it's moot.

--
OMG... I have a sig?
Re:$90,000+ by dkuntz · 2011-09-07 09:00 · Score: 1

and... s/done in/done it

--
OMG... I have a sig?
Re:$90,000+ by houstonbofh · 2011-09-07 09:54 · Score: 1

It is not just paying the money. You also have to listen to the advice. Occasionally, that is rare in some management types. (No, you do not need root on the mail server.)
Re:$90,000+ by rve · 2011-09-07 23:42 · Score: 1

In the country where DigiNotar was based, you'd be lucky to get half that.

What a poisonous concept we've embraced. by Beelzebud · 2011-09-07 08:48 · Score: 1

Too big to fail.... Just a sign of the times I guess. Don't expect anything to get better if this is the question we ask ourselves.

Re:What a poisonous concept we've embraced. by Rich0 · 2011-09-07 14:34 · Score: 1

Yup, in my book too big to fail is too big to exist.
When something too big to fail does fail, the solution should be a government takeover for the public interest. The government keeps the operation running, dives through the records for evidence, and then files criminal charges against the former management and sues them for damages.
The too-big organization is then chopped up into manageable pieces and they're all IPOed. The proceeds are used to pay off first any expenses incurred by the government to run the operation, then any debts held by the organization, and then the former shareholders (if there is anything left then it is the true value of the company and this satisfies the eminent domain requirements). The new companies are considered debt-free and are owned only by their new shareholders.
With such an arrangement you won't find too many companies begging for bailouts...

Re:No... by vlm · 2011-09-07 08:54 · Score: 1

The ones we got are simply not fit for the job and the govt needs to revoke their license.

What license? I suppose it depends on the country, but none is necessary here. If one was necessary, "they" contribute tens of thousands to re-election campaigns of multiple politicians, and "you" probably do not. Wonder how thats gonna turn out.

I run my own CA. Its not hard. I certainly needed no license. (Note: I guarantee my root cert is not in your browser). Reason why is some apps like fetchmail, dovecot imap, dovecot POP3, and a couple others, are easier run over SSL than thru shared SSH keys. Also, it was remarkably easy.

--
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger

Confused... by Junta · 2011-09-07 08:54 · Score: 1

'It's not a simple matter of removing certificates from a database, because they're not in any databases,

I don't get this. Removing/replacing a CA cert from trust is easy for browsers/os vendors to do, technically (CA should be on the hook to re-certify certs if they are forced to remove their cert from circulation).

With OSCP, at least *good* certificates *are* in a CA's database, and OSCP will fail for any signed certs that cannot update the OSCP server's hosted copy. Implementation wise, OSCP validation is done poorly, but that's not a flaw of the theoretical design.

There is a whole lot of people calling to throw the baby out with the bathwater in x509, but a 'simple' tweak of mandatory, *affirmative* (no saying 'ok' to server errors or 'try again') OSCP validation to indicate any hint of trustworthiness. If a CA screws up, kick em out.

In terms of more 'radical' changes, I've liked suggestions such as 'require multiple CAs to sign a CSR' and 'publish the CA(s) that are *expected* to be in use via DNSSEC' (requiring attacker to compromise the *specific* CA in use or compromise DNSSEC as well as a CA). I'm wary of key distribution via DNSSEC (requires implementation too pervasive to be practical, theoretically lands you into more dubious territory than current CA model), and I'm wary of Perspectives/Convergence (I'm dubious on how trust gets established in the first place, and I would not be surprised if these systems fell flat on their face under the onslaught of the 'unwashed masses'). Lot's of attacking current state of x509 in the name of advocating some drastic change without enough thought around fixing the weaknesses while preserving the proven strengths.

--
XML is like violence. If it doesn't solve the problem, use more.

Re:Confused... by ewanm89 · 2011-09-07 13:05 · Score: 1

convergence/perspectives use multiple servers around the internet called notaries, when you connect to a site you also connect to these notaries and ask what they see for the site (this is in perspectives mode, notaries can do other things in convergence), now if they don't match with what you got then either you or they are being MITM attacked and therefore the connection is dropped with an error (in convergence the user can control just how much of a match is needed, 1, majority, consensus). The idea is that the attacker would have to MITM you and the notary (depending on match mode, 1 or more of them) at the same time. Not easy especially with multiple notaries placed around the world.
Re:Confused... by icebraining · 2011-09-07 14:49 · Score: 1

And if you kick a big CA like Verisign out, you'll basically break the internet since so many websites rely on certs signed by them.
Sure, it's easy to remove/revoke a root cert. It's not easy to deal with the clusterfuck of having 80% of all HTTPS websites giving an error.

--
Dilbert RSS feed
Re:Confused... by Tomato42 · 2011-09-07 22:40 · Score: 1

There are extensions to TLS that allow the server to provide the client the OCSP response that its certificate is valid. Considering that the regular OCSP response has a validity period of one to two days, even if CA OCSP server goes down, Amazon architecture stays up and remains secure. Second: CA can create multiple OCSP servers distributed over geographically diverse locations. They have the money to do that and creation of robust systems is possible: when was the last time you couldn't go to google.com while your Internet was up?

People keep forgetting that security is a process, not a service or magic pixie dust. You have to constantly update it. Yet still the there were absolutely no major changes between introduction of SSL and now, we still have CAs that provide CRL and OCSP service only on paper, browsers that don't bother checking it at all. The biggest change was phasing out of MD5 (while we shouldn't be using SHA1 now) and phasing out of SSL2 (still used by over 25% of SSL-enabled sites in the Internet).

The biggest problem is that the Joe Random doesn't even see the whole issue as a problem so the big players do absolutely nothing.

Downright scary by roman_mir · 2011-09-07 08:55 · Score: 1

When I hear that something is "Too Big To Fail", I think about 2008 but I also think about USSR. Was the entire country "Too Big To Fail"? How about USA, is it "Too Big To Fail"?

Who can prevent a country from failing?

CA is not a country, but if one CA issues a large number of certificates, then does this CA become too big to fail and do we close our eyes on the problem, which is - CA cannot be trusted?

Can a CA be trusted? Any CA at all? OK, let's turn this around and ask it differently, can a CA be shut down, as in, all certificates signed by that CA revoked and what is the moral hazard of NOT shutting down a CA if one is shown that it cannot be trusted?

Compare this question to the question of moral hazard in the financial industry: how much better is the health of economy now, that financial industry players were deemed "Too Big To Fail" and they were bailed out and stimulated?

Is it better now? Does anybody believe that the economy is better now, that those corporations were not allowed to go bankrupt, as the market required, debts liquidated, assets sold off to pay off some debts in order of priority?

I know the argument that is going to be brought up: counterparties are put at risk. Yes, other banks are put at risk and they will also go bankrupt and shut down and will have to be liquidated, because they assumed risk that was hedged by the counterparties, which are going down.

Same with the CAs, if you shut down the ones that are failing, then what about all the sites out there, whose certificates will stop working? It's not just B2P sites, it's all sorts of certificates that are used in B2B commerce systems, etc.

AFAIC there is no such thing: "Too Big To Fail". You let them fail, you always let them fail. Certificates must be recreated, it will cost businesses something, but it will make them choose their CAs (or whatever other means of doing business), this will increase competition, new ideas will be thrown around, likely many will go with self signed certificates (well many do, I know for a fact that many businesses do use self signed certificates for inter-business stuff).

If you think preventing something that is "Too Big To Fail" from failing with SOLVE the problem, look at the economy today, look at who was bailed out and think again.

--
You can't handle the truth.

Re:Downright scary by UnknownSoldier · 2011-09-07 10:30 · Score: 1

> I think about 2008 but I also think about USSR. Was the entire country "Too Big To Fail"? How about USA, is it "Too Big To Fail"?
> Who can prevent a country from failing?
Agreed, but I think about the $700 billion bailout to the banks.
Repeating what I posted in a different thread...
"too big to fail" = "the general population gets fucked with the bill !"
True Story: Forest Ranges used to be anal about stopping _every_ forest fire. They eventually learnt that this makes the situation _worse_ in the _long_ run because all the decay that _would_ of been cleared when a big fire hits, is still there. By letting "smalls" fire occasionally go through, it lessens the impact of the bigger ones.
See: http://en.wikipedia.org/wiki/Controlled_burn
What is interesting is that the Talmud mentions about all debts being released every 50 years. It looks like some Jewish wisemen already saw the problems of usary over 3,000 years ago ...
People (and by proxy Government) learn the _most_ from failure.
_Every_ government has collapsed. It is not just a matter of IF, but WHEN. Propping up entities artificially doesn't change that fact, and takes away the learning opportunity of "WHAT NOT TO DO"
Re:Downright scary by roman_mir · 2011-09-07 10:49 · Score: 2

I am familiar with the forest fires coming back with vengeance after a while, it's a true problem that people create.
The prohibition of usury is more about unreasonably high rates charged for loans, but the religions are wrong. There should be a way to charge any amount of interest, but of-course the risk that comes with this is such that you should know, that many of the loans you make won't be returned. Some will be returned within a small amount of time, so even though the interest is very high, the absolute interest paid in money is really not that bad considering that the person really needed the money and couldn't get it from a different lender (maybe it was a very very risky thing he wanted to do, the collateral was non-existent, but the pay out was huge, so it makes sense to gamble), it is gambling - giving loans to people.
The problem with banks in the current financial market is the moral hazard provided by government, which guarantees depositors will be reimbursed, so bank depositors don't care to find out anything about the bank, they don't look at the business practice of the bank. Imagine that - they are loaning money to the bank (that's what a deposit is), but they don't check on what the bank is doing with the money. They don't care if the bank has private insurance and what the reserves are - government is going to take care of it.
Well CAs being 'Too Big To Fail' is exactly like that. Somebody is going to cover their problems, so why should we care about who we are using with part of our security procedure, an important, user facing part? Never mind, just do what everybody does.
--
Here is a good idea: whenever you find yourself in a situation, that the majority is agreeing with you, you need to reevaluate your own assertions and views, because it's likely you are on the wrong path as part of the herd.

--
You can't handle the truth.

Anything 'too big to fail' by unity100 · 2011-09-07 08:59 · Score: 1

should be nationalized. because if they are as big like that, it means they become infrastructures of strategic kind, which you cannot just let private interests control.

anyone arguing otherwise has to justify not privatizing the army first.

--
Read radical news here

Re:Anything 'too big to fail' by roman_mir · 2011-09-07 09:06 · Score: 1

Right, this means all of the "Too Big To Fail" become shared ownership, and because their ways do not change, but their ability to hurt the economy/society grows, as they are now part of government system, they are going to get ever bigger. When all the things converge the government then becomes "Too Big To Fail" and because of all the misallocations and malinvestnments and resource misallignments based on the "Too Big To Fail" that are owned by the government, the government now is collapsing and there is nobody there who can bail out the government.
As to privatizing the army - the government already did that, what's Blackwater, so it failed in that respect.
The question is: how much can you put upon the government to do, before it becomes too big to fail, but then fails eventually anyway, taking down the economy with it?

--
You can't handle the truth.
Re:Anything 'too big to fail' by vlm · 2011-09-07 09:46 · Score: 1

should be nationalized.

OK for "national strategic resources". I don't necessarily agree, but I mean OK as in I understand your idea. So what do you do with "inter-national strategic resources" like the corrupt world banking system, or corrupt CAs? "inter-nationalize" them? What would that even mean? The UN owns them? The UN is just a gang of thugs, literally. The IETF? The NANOG emailing list and its cabal?

--
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Re:Anything 'too big to fail' by 0123456 · 2011-09-07 10:20 · Score: 2

should be nationalized.
Government-run CAs are the only ones you can absolutely guarantee will be used to issue fake certiifcates at some point.
Re:Anything 'too big to fail' by nedlohs · 2011-09-07 10:21 · Score: 1

Surely anyone arguing otherwise would have to justify privitizing the army?
At least in your strange "the only reason for nationalized things is because they are too big too fail" world.

Re:No... by Tasha26 · 2011-09-07 09:19 · Score: 1

I thought CAs were a regulated business, just like financial, accounting or law firms, i.e. you have a duty of care, doing your job properly? If not, I foresee lawsuits...

Re:No... by moortak · 2011-09-07 09:21 · Score: 1

Do you have a better, scalable solution that doesn't suffer the same or greater weaknesses? The problems of CAs remind me of the issues with spam. Everyone agrees the system we have is broken and no one has a better solution.

--
Xavier Rabourdin for president 2012

Re:No... by lgarner · 2011-09-07 09:32 · Score: 1

I'm pretty sure they're not. Anyone can be a CA. The only thing necessary to be a "real" CA is to have your cert installed by default in the major browsers. They (Opera, Microsoft, Mozilla, Google) decide who's a "real" CA or not. In other words, it's just about trust. Your browser trusts Thawte, Verisign, and a ton of others by default. If you install my personal root CA in your browser, then for you I'll be just as "real" as the others.

Re:No... by houstonbofh · 2011-09-07 09:37 · Score: 1

Before you respond to an obvious troll, look at the profile. I only found one post of his not modded -1, and it was 0. Ignore them, and they soon get modded to oblivion. Respond, and he will respond back and have faff material for days.

Re:No... by vlm · 2011-09-07 09:42 · Score: 1

Like my disclaimer says

I suppose it depends on the country

but in the USA its completely unregulated, at least WRT "being a CA".

As I said, I am my own CA ... If I issued some certs to you, either barter or for cash, then I'd have all the usual financial / tax / zoning / liability laws that any business follows or pays money to get out of following, but absolutely no laws are specifically CA related.

Its easy to govt license physical things like nuclear material or firearm receivers, but I think you'd find govt licensing of openssl software to be a bit problematic.

If you don't believe me, try to disprove me by setting up the software, and being unable to issue certs without some sort of govt license...

Its like talking to people who thought you needed a license to install a webserver... Stockholm syndrome that us little people could not possibly be permitted to have that power, so it must be illegal or something, etc.

--
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger

Re:No... by houstonbofh · 2011-09-07 09:46 · Score: 1

Actually, yes. http://convergence.io/ However, it also is not perfect, just better. Just catching that troll behind you there...

Re:No... by Bucky24 · 2011-09-07 10:10 · Score: 1

southerner based pseudonym

Well at least the troll is semi-creative. I especially like the cowering in the shadow parts. If you're a troll, generally you don't come in the light much, and you don't HAVE a shadow for anyone to cower in. So.... What you request is impossible. Sorry.

your chosen fatherless southerner based pseudonym

The pseudonym is fatherless? Well, yes, in fact pseudonyms are spawned from the fertile imaginations of the users who cower behind them, and in fact have neither mothers or fathers.

Yes, yes, I know, cower in your shadow behind my pseudonym.

--
All the world's a CPU, and all the men and women merely AI agents

Alternative improvement idea by vadim_t · 2011-09-07 10:14 · Score: 4, Interesting

So I've seen quite a few people wanting a switch to self-signed certs (who IMO mostly don't understand what making that secure actually involves), and an idea to check certs from different network paths (which doesn't work if your only path is compromised, and how do you secure the communication to the service that does the check for you?).

So here's an alternative idea: Require multiple CAs.

Instead of doing it the "extended validation" way which is more money for not a whole lot more service from the same provider, it'd be much better to have multiple CA signatures on a single cert.

Compromising multiple CAs in the same timeframe to create a cert would be considerably harder than creating one. More importantly, it'd make revoking large CAs much easier.

Let's say that the new norm is to have a site's cert is signed by 5 different CAs, and that the minimum acceptable amount is 3 signatures.

Then, if Verisign gets compromised there's no problem with pulling their cert: you're down to 4 valid signatures on your certificate, which is still fine. That should put considerably more pressure on CAs to perform better.

Even Verisign wouldn't be able to trust that their security problems would be let go due to their popularity, as even the largest CAs would be completely expendable without the end users needing to care much. The site would just go with a different 5th CA to return back to the full strength.

Re:Alternative improvement idea by ftobin · 2011-09-07 11:57 · Score: 1

That's a fairly novel idea that would provide pretty good privacy.
Re:Alternative improvement idea by ewanm89 · 2011-09-07 12:41 · Score: 1

Multiple path is done over SSL with certs to match against pinned in the browser. This is more a trust on first use, as is an exception for self signed. The only possible compromise time with this is that first connection to the notary (server for doing validation) or the self signed server.
Re:Alternative improvement idea by flonker · 2011-09-07 13:10 · Score: 1

He also claims to 0wn four more 'high-profile' CAs
http://it.slashdot.org/story/11/09/06/1245214/Possible-Diginotar-Hacker-Comes-Forward
Re:Alternative improvement idea by AxeMurder · 2011-09-07 15:36 · Score: 1

So instead of shaking down small business for $50 (or $500 or whatever) for a cert we now shake them down for 5 times that instead? If the CA aren't doing their jobs I'm pretty sure we shouldn't reward them by require requiring companies to hire them five times instead of just once.
Re:Alternative improvement idea by OneMadMuppet · 2011-09-07 17:27 · Score: 1

PGP style signing of certs. From the point of view of the customer, the SSL cert says it's been signed by 3 CA's I've never heard of, plus my IT department who seem to have some idea, plus my wizzkid brother in law who has OCD who I completely trust. My brother in law also trusts one of the CA's, but not the other 2. A score gets automagically generated, plus the details if I want them. If the CA screws up, my brother in law revokes his signature.
Re:Alternative improvement idea by pthreadunixman · 2011-09-07 19:09 · Score: 1

I don't see how multiple signers does anything to prevent any of the 100 or more commercial CAs from issuing a certificate for any random host on the internet --which is the problem at hand here.
Re:Alternative improvement idea by vadim_t · 2011-09-07 19:21 · Score: 1

First, my idea is that it'd need to happen with 3 of them, which makes it more difficult than with just one.
Second, by requiring multiple signatures and adding a safety margin, any CA's signature becomes expendable. Right now gmail.com is signed by Thawte. Which browser vendor would dare pull Thawte's cert? Very few probably. Now what if gmail.com was signed by Thawte and 4 other providers? Then you could remove Thawte's cert, and nobody would notice anything, because it's still signed by >= 3 valid CAs.
The idea of that is to put more pressure on CAs and make it so that there simply can't be such a thing as a CA that's too big and important to be removed from the trusted CAs list.
Re:Alternative improvement idea by vadim_t · 2011-09-07 19:34 · Score: 1

That would be possible under a system like that, but I think the current system of trusted by default CAs ought to remain. 99% of people simply aren't going to take time to understand how a PGP style works. I'd know, I explaned PGP to several people and it takes a quite long time to do properly.
Besides, just what does your brother in law trusting a CA means? He thinks they're really professional? They are cheap and have nice customer service? But none of that has anything to do with their security and internal practices. Unless it's say, his company's CA and he personally knows that his company's security is well managed, it's pretty much impossible for a normal person to have a meaningful trust in a CA like that.
Re:Alternative improvement idea by Lennie · 2011-09-08 00:53 · Score: 1

I was thinking the same thing.

--
New things are always on the horizon
Re:Alternative improvement idea by owlstead · 2011-09-08 11:22 · Score: 1

It's an interesting idea, but besides the administrational monster that it would create, there is the problem of e.g. validity periods and other certificate fields. It would be pretty interesting to see how to get the main CA's working together on deciding to put what in the certificate. And what happens if decides that the key has been compromised, and the others don't really see it that way? Who's CRL are you going to trust? Three out of five again? Or would you have a "parent CA" that is trusted for all of that?
Putting extra signatures under the cert is not really an issue, but I can see a lot of snags already - and I' ve only just started thinking about it.

Dedicated certificate revocation servers? by drig · 2011-09-07 10:15 · Score: 1

Why doesn't each browser's company put up a certificate revocation server? Then, they can revoke individual certs, including those of the certificate authority, and control the length of the revocation, re-authorization, etc.

--
Citizens Against Plate Tectonics

Re:No... by sjames · 2011-09-07 10:59 · Score: 1

All it takes is to convince someone to put your cert in the list of roots. That someone can be a distro maintainer, browser maintainer, or individuals. The more, the better. In the practical sense, if you can convince MS, Google, and Mozilla to include your cert, you are now a CA.

Already has happened by ewanm89 · 2011-09-07 12:36 · Score: 1

I point out that Comodo are compromised twice recently, and not revoked by any browser. As Moxie pointed out in his blackhat talk.

Re:same story as always with computer security... by ewanm89 · 2011-09-07 13:08 · Score: 1

Or they don't even care to listen. Oh, and one CA is compromised then all HTTPS sites are compromised, not just those the CA is payed to sign, I'll let you ponder that one.

Re:No... by Rich0 · 2011-09-07 14:30 · Score: 2

Yes - DNSSEC.

Right now if you lookup bank.com in DNS you get a bunch of records that are maintained by Verisign. With DNSSEC those records will be signed by Verisign so that you can be sure they aren't tampered with.

There is no reason that one of those records can't be an SSL certificate. There is also no reason that one of those records can't be an indicator of how much verification Verisign performed.

For 99% of intended uses just verifying that the domain owner uploaded the certificate should be adequate. Unless you actually read the certificates for the sites you browse you aren't getting more than that today anyway.

If verisign tries to charge to include certs it is a non-issue - just run the site off of a subdomain and then you can put the certs on your own DNS server. You still have a signed chain of trust protecting the DNS records due to DNSSEC so it is just as secure.

DNS is already scalable to the entire internet, and is designed to handle distributing arbitrary host records. SSL would only fail if DNS fails, and if DNS fails you're not going to be connecting to the server anyway.

Well by xenobyte · 2011-09-07 20:04 · Score: 1

One thing is that I would love a costless distributed solution like the one Marlinspike suggests. I'd much rather trust a large group of peers than a company whose security practices may be questionable. Sure, the peers might be much less secure individually but as a group it's extremely hard to force something onto everybody thus causing manipulative results. If the network both rates the certificates and each other, it's next to impossible to introduce corruption on a level that matters.

Now, given what we have today, the solution is easy:

Regardless of importance - any CA caught being the source of fraudulent certs should be immediately blacklisted so that all certs issued by this CA are rendered useless. It should not even be possible to accept the risk and visits sites using certs from this CA. This will in turn result in massive lawsuits against the CA (just imagine the loss from a company like Amazon being unable to process payments) and thus most likely the complete financial destruction of the CA. The mere prospect of this should make the CA's take their security seriously. I mean if a semi-talented wannabe like this Comodo-hacker can cause this much damage, and perhaps even have gained access to several CA's, their security must be next to non-existent, and that is more than unacceptable.

--
"For every complex problem, there is a solution that is simple, neat, and wrong." -- H.L. Mencken (1880-1956) --

Re:Well by Tomato42 · 2011-09-07 22:44 · Score: 1

The current CA woes show that probably the CAs weren't attacked because the script-kiddies and "real crackers" thought of them as ivory towers, completely impenetrable.

In the coming months we can be fairly certain that more and more CAs will fall victim to attacks, just like Sony.

another approatch... by fredan · 2011-09-07 20:18 · Score: 1

What if you publish your own CA with the domain name in the DNS?

You first make an CA and publish your public key as an TXT (or something similar) field to your root domain (name.tld) and using dnssec to make sure it's correct. You can now use that CA to make certs of all the names that you want within your own domain.

If someone tries to make an CA of your name and try to intercept the dns traffic to change the public key, the dnssec would fail and in that case and the CA is invalid?

Re:another approatch... by Tomato42 · 2011-09-07 22:48 · Score: 1

It's a good scheme as long as you can trust your registrar and your country government. For small business and private sites it's a solution good enough in a road to phase out unsecured HTTP. Not a solution if you want/need real security.

Perspectives by thegarbz · 2011-09-07 21:13 · Score: 1

So here's an alternative idea: Require multiple CAs.

Instead of doing it the "extended validation" way which is more money for not a whole lot more service from the same provider, it'd be much better to have multiple CA signatures on a single cert.

What you are proposing is roughly what the Perspectives project has implemented.

Re:Perspectives by vadim_t · 2011-09-07 21:47 · Score: 1

Not at all. My idea has absolutely nothing to do with what this project.
My idea requires: Certificates to support multiple CA signatures, and for a browser to require multiple valid CA signatures on a cert. Other than that it fits perfectly well in the current scheme. You'd still get your cert signed by companies like Verisign and Thawte, and their certs would still come by default with the browser.
Re:Perspectives by vadim_t · 2011-09-07 22:27 · Score: 1

I found this, which mirrors my idea.
I also looked at Perspectives.
IMO, it's quite silly.
First, the idea of it is to replace CAs with... a CA. It does exactly what any other CA does, except it implements a different policy. Instead of "we certify that bobsmith.com belongs to somebody named Bob Smith", or "the person who requested this cert proved they control http://bobsmith.com/", it's "we certify that this cert looks the same from everywhere".
It is just as hackable as any other CA, though I guess it does have the slight advantage of the attacker to modify their servers and keep the intrusion active, instead of breaking in, making a few certs, removing traces and disappearing.
If you use it in addition to the current system it's just a CA more. If you only use that you're using an unique CA provider, which is just like only trusting Verisign. It's got less points of failure, but if it does fail you don't have anything else to fallback on.
Also imagine somebody takes the code and runs their own. And then we're back to the current system of multiple CAs, the compromise any of which can break the entire system.
Implementation-wise it seems to have downsides. For instance it requires a connection to their servers, which is trivially blocked, while SSL works fine with having just a connection to the server you're connecting to.
It also requires active scanning, which means that you can't renew a cert transparently: either there is a time window during which a different cert goes unnoticed, or the modification immediately triggers a security warning. The later means that any cert change requires you to accept that your users will see your site as untrustworthy until the system is happy with the new cert.
Re:Perspectives by swillden · 2011-09-08 01:46 · Score: 1

It is just as hackable as any other CA, though I guess it does have the slight advantage of the attacker to modify their servers and keep the intrusion active, instead of breaking in, making a few certs, removing traces and disappearing.
I disagree.
The idea is that the client doesn't rely on just one notary, the client checks several of them, chosen at random from a large list. So the attacker has to compromise all of the notaries the client chooses to use, simultaneously, and without knowing which notaries the client might use. The attacker could block access to all of the notaries but the one he's compromised, but that's trivially defeated by configuring the client to require multiple successful validations, and to refuse to validate at all if many notaries appear to be offline.
Further, keep in mind that Marlinspike's system doesn't have to be a replacement for the existing PKI. It can stand beside it, and clients can be configured to require both systems validate a server's certificate before considering it valid. This would make the attacker's job nearly impossible.
The biggest disadvantage I can see is that having to connect to multiple notaries in order to establish an SSL connection to the server you want to get to would be slow. But it's really only necessary to do that the first time you connect to a site. After that, your browser can remember that this is the cert it's seen before for this site and simply connect without checking -- or, better yet, do the checks in a background thread after already having established the connection.

--
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Re:Perspectives by vadim_t · 2011-09-08 03:03 · Score: 1

The idea is that the client doesn't rely on just one notary, the client checks several of them, chosen at random from a large list. So the attacker has to compromise all of the notaries the client chooses to use, simultaneously, and without knowing which notaries the client might use. The attacker could block access to all of the notaries but the one he's compromised, but that's trivially defeated by configuring the client to require multiple successful validations, and to refuse to validate at all if many notaries appear to be offline.
That is a good idea.
However, by looking at the code I can see a few weaknesses:
There's a single point of failure: the notary list. If you can manage to provide your own, you're set, no matter how many notaries there are.
Fortunately, the list is signed. Less fortunately, it's vulnerable to replay attacks. One could make the job easier by saving an old list with few servers. Also all of the notaries are on the same domain which probably is not a good thing.

Further, keep in mind that Marlinspike's system doesn't have to be a replacement for the existing PKI. It can stand beside it, and clients can be configured to require both systems validate a server's certificate before considering it valid. This would make the attacker's job nearly impossible.
Now that's more along the lines of what I was saying.
However, what about false positives?
Realistically most of the time you'll be seeing false positives from Perspectives. Lots of certs only last a year, there's only 365 days in one. If you browse around enough you will see a validation errors pretty often, for every time a cert is renewed. The current gmail cert expires on 19/12/2011, will you stay away from gmail until Perspectives is happy with the new cert?
Re:Perspectives by thegarbz · 2011-09-08 19:44 · Score: 1

IMO, it's quite silly.
First, the idea of it is to replace CAs with... a CA. It does exactly what any other CA does, except it implements a different policy. Instead of "we certify that bobsmith.com belongs to somebody named Bob Smith", or "the person who requested this cert proved they control http://bobsmith.com/", it's "we certify that this cert looks the same from everywhere".
I don't think you quite understand how it solves the issue of MITM attacks. While on the face of it the idea seems silly what it does do is implement a lookup to multiple third parties and not just trust it because a single 3rd party signed it. It actually goes to third parties and says "Do you all agree this is what it looks like?"
This gets around the key issue of trust. How can you trust someone to be who they say they are vs say the Iranian government routing its way through a specific server. When we hit compromised google.com we get a result saying 99% of notaries agree with what we see. When the Iranians do the same thing they get a result saying only 1% of notaries agree which immediately points to a MITM attack even if the certificate is still valid and signed by the CA.
The CA is still hackable and can still issue a dodgy certificate, but unless you actually were physically in a position to implement your MITM attack in the final node to a site then you will get discovered. If you do have access to the last link you likely have the ability to attack the server directly anyway. If you take the bulldozer approach and just re-route the entire internet, someone will notice very quickly.
Re:Perspectives by vadim_t · 2011-09-09 00:12 · Score: 1

No, I understand it perfectly fine.
In fact after debating with people here and reading the source I'd say that I might have an use for it myself. But I just don't buy into the hype.
First of all, again, it's not a replacement for the CA system as being claimed by some people here. It's very much a CA, except one that runs a different verification policy. It keeps the weaknesses of a CA system, like a single CA being compromised being enough to break security.
Second, it's not very user friendly. Current CAs are near transparent, and still are hard enough to explain to normal people. Explaining why Perspectives is unhappy with gmail renewing their cert will be very difficult and spell doom for security. All most people will get from the explanation is "the smart computer guy says it's safe", and click "Ignore". And do the same thing when the warning comes up due to actual MITM.
Third, it doesn't perform all the duties of a CA. It'll happily declare as valid a cert for gmail.ws that says that it's been issued to Google. Sure, normal CAs are ocassionally tricked into doing that, but with Perspectives it's guaranteed.
Re:Perspectives by thegarbz · 2011-09-09 01:16 · Score: 1

Well yes the idea that it is a replacement for CAs is absurd. It's meant exclusively to compliment the existing CA relationship.
Though I am still interested in how you think a compromised CA issuing a dodgy certificate to a third party breaks the security process. The issuing of a dodgy certificate is still only part of the challenge. You still need to convince people to connect to your site, and as such when you have compromised a CA and issued yourself a dodgy certificate for google.com you need to somehow insert yourself into path between your victim and their request to go to a google server. As it would be near impossible pull off this globally the notaries will show up with different results and expose the MITM attack.
Your last example is also not likely. Perspectives doesn't take the place of a CA but only verifies already issued certificates against notaries. You'd still need a CA to issue a valid certificate to Google.ws, and perspectives neither makes this process more or less secure as this is still the job of the CA. Mind you if you can convince a user to go to gmail.ws you probably don't need a massive MITM attack, a simple email claiming "Google Accounts is currently verifying credentials, please send us your login and password" would do the trick.
I agree Perspectives has way too much hype. It's not a solution to SSL, it's merely a supplement to the existing CA system which prevents the use of a compromised certificate for a MITM attack. Not a social engineering attack from some funny other domain, but a real MITM attack which is the biggest issue facing a compromised CA.
Re:Perspectives by vadim_t · 2011-09-09 03:22 · Score: 1

Though I am still interested in how you think a compromised CA issuing a dodgy certificate to a third party breaks the security process. The issuing of a dodgy certificate is still only part of the challenge. You still need to convince people to connect to your site, and as such when you have compromised a CA and issued yourself a dodgy certificate for google.com you need to somehow insert yourself into path between your victim and their request to go to a google server. As it would be near impossible pull off this globally the notaries will show up with different results and expose the MITM attack.
The current system is "if the cert is signed by any of the 150 CAs listed in the browser", it's good. Thus it's enough to compromise one of those and start issuing certs.
Perspectives does help a bit there, but it can be compromised too. From looking at the source ideally the attacker would compromise the notary list. If they can provide their own, they can run their own notaries that say everything is valid.
MITM isn't that hard to set up, btw. A trivial way of doing it is running an open wifi AP in a well populated place and just waiting until somebody falls for it.

Your last example is also not likely. Perspectives doesn't take the place of a CA but only verifies already issued certificates against notaries. You'd still need a CA to issue a valid certificate to Google.ws, and perspectives neither makes this process more or less secure as this is still the job of the CA
Done that way, yes, it's helpful, but I see people clamouring for replacing the CA system with something like Perspectives. They say that a self-signed cert shouldn't be seen as a bad sign if validated in a Perspectives-like manner.
Re:Perspectives by swillden · 2011-09-09 04:31 · Score: 1

There's a single point of failure: the notary list. If you can manage to provide your own, you're set, no matter how many notaries there are.
That's more of an issue with the plugin than the system. The eventual idea is that notary lists would be distributed with the browser, the same way you get your CA list now.

Also all of the notaries are on the same domain
Another implementation flaw, not a design flaw. If this took off, I'd expect to see lots of major Internet companies providing notaries, scattered all over the Internet, across many domains and networks. Google alone could provide a fault-tolerant, highly-distributed notary network, and spoofing or blocking DNS service for google.com is obviously something Google takes pains to make very, very difficult.

Realistically most of the time you'll be seeing false positives from Perspectives.
No, for two reasons, one trivial, and one fairly profound:
First, well-managed sites deploy new certs before the old ones expire. If that weren't the case you'd see a lot of expired cert warnings now, because this is just as much a problem for the CA-based PKI than it could be for Perspectives.
Second, Perspectives really has no reason to care about certificate expirations. Its purpose is to verify that the cert being seen by the client is the same one being seen by the network of notaries. Period. Dates don't matter, name and domain fields don't matter, etc. Clients may want to check these anyway, just out of an abundance of caution, but, fundamentally, if every notary sees the same cert from a given site, then either (a) no MITM attack is being carried out on that site or (b) a MITM attack is being carried out on the site's sole connection to the Internet. And it's easy for sites to mitigate (b), by periodically querying the notaries themselves, asking what cert the notaries are seeing. The attacker can't alter the notary replies, so the very best he can do is to notice when the site makes a request and then cease his MITM attack until the notaries check and return the true cert... but that will cause notaries to see an "oscillating" certificate which is a clear warning sign, and in any case the site operator can completely defeat it by tunneling out or hitting the notaries from somewhere else.

--
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Re:Perspectives by thegarbz · 2011-09-10 19:11 · Score: 1

From looking at the source ideally the attacker would compromise the notary list.
The Notary list is not something that is freshly updated. The defaults are coded in at initial install. The weakest link here is they all have very common DNS addresses so compromising that may be a good first step, but each of the Notaries is also accompanied by an identifying key. Even if you could replace a Notary with your own that would require doing it for 75% of them before (as per defaults) perspectives wouldn't disagree on a certificate, AND you would need to compromise the public key system they use to verify notaries.
Actually the easiest attack would be on the source code itself but then your target pool of victims would be very small before you're discovered.
It's not a perfect system but it would put an end to the ease at which someone with a dodgy certificate could compromise a very large audience without detection.

but I see people clamouring for replacing the CA system with something like Perspectives.
Yes I think we can both agree that's absurd. I can see a perspectives type system being PART of the solution, together with something like DNSSEC or some such thing. But in the case of the existing SSL system it really does well at polishing a turd.

Re:No... by Lennie · 2011-09-08 00:15 · Score: 1

Highly profitable ? Hmm... well, there are also free certificates:

https://www.startssl.com/

Obviously you can pay for extra features, but it is still the cheapest choice for a lot of the extras.

--
New things are always on the horizon

Re:No... by Lennie · 2011-09-08 00:28 · Score: 1

If you want to be on that default list, it will cost you a lot of time (and thus money) to get started.

It is not that you have to pay a lot of money to browser vendors, it is because every browser vendor has it's own set of rules, although many are discussed and 'standardised' through the CAB-forum.

Most of the money you need to pay is for the auditing by an organisation like WebTrust or PriceWaterhouseCoopers.

The audit looks at your processes and procedures. And checks all the paperwork and that you keep paperwork on the certificates (and types) you grant and revoke.

The audit checks if you pass all the requirements, after that you probably get on the list.

At least that is what I understand from it, after looking into the CACert project.

I hope they add a requirement that the CAs which allow for online automated requests need to have their technical infrastructure audited regularly too, with penetration testing and so on.

--
New things are always on the horizon

Re:No... by MSG · 2011-09-09 04:42 · Score: 1

DNSSEC is only secure if the CAs that sign it are also secure. If the problem is the security of the CAs, then their subordinate security infrastructure (DNSSEC) cannot be the answer.

Re:No... by Rich0 · 2011-09-09 08:18 · Score: 1

I'm not convinced of that.

Registrars already do a reasonably good job of controlling ownership of domains. I haven't really seen any cases where a registrar transferred ownership of a domain of importance (like Google/etc) to a random 3rd party unless they allowed the registration to lapse. Sure, you can register google.zz where zz is some obscure country code, but that really isn't the same thing. DNSSEC will protect against DNS spoofing, which is a much more common attack vector.

I would think that most CAs are only going to verify the CN to the extent that they ensure that you control it, which is what DNSSEC does anyway. Anything stored in any field other than the CN in a certificate is worthless 99% of the time since the browser can only check the CN and nobody reads the rest of the certificate.

So, what DNSSEC ensures is that when you type google.com into your browser, you get the site hosted by google.com. It doesn't guarantee that you get the site run by Google, and neither does the present CA system. (If Google's domain expired I should be able to register it and get a certificate legitimately for John Smith, CN=google.com which works just fine in any browser.)

DNS is also much more heirarchical. You have one administrator for a domain who is responsible for running it correctly. With CAs there is no scope limit on trust - so some obscure CA in Singapore can issue microsoft.com certificates. With DNSSEC only Verisign can issue a microsoft.com certificate, and if they botch the job they can lose their contract.

Slashdot Mirror

Are Some CAs Too Big To Fail?

133 of 163 comments (clear)