Support CAcert server-side certificates

[mart-e]

When I try to connect to e14n.com with my account from my instance u.mart-e.be, I have got the following error :

Error: UNABLE_TO_VERIFY_LEAF_SIGNATURE
    at SecurePair.<anonymous> (tls.js:1350:32)
    at SecurePair.EventEmitter.emit (events.js:92:17)
    at SecurePair.maybeInitFinished (tls.js:963:10)
    at CleartextStream.read [as _read] (tls.js:463:15)
    at CleartextStream.Readable.read (_stream_readable.js:320:10)
    at EncryptedStream.write [as _write] (tls.js:366:25)
    at doWrite (_stream_writable.js:219:10)
    at writeOrBuffer (_stream_writable.js:209:5)
    at EncryptedStream.Writable.write (_stream_writable.js:180:11)
    at write (_stream_readable.js:573:24)
    at flow (_stream_readable.js:582:7)

I used to be able to connect to this instance but not anymore for a few weeks. I have this also with other instances from e14n (microca.st, 1realtime.net, ...)

[erincandescent]

Your certificate is from CACert. CACert is not considered sufficiently trusted for inclusion in the OS/distro/OpenSSL/NSS certificate stores; other instances are rejecting your certificate because it is untrusted.

Use a trusted CA.

[mart-e]

Well that sucks. Does it mean also I can not use self-signed certificates ?

I think it's a bad move to forbid these certificates, it's still better than not using SSL (and also it's how I make pump cohabit with other websites).

[evanp]

StartSSL works, and it's gratis:

http://www.startssl.com/

[erincandescent]

Disabling certificate validation is asking attackers please man in the middle me. It gives you a false sense of security while being very little better than cleartext.

[mart-e]

I don't ask to disable certificate validation. Browsers have a nice way to handle this issue by asking you what to do. You could also see this warning at first connection with the untrusted host and remember this certificate as safe. If the certificate change later, then you can put big MITM warning.

I like CAcert for the community aspect. I could also get a gratis one at StartSSL but it is not the same purpose. Anyway, I find that rejecting every self-signed certificate is a bit extreme.

[erincandescent]

And what if the user doesn’t validate the certificate? (we know that any pretence that they do is an elaborate fiction…)

How do you limit the scope of this approval to the user who approved the certificate?

How do you handle this when the communication was initiated because of API actions? Especially considering that distribution is handled asynchronously in the background…

It’s unworkable; never mind that browsers are more and more making bypassing certificate errors difficult for very good reasons.

PS, while we are on the subject of certificates: Evan, don’t forget that some of the try-it pump certificates are up for renewal in the near future!

From: Martin Trigaux [mailto:notifications@github.com] Sent: 22 August 2013 22:38 To: e14n/pump.io Cc: Owen Shepherd Subject: Re: [pump.io] Can not connect UNABLE_TO_VERIFY_LEAF_SIGNATURE (#786)

I don't ask to disable certificate validation. Browsers have a nice way to handle this issue by asking you what to do. You could also see this warning at first connection with the untrusted host and remember this certificate as safe. If the certificate change later, then you can put big MITM warning.

I like CAcert for the community aspect. I could also get a gratis one at StartSSL but it is not the same purpose. Anyway, I find that rejecting every self-signed certificate is a bit extreme.

— Reply to this email directly or view it on GitHub https://github.com/e14n/pump.io/issues/786#issuecomment-23128167 . https://github.com/notifications/beacon/KfCbfcweUREkh0uq_-Z6AK1UR16DYrpcGT8frdUvlnGnfkNqGg2zA3pkmaSj5QYU.gif

[gllmhyt]

Just for the record: CACert's root certificate is included in distributions worthy of being one (ca-certificates package). I don't see where StartSSL is more reliable than CACert. Do you even remember DigiNotar? Staying with such centralized conceptions of certificates issuers is irrelevant when you're trying to build a decentralized/federated network. Moreover, such decisions will repel enthousiast adopters. If one user cannot afford an arbitrary trusted certificate, or has to use a load-balancer because he has multiple services on a single machine, he can go f*ck himself. It's like you don't want anybody (certainly not « poor » individuals) to use pump.

[erincandescent]

We have a decentralized certification system; it's called DANE. It completely sidesteps the issue of certification authorities by allowing you to assert your TLS certificate(s) directly from your (DNSSEC-secured) DNS records. If you want a true solution to the problem of CAs, get OpenSSL and NSS to incorporate support for DANE. Then, once it becomes widely deployed, we can sideline the role of CAs to providing "value add" security services, e.g. EV certificates.

Note the list of people from that list which don't include CACert:

• Fedora
• RHEL
• FreeBSD
• Ubuntu
• Mozilla
• Google (Android)
• Apple, Microsoft, etc

Between them Fedora, RHEL and Ubuntu comprise a significant proportion of web servers; never mind that Mozilla, Google, Apple and Microsoft between them cover the vast majority of web browsers

Why? Because CACert doesn't meet their inclusion policies (Note that I couldn't even find what the policies are for most of the distros which include CACert, which is hardly what you want to discover for such an important issue); more concretely:

• Mozilla, Apple, Google, Microsoft require CACert pass an audit which CACert have yet to pass (last time they tried they *failed()
• Fedora, RHEL and FreeBSD all delegate to Mozilla
• Ubuntu has its' own policies which CACert doesn't meet

What I ask of you is this:

1. FIrstly, Why should CACert be subject to lower standards than any of the other CAs already included, especially noting the known issues with the system as-is?
2. What are you proposing as a solution to this? That Pump.io ship its' own CA list and somehow redirect Node to it?

Again, if money is an issue: what, concretely, is the issue with StartSSL?

[evanp]

I think it should be possible to use the OS's list of certs with this package:

https://github.com/monceaux/crypto-cacerts

[gllmhyt]

@evanp It seems interesting, indeed.

@oshepherd I think I made my point unclear. I'm not against the choice of some distributions to not have CAcert root certificate installed, but against the choice to develop a federated service relying on centralized CA cartel hierarchy. As we have seen in DigiNotar's case, this is a broken system that do not exclude fraudulent certificates. I do agree that lower standards are against security, I'm not a blinded proselyte for CAcert's community. I hope that you understand that on this base money is less an issue than the structure itself of those CA's you're relying to. StartSSL is one of those, that's why I'm rejecting it too. For a federated service, I simply see a contradiction and wanted to point it.

Nonetheless, I have the feeling that the constraints for a good experience of the software (like the certificate in this case) are unreachable by individuals whom are not "aware" of those constraints, and just want to participate to the community. How many have a dysfunctional certificate ? Moreover, the injunction to use StartSSL, to those whom cannot afford some trusted certificate given out by the CA cartel, does really sound like coercion.

The second part of my reaction was more like discontent, and you would have probably no due to endure it. I was fed up with developers' authoritarianism. The "fix it" / "do it" / "fork it" / "code it" / "patch it" / "make it" / "learn it"... leitmotif is driving me insane as much as the Daft Punk's song. Because one have the liberty to do something doesn't imply neither he has to do it, nor he has the ability for it. This was the reason I scented you don't wanted a community. It's not against you in particular, you are free to deal with the community and impose the constraints you want to.

For me, the corollary was segregation, marginalisation, technical pauperization of the potential hobbyists, antinomic with my notion of free software (remember: liberty, equality, fraternity). But I may have forgot that opensource software is not free software in the debate. I exploded here because I think it's unacceptable and symptomatic on the opensource scene, but I'm neither against pump, nor you. I hope your project will grow and live on, I truly hope it.

Cheers.

[erincandescent]

The problem here is machine to machine trust - note that Pump servers which have never encountered each other potentially have to communicate in response to API calls; potentially in the future in response to other server to server communication (when "complete" comment distribution occurs)

Somebody needs to vouch for the identities of those servers (else the network has no mechanism of trust). At the present moment in time, the best system that we have for that is the one that your browser uses; the certification authority.

Now, regarding that: You assert that the CA system is centralized, but I see it as the opposite: All the major actors (Mozilla, Microsoft, Apple, Google) have very transparent policies for CA inclusion; anyone who can afford the equipment and the audits can become a CA. Certification is very decentralized.

Which, of course, is its' downfall; we now have over a hundred CAs, and every CA is another potential weak point, yet stopping accepting new CAs would result in market ossification and eventually price gouging. Keeping an eye on every CA is... difficult.

This is why, to patch the CA system, we (as in the internet community) are implementing things like key pinning, the Google certificate transparency project, and CA scopes (For example, the Spanish government CA could be restricted to *.gov.es). Hopefully, these are "stopgap" measures.

On the other hand, we are working on things like DNSSEC and DANE, which are, as it works out, a centralized solution. Because trust all flows from the root DNS zone, we have one trust anchor, and for domains, we only have to trust two people (ICANN and the operator of our chosen TLD), as opposed to every CA in existence.

Of course, DNSSEC has the advantage that it doesn't require an additional actor: We already pay for our domain; there is no 3rd party to pay.

We like to think of the internet as distributed and, at the protocol layer, it largely is. However, underlying that we must not forget the layer of centralized administration which goes into running it

We recommend StartSSL, of course, because StartCom give away free domain validated certificates (and were the first to do so) and are widely supported (finding an OS without their root certificates included is difficult these days - an install of Windows XP will do it, but SChannel will go and ask Microsoft when it encounters a root it doesn't know, so dynamically populates the databse with new roots). In addition, they contribute to open source and maintain a good presence in places like the mozilla-security-policy mailing list. I've discussed matters with them; I have no real reservations with recommending them.

And, really, until DNSSEC is more widely supported and easy to deploy, it's our best solution. Deploying a certificate isn't difficult, but, yeah, we need better documentation.

[dper]

Responding to a old comment about why StartSSL is bad. It is bad because revocation costs money. You can do half of what you want for free, but then you find yourself trapped. You might call it a lock-in SSL provider.

One problem is how to handle certificates. If I set up a server using CACert, which I find easy to use, then other servers might not talk to me. But there are no visible error messages -- we have to go looking for them. This is in contrast with a web browser where an alert appears.

In other words, if pump.io is to be restrictive about certificates, then it would be nice to make the denied connections more visible, and perhaps it would be nice to be able to quickly whitelist certificates or certificate authorities.

To make federation dependent on playing in the big leagues where most people purchase commercial certificates is something to avoid, if we can reasonably do so.

[strugee]

This feels like it will be a non-issue when Let's Encrypt rolls out, though.

[larjona]

Let's Encrypt is public now. Comments?

[dper]

With clear documentation, this solves the problem. Something like (or better than) this might be good...

If you are looking for a free SSL certificate, please consider Let's Encrypt. Self-signed certificates and certificates signed by less-trusted providers like CACert appear to work when you're installing, but later your server may have trouble communicating with other pump servers.

In a perfect world we would also like for people to easily see an error message in the case that they're using a broken or unsigned certificate, but that is a separate and far less important issue -- something like "error information should be more visible".

[strugee]

In a perfect world we would also like for people to easily see an error message in the case that they're using a broken or unsigned certificate, but that is a separate and far less important issue -- something like "error information should be more visible".

Filed #1150.

[larjona]

Filed #1151 for the documentation improvement part. I think this issue can be closed. If there are no further comments here, I'll close it in some days.

[strugee]

Closing per @larjona's comment above. The answer to this is now "use Let's Encrypt".