The SSL Co-operative: A Member-Controlled Certification Authority(sslcoop.org)
sslcoop.org
The SSL Co-operative: A Member-Controlled Certification Authority
http://www.sslcoop.org/
12 comments
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...
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.
One could argue that should be okay for a class of certificate without identity/organization verification.
Actually, yeah, they should. Info Secure Apple. Make a comment forum about fruit-borne illness. Why should that be denied because there are companies using one of those words?
What we "need" more of is EV-style validation, so I can see that the site I'm on is an actual company registered in whichever territory. Otherwise all it indicates is that an email address with the associated domain is linked to the private key for this site. Not really what most people are looking for.
What we "need" more of is EV-style validation, so I can see that the site I'm on is an actual company registered in whichever territory. Otherwise all it indicates is that an email address with the associated domain is linked to the private key for this site. Not really what most people are looking for.
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 my problem and others, count me in.
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 my problem and others, count me in.
"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.
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.
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)
The game-changing of the SSL co-op has already started! New business models are taking shape! (grin)
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.
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.
Well, currently CACert certs are not accepted by any major browsers, so while it's a great idea, without funding it's dead in the water.
I'll say the same thing here that I said in a response to the survey: I'd be interested in taking part in a CA co-op that seeks membership/sponsorship to cover its infrastructure costs (including the huge initial cost of becoming an accepted CA), but that does not charge to issue certificates, including wildcard certificates.
Certificates cost approximately nothing to issue, and most of the CA's infrastructure would not need significant scaling with the issuance of more certificates.
Manual validation of human/organization identities (the type that requires reading identity documents, such as for EV) costs money, and that could have associated fees, but it doesn't need to occur on a per-certificate basis. And automatable validation costs nothing.
In particular, wildcard certificates don't need to cost any more than standard certificates, and no-cost wildcard certificates would change the SSL landscape significantly. Today, any service that uses subdomains incurs significant fees to secure those subdomains.
Certificates cost approximately nothing to issue, and most of the CA's infrastructure would not need significant scaling with the issuance of more certificates.
Manual validation of human/organization identities (the type that requires reading identity documents, such as for EV) costs money, and that could have associated fees, but it doesn't need to occur on a per-certificate basis. And automatable validation costs nothing.
In particular, wildcard certificates don't need to cost any more than standard certificates, and no-cost wildcard certificates would change the SSL landscape significantly. Today, any service that uses subdomains incurs significant fees to secure those subdomains.
StartSSL/Startcom already does not charge for individual (wildcard) certificates, you can request unlimited numbers.
You do pay a $60 fee for identity validation, which is valid for 2 years. You can also have automated validation, but they don't allow wildcard certificates (which I sort-of understand, they do need to make money some way right)
So you get unlimited free non-wildcard certificates or unlimited wildcard certificates for $30/year. Not a bad deal.
You do pay a $60 fee for identity validation, which is valid for 2 years. You can also have automated validation, but they don't allow wildcard certificates (which I sort-of understand, they do need to make money some way right)
So you get unlimited free non-wildcard certificates or unlimited wildcard certificates for $30/year. Not a bad deal.
> 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!
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.
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")
(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")
Apparently StartSSL does charge you quite a bit to revoke a free certificate. That bit a lot of people when Heartbleed happened. See https://www.startssl.com/?app=37.
That's partly because of how the revocation infrastructure operates. It definitely adds cost, including generating CRL, trimming the CRL as certificates expire (could be 10 years into the future), and running the revocation server itself.
Let's not pretend it's anything more than profit. Adding a fingerprint to the end of a CRL file is a completely automated process which does not place significant strain on infrastructure.
I'd imagine the file gets large after a while, but we've had ways to ease distribution of large files for quite some time..
Nevermind the fact that CRLs are of dubious value, anyways. See: http://people.csail.mit.edu/rivest/pubs/Riv98b.pdf
I'd imagine the file gets large after a while, but we've had ways to ease distribution of large files for quite some time..
Nevermind the fact that CRLs are of dubious value, anyways. See: http://people.csail.mit.edu/rivest/pubs/Riv98b.pdf
In another thread it was explained that they charge for revocation because their current software doesn't automate it. It sounded like a limitation in their stack and the fee is a workaround.
Pretty much what I was thinking. Here's what I almost sent as a response to the survey:
This is a brilliant idea. I would pay up to $50 a year for the pleasure of being able to get domain validated SSL certs that are trusted by the major browsers. I would assume that the validation would be via emailing webmaster@domain and making them either respond or click a link or something. That could all be automated couldn't it.
Also, make wildcard certificates for domains available for the same low price, because it shouldn't take any more work should it. If I control example.org, then I think it's obvious that I control www.example.org and slighly-biased.example.org.
But then you have the issue of, if Org A controls com.au, that doesn't mean they control mywebsite.com.au. I don't know how you would automate that issue.
The non-automated stuff, make people pay for it. Seriously.
Also, make wildcard certificates for domains available for the same low price, because it shouldn't take any more work should it. If I control example.org, then I think it's obvious that I control www.example.org and slighly-biased.example.org.
But then you have the issue of, if Org A controls com.au, that doesn't mean they control mywebsite.com.au. I don't know how you would automate that issue.
The non-automated stuff, make people pay for it. Seriously.
Mozilla created https://publicsuffix.org/ - perhaps that could help with com.au vs. example.com.au?
That's brilliant. I was wondering if there was a list that actually provided the relevant information. Thanks for the link.
Well, one way to automatedly ensure someone controls all the subdomains a wildcard certificate gives would be to ask them to create dns records indicating that. Basically, the CA could say "you want *.example.com, then create a dns txt record at mzzafr2pr.example.com with the following text: F5cbUl7pL2JM7z and click here. We'll get back to you once we see the dns change propagate". If I can create a random subdomain they suggest within a wildcard range, that makes it almost certain I can create every subdomain.
This breaks for obvious cases such as mzzafr2pr.blogspot.com
Not really, as while you can make the domain exist you can't make the TXT record appear in DNS.
You both have to prove that you own the ability to create dns (with blogspot sorta) and the actual content. The CA provider both lists the record name and value.
You do have a good point though. I'm sure there are some services right now that allow decent control of a chosen subdomain's dns, but don't mean for you to be able to create ssl certs valid for all other subdomains too. Perhaps there should be a blacklist of sites like "blogspot". Perhaps there should be a way for a domain to indicate that wildcard certs cannot be automatically created for it without passing other conditions.
You do have a good point though. I'm sure there are some services right now that allow decent control of a chosen subdomain's dns, but don't mean for you to be able to create ssl certs valid for all other subdomains too. Perhaps there should be a blacklist of sites like "blogspot". Perhaps there should be a way for a domain to indicate that wildcard certs cannot be automatically created for it without passing other conditions.
How so? You would still be subject to clicking on the link in the standard email sent to [email protected] to prove you owned the root.
The same issue appears when deciding allowance of cookie share-ability across subdomains.
The solution is called a public suffix list - more information about it is available at https://wiki.mozilla.org/Public_Suffix_List .
The solution is called a public suffix list - more information about it is available at https://wiki.mozilla.org/Public_Suffix_List .
(I'm the sslcoop.org guy)
That's essentially the model I'm looking to implement. I prefer DNS modification for domain validation, but anything that can be automated will be.
That's essentially the model I'm looking to implement. I prefer DNS modification for domain validation, but anything that can be automated will be.
StartCom charges $60 for a wildcard certificate that will be accepted by just about every important browser out there. You might even be able to get them cheaper elsewhere.
There are not any significant costs to obtaining SSL certificates, so a new CA is hardly likely to change the SSL landscape at all.
There are not any significant costs to obtaining SSL certificates, so a new CA is hardly likely to change the SSL landscape at all.
(I'm the sslcoop.org guy)
StartCom's $60 wildcard is the cheapest I've ever seen. I'm impressed with StartCom's model overall, and it was a great inspiration to me with the SSL co-op. I feel like the more diversity in approaches there is, the better off the CA ecosystem will be. If nothing else, another voice for sanity in the relevant standards bodies (CA/Browser Forum, for instance) can only be of value.
StartCom's $60 wildcard is the cheapest I've ever seen. I'm impressed with StartCom's model overall, and it was a great inspiration to me with the SSL co-op. I feel like the more diversity in approaches there is, the better off the CA ecosystem will be. If nothing else, another voice for sanity in the relevant standards bodies (CA/Browser Forum, for instance) can only be of value.
> $60 for a wildcard certificate
It is $60 for as many as you need, for multi-name certificates too, as long as (presumably, I'd need to recheck the smallprint to remind myself) they are all for you and you aren't signing certificates for others. The fact that they are signed for two years instead of one is handy too.
I've recently signed up for that to get some wildcard+multiname certs mainly for convenience (not having to sign a new cert for every tld/sub-domain combination), and not have s wildcard cert for my vanity domain and one for all the names associated with a project that I'm trying to work on (.domain.net, .domain.com, .domain.co.uk, .domain.uk all in one certificate). Remember before considering this though: there is some extra security in having separate certificates for everything instead of a huge wildcard-for-all arrangement. If you PK for a combined wildcard certificate leaks from any one location any security problems that causes affects every location you have that one certificate in use, so I am trading off a convenience gain against taking a little extra risk.
It is $60 for as many as you need, for multi-name certificates too, as long as (presumably, I'd need to recheck the smallprint to remind myself) they are all for you and you aren't signing certificates for others. The fact that they are signed for two years instead of one is handy too.
I've recently signed up for that to get some wildcard+multiname certs mainly for convenience (not having to sign a new cert for every tld/sub-domain combination), and not have s wildcard cert for my vanity domain and one for all the names associated with a project that I'm trying to work on (.domain.net, .domain.com, .domain.co.uk, .domain.uk all in one certificate). Remember before considering this though: there is some extra security in having separate certificates for everything instead of a huge wildcard-for-all arrangement. If you PK for a combined wildcard certificate leaks from any one location any security problems that causes affects every location you have that one certificate in use, so I am trading off a convenience gain against taking a little extra risk.
>There are not any significant costs to obtaining SSL certificates, so a new CA is hardly likely to change the SSL landscape at all.
Well, it'll slightly increase the attack surface against the CA model, so there's the (probably very small) chance that something will go wrong and it will introduce a massive (temporary) hole in TLS, since CA-based trust has a "weakest-link" failure model.
Well, it'll slightly increase the attack surface against the CA model, so there's the (probably very small) chance that something will go wrong and it will introduce a massive (temporary) hole in TLS, since CA-based trust has a "weakest-link" failure model.
I disagree, I think free would be a significant difference. A low barrier vs. no barrier.
But this initiative (however good) will also not provide a no-barrier approach. You need to be a member of the coop (with associated fees) to request certificates.
Which is logical. Running a CA and getting the root certificate into the right places is not cheap. Unless someone with money (e.g. Google, as they do with their CDN) decides to provide this service for free some money needs to be earned.
Which is logical. Running a CA and getting the root certificate into the right places is not cheap. Unless someone with money (e.g. Google, as they do with their CDN) decides to provide this service for free some money needs to be earned.
(disclosure: I'm the SSL co-op guy)
All of Google's free services (CDN, DNS, Chrome, etc) are centred around improving the experience of using the web, so more people use it for longer (and, hopefully, do more searches with Google and/or visit more webpages with AdSense ads on them). I'm not sure how more SSL-secured traffic feeds into that, exactly, but if anyone at Google wants to talk sponsorship, I'm all ears...
All of Google's free services (CDN, DNS, Chrome, etc) are centred around improving the experience of using the web, so more people use it for longer (and, hopefully, do more searches with Google and/or visit more webpages with AdSense ads on them). I'm not sure how more SSL-secured traffic feeds into that, exactly, but if anyone at Google wants to talk sponsorship, I'm all ears...
With all the cheap SSL providers[0] today, I don't really have an issue buying the certificates anymore. When they used to cost a small fortune, I was really restrained to buy a certificate for every small web project, but now the situation has improved.
[0] - https://getssl.me/
[0] - https://getssl.me/
That sounds very much like the service that is already offered by StartSSL.com. You pay for identity validation, but you can then create as many regular and wildcard certificates as you wish. It's a superb service.
it's a superb service, until you want a revocation, then they try to extort $25/revocation out of you (even if you've been a long term paying customer)
this may be OK if you have only issued one cert, but if you've issued a few hundred (which is the main point of StartSSL: pay once and issue many), then you are SOL unless you can afford to plonk down thousands of dollars.
more here: https://www.techdirt.com/articles/20140409/11442426859/shame...
the CEO (Eddy Nigg) is similarly patronising over email too.
this may be OK if you have only issued one cert, but if you've issued a few hundred (which is the main point of StartSSL: pay once and issue many), then you are SOL unless you can afford to plonk down thousands of dollars.
more here: https://www.techdirt.com/articles/20140409/11442426859/shame...
the CEO (Eddy Nigg) is similarly patronising over email too.
Since the revocation protocol is broken anyways I don't really think this is a real problem.
All we have to do is get all certs flagged with must-staple and have all webservers handle stapling, and we're set!
(Sarcasm? Moi?)
(Sarcasm? Moi?)
To be fair, it seems like they have a point that revocation is actually expensive for them.
Where does it say that? I would assume it's just as easy as issuing them in the first place.
You would assume wrong. Revocation is a massive PITA.
Running a revocation service is an annoyingly fiddly job, but all of that needs to be setup and running before you become a CA. Pretty much all of the faffing around is in the need to regularly regenerate (including signing with the CA key) CRLs and OCSP responder certificates. Like the rest of a CA's operation, revoking an individual certificate should be a miniscule incremental cost, modulo the larger CRL size due to the added fingerprint. I was rather surprised that so many people are sucking down CRLs, but clearly they do (http://blog.cloudflare.com/the-hard-costs-of-heartbleed).
Why? It appears a CRL is nothing more than a file containing blobs of DER-encoded cert files.
I use and like StartCom certificates, but they wouldn't solve this problem. Wildcard certificates should not require identity validation; you should be able to get a domain-validated wildcard certificate for free.
Also, their free certificates expire every year; domain-validated certificates should only require revalidation if the domain changes hands.
Also, their free certificates expire every year; domain-validated certificates should only require revalidation if the domain changes hands.
There are rules being introduced against issuing certificates for more than about three years (you can still get five years certs at the moment, but not for much longer); this is more to limit the risk of private key compromise than it is to require people to revalidate. I don't find it too onerous to have to install a new cert every year or so (he says, with several certs currently expired).
Still, I'd suggest issuing certificates for the maximum allowed length, unless requested shorter. Scalable revocation is possible; follow best practices for encryption keys by keeping a separate offline copy of a signed revocation request.
Revocation for X509 certs is a very different matter to that of revoking PGP keys. For X509, the CA can revoke the cert unilaterally, or at the request of the subscriber without the need for the subject private key. In fact, I'm not aware of the existence of a subject-side revocation process that doesn't involve the cooperation of the CA.
Do take note that they will reject and/or also refuse renewal if they think the domain whois doesn't exactly identify you, even if you confirm the domain webmaster validation. Lots of hassle if your domains have other entities or business names listed as the whois admin contact.
[deleted]
[deleted]
http://www.cacert.org/ is a similar-ish effort that's been ongoing for quite a long time.
Unfortunately they are so messed up, it isn't even funny.
Honestly, my experiences with CAcert were awful. Pressuring people into signing legal contracts that are just laughably unfair was just one part of it.
They may have been a likable organisation at the begininng (maybe with a penchant for over-the-top policy), but when they realized they wouldn't get into major browsers by default, they tried to get "serious", changing too much too fast and wrecking the whole thing. Without the big result they were hoping for.
Honestly, my experiences with CAcert were awful. Pressuring people into signing legal contracts that are just laughably unfair was just one part of it.
They may have been a likable organisation at the begininng (maybe with a penchant for over-the-top policy), but when they realized they wouldn't get into major browsers by default, they tried to get "serious", changing too much too fast and wrecking the whole thing. Without the big result they were hoping for.
It's sad that debian removed them. I think cacert needs more dedicated governance. If all the money we spent on ssl certificates could be pooled together to create non-profit organisation dedicated to public certificates, it would be awesome! And we could probably get opensource PKI infrastructure.
(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, get everything audited, and then getting through the inclusion process for all the browsers. That's what takes somewhat more organisation (and money) than writing some code and running openssl...
"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, get everything audited, and then getting through the inclusion process for all the browsers. That's what takes somewhat more organisation (and money) than writing some code and running openssl...
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 fulfilling than doing the F/OSS dance and re-inventing the wheel..
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 fulfilling than doing the F/OSS dance and re-inventing the wheel..
(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.
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.
Am I the only one that finds it hillarious (or troubling) that the SSL cert for this site is for a different host name?
(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 -- but we already knew that. ipv6coop.org, anyone? (grin)
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 -- but we already knew that. ipv6coop.org, anyone? (grin)
Possibly a stupid question, but why not make whichever vhost is correctly configured for SSL your default? Any traffic will go there unless another match is found. This is what I do to force SSL and redirect anything not matching another vhost.
Catch-all + HTTP --> HTTPS
server {
# Set server name & make it the default for this IP address
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
return 301 https://EXAMPLE.TLD$request_uri;
}
server {
listen 443;
server_name EXAMPLE.TLD;
return 301 http://EXAMPLE.TLD$request_uri;
}
That's not helpful, he doesn't have a cert for www.sslscoop.org, so the link is http; but if you try https://www.sslscoop.org/ you get a cert error, because the IP(s) are running https, but for a different name.
By the time the server can return the redirect you propose, the user agent must have already accepted the non-matching certificate.
By the time the server can return the redirect you propose, the user agent must have already accepted the non-matching certificate.
Hmm, good to know then. Is there a working Nginx config you can point me to for this use case, because I'd like to solve this issue too. My setup happens to be one HTTPS only server and one HTTP only, but it would be good to know in case I want to mix things up.
Testing a couple third-party sites, our local bus company simply times out when you manually input https://www.libertybus.je. Doing this on the main BBC site https://www.bbc.co.uk/ quickly returns you to the http version. Those are different setups but the cert errors do not happen, which is the goal here.
Testing a couple third-party sites, our local bus company simply times out when you manually input https://www.libertybus.je. Doing this on the main BBC site https://www.bbc.co.uk/ quickly returns you to the http version. Those are different setups but the cert errors do not happen, which is the goal here.
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 of the site's current SSL woes...
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 of the site's current SSL woes...
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...
[deleted]
if you find a way, could you post a gist here please !!
Yes, let's trust these people to run a certificate authority when they aren't competent enough to set up SSL properly on their own site...
[deleted]
NSA, is that you? :) (Thanks for the downvotes in advance)
What about this post makes you think the NSA is or would be involved?
I think the question you should ask yourself is: how is the NSA involved in the currently established CA system? The answer (to your question) is , the very same way. Besides, who does think that having an alternative CA provider is going to change anything? The crypto empowering security nowadays is un-trusted, implementations proven containing backdoors, and on the top of that all the implementations are written in languages that can't be formally verified and there are serious security bugs every other week. Back to the topic, what is this new CA group addressing? Which part of this chain that going to be fixed by any mean with this initiative? I guess the answer is none. :)
The NSA almost certainly has a way to sign their own certificates that they use for MITM attacks.
But that doesn't mean they gain anything from infiltrating a large number of CAs; after all, those only sign certificates, not create the private keys.
But that doesn't mean they gain anything from infiltrating a large number of CAs; after all, those only sign certificates, not create the private keys.
Well, the joke was about how useless is to start a new CA. The first member is going to be the government through a cover agency. Remember, making you believe that SSL makes your service secure is cheaper and better from the NSA point of view than having a huge cluster to crack the encrypted traffic.
How is the NSA involved in the currently established CA system?
The CA's are legally compelled to issue 'global certificates' that always return as valid so they can do MITM attacks at will.
It's fairly well documented if you google around.
And note, while it may seem like a terrible thing, it really isn't. The issue isn't that they're able to do it, the issue is how rigorous they are with their process of deciding to do it.
There is absolutely a valid reason for the government to want to do this.
It's fairly well documented if you google around.
And note, while it may seem like a terrible thing, it really isn't. The issue isn't that they're able to do it, the issue is how rigorous they are with their process of deciding to do it.
There is absolutely a valid reason for the government to want to do this.
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
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 reseller.
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 reseller.
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.
A couple of questions:
- Where do you plan to place the infrastructure of the cooperative?
- What is your expected timeline to issue Browser accepted certificates?
- Are you planning to provide an API for signing CSRs?
I am currently working on a solution for self hosted messaging and file synchronization, and your project would complement our efforts to give people the possibility to self-host securely.
- Where do you plan to place the infrastructure of the cooperative?
- What is your expected timeline to issue Browser accepted certificates?
- Are you planning to provide an API for signing CSRs?
I am currently working on a solution for self hosted messaging and file synchronization, and your project would complement our efforts to give people the possibility to self-host securely.
(I'm the SSL co-op guy)
- Probably in Australia, at least at first, since that's where I'm based. I'd like the DR site to be in Europe, if possible, but that might not be a day 1 achievement.
- I'd like to be able to issue certs from day one of the co-op, via a reseller or other arrangement -- that might cost a few dollars per cert, though. It's a minimum of two years from "let's do this!" to being accepted in all the browsers, though (look at the Mozilla inclusion timeline for an idea of best case: https://wiki.mozilla.org/CA:How_to_apply#Timeline)
- An API is definitely intended from day one. My general architecture for these kinds of systems is API for everyone, and the website just talks to the same API that the general public does.
I'd love to talk to you more about how the co-op could help you with your system.
- Probably in Australia, at least at first, since that's where I'm based. I'd like the DR site to be in Europe, if possible, but that might not be a day 1 achievement.
- I'd like to be able to issue certs from day one of the co-op, via a reseller or other arrangement -- that might cost a few dollars per cert, though. It's a minimum of two years from "let's do this!" to being accepted in all the browsers, though (look at the Mozilla inclusion timeline for an idea of best case: https://wiki.mozilla.org/CA:How_to_apply#Timeline)
- An API is definitely intended from day one. My general architecture for these kinds of systems is API for everyone, and the website just talks to the same API that the general public does.
I'd love to talk to you more about how the co-op could help you with your system.
I'm mainly favor in this because I could trust the cooperative more than I trust the existing CAs. As long as it doesn't cost me more than the existing cheapest options [e.g. StartSSL, NameCheap's cheap ssl certs] and had 99.7%+ coverage, I'm 100% sure I'd pay for it.. :)
CA's currently maintain internal keyword warning systems that flag domain validated requests for manual intervention. Anything that even hints that it is involved with a major company, church, charity, bank or financial institution gets flagged and approved manually.