Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The SSL Co-operative: A Member-Controlled Certification Authority

sslcoop.org

Post reply on HN
Print view View original

81–90 of 90 posts

Re: The SSL Co-operative: A Member-Controlled Certification Authority

#81

Post by leccine »

MichaelGG wrote: post #72
leccine wrote: post #58

Earlier quoted context omitted.

2 ways, A, creating rogue cert by md5 collisions (they have the capacity) B, making people believe that a CA guarantees the identity of the issuer, while having their CA in the approved list so they can sign certs (for example like gmail.com) There is good documentation about it: http://files.cloudprivacy.net/ssl-mitm.pdf

Except if the NSA did sign Gmail in any non-trivial capacity, it'd certainly be noticed and the offending CA would be removed or put out of business or something like that. Plus it'd draw lots of attention to the NSA directly. If they did want to sign something publicly, they'd just compromise some third-world CA and have them take the blame. There's plenty of them in there. Or they could just sign up as a Comodo res…

I think you are missing the point. NSA signs any cert to make it valid for any service. I think you should read that white paper i linked above.

Re: The SSL Co-operative: A Member-Controlled Certification Authority

#82

Post by womble »

IgorPartola wrote: post #57

What would make sense to me more than an SSL co-op would actually be a registrar that gives you a free wildcard certificate for every domain you register. You almost always need a certificate for every domain you use, so why not bundle the two? I wonder if doing a crowdsourced bootstrap of such a registrar would work.

I'm not averse to that idea, in principle. Heck, that sounds like a nice complementary business idea -- you run a DNS registrar that offers a free domain-validated wildcard certificate with every domain sold, and get your certs from the co-op. The costs would be minimal -- there's bugger-all required to start a domain name reselling business, and SSL co-op membership is shaping up to be more on the "consumer" end, rather than "retailer" cost structure, so there wouldn't be significant costs there, either. I don't think it would need crowdsourced funding to get started, honestly.

The game-changing of the SSL co-op has already started! New business models are taking shape! (grin)

Re: The SSL Co-operative: A Member-Controlled Certification Authority

#83

Post by womble »

daveloyall wrote: post #66
womble wrote: post #37

Earlier quoted context omitted.

(I'm the sslcoop.org guy) Yeah, well, I haven't worked out how to tell nginx to look at the SNI for a HTTPS request and bomb out completely if it doesn't match any SSL-enabled vhost. Unless you've got pervasive IPv6 -- then I can set everything up so manually mangling URLs to use HTTPS doesn't cause problems (there's no links to HTTPS resources on sslcoop.org)... Turns out the real scarce resource is IPv4 addresses -…

Womble, I like your idea and I wish you success. But, it is now constructive feedback time. :) meowtaxi is sooo right! Seriously, I was going to post the same thing. Sure, I expected an SSL error when I manually switched to the https version of your url, but the specific SSL error I ended up getting reflects really, really poorly on an organization that aims to become a CA. I did check your FAQ first for some mention…

I'm a little surprised that so many people deliberately mangle URLs to see if there's anything listening on :443, myself. I might just pull SSL off the other domain on IPv4, and put it on a separate IPv6 address...

Re: The SSL Co-operative: A Member-Controlled Certification Authority

#84

Post by womble »

michaelbuckbee wrote: post #61
ademarre wrote: post #31

Earlier quoted context omitted.

Interesting. Perhaps an alternative to the keyword warning system you describe (for SSL certs only) could be to scan the candidate CN for existing SSL certs. If any are found, flag it for manual review, or possibly come up with a proof system whereby the applicant proves he is the holder of the former certificate.

The problem is that phishers register sound alike domains like info-secure-apple.com or atlanta-usbank.com, that were completely clean prior to issuance.

Anything that includes a trademark (like info-secure-apple.com) or "risky" term (like atlanta-usbank.com) typically ends up getting manually verified, even for domain-validated certs. Not saying that plenty of dodgy stuff doesn't slip through the cracks, but it isn't quite a wild-west free-for-all...

Re: The SSL Co-operative: A Member-Controlled Certification Authority

#85

Post by womble »

eximius wrote: post #69

I will gladly run a member organization to lower the barrier of entry to end-users and non-businesses. No one should have to sacrifice security because they don't want to fork over that kind of cash. I run a forum I want Wildcard SSL on but I don't want to buy one since I currently spend no more than $30/year to host it. The Wildcard SSL Cert alone would cost double that at some of the cheapest places. If I can fix m…

"No one should have to sacrifice security because they don't want to fork over that sort of cash"

It's a bit long to be the SSL co-op's tagline, but as a motto, you've pretty much hit the nail exactly on the head.

Re: The SSL Co-operative: A Member-Controlled Certification Authority

#86

Post by womble »

darrenkopp wrote: post #53

I'm failing to see how this differs from http://www.cacert.org/ , though perhaps this would be more strict on participation?

(disclosure: I'm the SSL co-op guy)

CAcert's goal is to issue certificates for free, by implementing an alternate identity validation model. The SSL co-op's goal is to issue a subset of certificates for free, by having those who take advantage of that service share in the costs of running the infrastructure required to do so.

CAcert's determination to stick to its guns on doing everything "on the cheap" is admirable, and I'd quite honestly much prefer it if they succeeded (it'd be a lot less work for me, for one thing). However, looking at the browser inclusion landscape as it currently exists, I have doubts that CAcert has much hope of ever being widely accepted in the browsers. Worse, you can only change the rules about inclusion if you're already in the club... it's a nasty chicken-and-egg problem.

Re: The SSL Co-operative: A Member-Controlled Certification Authority

#87

Post by womble »

TsukasaUjiie wrote: post #74
womble wrote: post #36

Earlier quoted context omitted.

(I'm the sslcoop.org guy) "If all the money we spent on ssl certificates..." And thus was sslcoop.org born! I'm not sure what you mean by "opensource PKI infrastructure", exactly, but as a long time F/OSS hacker, I'm definitely planning on putting everything that's developed for the SSL co-op under an open licence. But the software's the easy bit. The hard part is the work required to define processes and policies, g…

iirc the WebTrust Audit required for such a system is in the ~$100,000 range. Why abandon existing initiatives to start another undermanned community based authority. I think the focus should really be in jumpstarting CACert (overhauling its governance model) and building on its existing infrastructure and user/assurer base (As an assurer I'm probably biased here). Of course this would be hard work and less self fulf…

(disclosure: I'm the SSL co-op guy)

Organisations aren't code, so trying to make analogies to "forking" CAcert isn't something that stands up to scrutiny.

Yes, audits for WebTrust compliance are quite expensive -- $100k is within the range I've been quoted. However, CAcert has never (to my knowledge) even attempted to engage in one of those audits, and my understanding is that CAcert is attempting to create a system whereby they can operate without requiring a WebTrust audit -- so it's hardly reasonable to bring up the cost of an audit that's never been done, and will never be done.

It would be extremely hubristic of me to try and "take over" CAcert with the intention of trying to get it well-trusted by browsers. Either the organisation as it currently stands doesn't want to be in the trust stores (in which case, I'd essentially be destroying the organisation as it currently exists in order to make a new one from its ashes) or the organisation does want it, but the people currently working on the problem haven't worked out how, within the constraints the organisation has willingly placed on itself -- in which case, why do you think I'm that much smarter than the collective wisdom and experience of everyone, past and present, who has been involved with CAcert? Why would I have the silver bullet to work out how to satisfy the inclusion criteria of the browsers, within the boundaries the organisation has chosen to operate within?

My reasons for investigating the SSL co-op model have nothing to do with CAcert's governance -- from the outside, CAcert appears to be quite reasonably governed. They're to do with the feasibility of becoming a widely-trusted (by browsers, etc) root CA, given the current operational model. Given that I think the operational model needs to be completely different, the value of the existing infrastructure and user/assurer base to a root CA with a completely different operational model is, to be blunt, zero.

The SSL co-op will also explicitly not be an "undermanned community based authority". It will be operated on a solid commercial basis (please bear in mind that "commercial" does not equal "for profit"), and its budget will include funds to pay for staff to operate the CA and all the associated bumf. If the co-op cannot be run on a commercial basis, it will not be run, at least with my involvement.

And finally, I don't want CAcert to go away. I feel there is a strong need for more diversity in how CAs are operated, and the SSL co-op is merely the first step in that direction. I'd like to leverage the co-op's success to make it easier for alternatives like CAcert to be a part of the "in crowd" in the future.

Re: The SSL Co-operative: A Member-Controlled Certification Authority

#88

Post by dspillett »

Someone1234 wrote: post #64
dspillett wrote: post #47

Earlier quoted context omitted.

> So you get unlimited free non-wildcard certificates Do note the "no commercial use" clause on the free certificates. Not an issue for any of my uses but it may affect quite a few people. Though I'm not sure how they would enforce this. Of course if you can't afford $60 for two years for the next grade up, then your commercial venture is probably not a roaring success!

> Though I'm not sure how they would enforce this. Revoke the certificate.

But how do they detect that enforcement is even necessary?

(other than regular whois lookups assuming that data is correct (probably too much hassle), checking the sites secured by the certificates (even more hassle), or someone "dobbing you in")

Re: The SSL Co-operative: A Member-Controlled Certification Authority

#89

Post by michaelbuckbee »

womble wrote: post #84
michaelbuckbee wrote: post #61

Earlier quoted context omitted.

The problem is that phishers register sound alike domains like info-secure-apple.com or atlanta-usbank.com, that were completely clean prior to issuance.

Anything that includes a trademark (like info-secure- apple .com) or "risky" term (like atlanta-usbank.com) typically ends up getting manually verified, even for domain-validated certs. Not saying that plenty of dodgy stuff doesn't slip through the cracks, but it isn't quite a wild-west free-for-all...

Quite old now, but this was actually my point. That there is NOT really a level of validation that is/can be wholly automated and to try and develop a co-op or service with that assumption is bound for trouble.

Re: The SSL Co-operative: A Member-Controlled Certification Authority

#90

Post by womble »

michaelbuckbee wrote: post #89
womble wrote: post #84

Earlier quoted context omitted.

Anything that includes a trademark (like info-secure- apple .com) or "risky" term (like atlanta-usbank.com) typically ends up getting manually verified, even for domain-validated certs. Not saying that plenty of dodgy stuff doesn't slip through the cracks, but it isn't quite a wild-west free-for-all...

Quite old now, but this was actually my point. That there is NOT really a level of validation that is/can be wholly automated and to try and develop a co-op or service with that assumption is bound for trouble.

I'm not developing the co-op based on the assumption that domain validation can be wholly automated -- but it can be automated for the 99+% of domains that don't try to phish people. I'd say the degree of phishing certificate requests made via the co-op will be lower than the "general population", simply because only members can request certificates. That isn't to say that the CA's policies will be any less stringent because of that, but I don't expect to be spending all of my day clicking "reject" on shady CSRs.
Post reply on HN