
The SSL Co-operative: A Member-Controlled Certification Authority - SworDsy
http://www.sslcoop.org/
======
JoshTriplett
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.

~~~
raving-richard
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.

~~~
ehPReth
Mozilla created [https://publicsuffix.org/](https://publicsuffix.org/) \-
perhaps that could help with com.au vs. example.com.au?

~~~
raving-richard
That's brilliant. I was wondering if there was a list that actually provided
the relevant information. Thanks for the link.

------
michaelbuckbee
There's an assumption in this that domain validated certificates can be wholly
automated. But, in the same way that spammers seek out open SMTP relays,
phishers seek out weak SSL validation systems for use in setting up phishing
sites.

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.

~~~
ademarre
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.

~~~
michaelbuckbee
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.

~~~
womble
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...

~~~
michaelbuckbee
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.

~~~
womble
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.

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

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

------
colmmacc
[http://www.cacert.org/](http://www.cacert.org/) is a similar-ish effort
that's been ongoing for quite a long time.

~~~
CMCDragonkai
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.

~~~
womble
(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...

~~~
TsukasaUjiie
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..

~~~
womble
(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.

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

~~~
womble
(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](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.

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

~~~
womble
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)

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

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

~~~
womble
(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.

------
meowtaxi
Am I the only one that finds it hillarious (or troubling) that the SSL cert
for this site is for a different host name?

~~~
womble
(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)

~~~
tombrossman
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;
      }
    

Or, rewrite HTTPS to HTTP for that vhost only

    
    
      server {
              listen      443;
              server_name EXAMPLE.TLD;
              return 301 http://EXAMPLE.TLD$request_uri;
      }
    

Mozilla's server-side TLS wiki at
[https://wiki.mozilla.org/Security/Server_Side_TLS](https://wiki.mozilla.org/Security/Server_Side_TLS)
is the best documentation I've found yet, and includes great examples of
complete configs for various servers. Hope that helps.

~~~
toast0
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/](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.

~~~
tombrossman
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](https://www.libertybus.je). Doing this on the main
BBC site [https://www.bbc.co.uk/](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.

------
leccine
NSA, is that you? :) (Thanks for the downvotes in advance)

~~~
codezero
What about this post makes you think the NSA is or would be involved?

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

~~~
codezero
How is the NSA involved in the currently established CA system?

~~~
leccine
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](http://files.cloudprivacy.net/ssl-mitm.pdf)

~~~
MichaelGG
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.

~~~
leccine
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.

