At the moment Diaspora does not accept CAcert as valid certificate authority and as a consequence people using CAcert-certificates (and these are many) will not be able to communicate with other pods properly.
Admins already using CAcert may not create separate startSSL-certificates (as suggested in the wiki) just because of being annoyed and run their pod with “invalid” CAcert-certificates resulting in malfunctioning synchronization with other pods. Also users of CAcert-pods are not able to use Diaspora-apps such as cubbi.es due to their unaccepted certificates.
In short I think that the growth of the Diaspora-podnet suffers from the exclusion of CAcert.
This is why I want to vote for including CAcert as-soon-as-possible as a valid CA into the Diaspora project!
Note: This discussion was imported from Loomio. Click here to view the original discussion.
Why were they considered invalid in the first place?
I would urge you to carefully consider the consequences before doing this. As we discovered on the Friendica project (where even self-signed certs are accepted), invalid certs (as determined by the browser vendor) annoy people with popup warnings when viewing pages with content from other sites such as linked images.
I work on hundreds of computers in a day, and cannot even use Friendica from a new computer without manually writing down every “invalid cert” URL and visiting each site to accept them all. You don’t get a choice with images to accept the site when the warning pops up. You have to visit the site to get the option to accept it. You mom isn’t going to do this. She’s going to see the “this website isn’t trusted” and take the browser advice to “get me out of here”. The thing is, it won’t be the untrusted site where the warning pops up. It will be your site, after you’ve paid for a cert.
Anyway - I’m an outsider on this project and you’re free to do as you wish, but please weigh this decision carefully. With the Red Matrix project, we went full circle and lack of a browser valid cert (we’re using the Mozilla trusted CA list) means you aren’t part of the network - period. It isn’t about trust and it isn’t about the cert “cartel” - it’s about annoying your friends and making it difficult or impossible to see their own (or your own) social stream on multiple computers without technical hassles.
It definitely shouldn’t become the recommended method, my point is to enable federation with pods on CACert certificates. I’d go so far to include an extensive explanation in the installation guide, make it the podmins decision.
@mikemacgirvin I completely agree with you that Diaspora should not allow for a “popup-catastrophe”, but only allowing one another certificate-authority should not put Diaspora users in that situation.
Besides I think it is also about the “cert-cartel” and a free community-driven project as Diaspora should not rely on some company selling certificates.
@jonnehass Yes. Maybe it should be the podmins decision, but at least it should be the default policy to accept CAcert. - In my opinion it should not even be the podmins decision and there should be no config-option to disallow CAcert. - As one of Diasporas strengths is decentralization, boundless communication between all pods is crucial and should not depend on config settings which split the pod-network into subnets!
While the browsers do not recognize CaCert, it’s really hard to use it…
Well it’s really only the Mozilla products since they come with their own CA bundle. All other ones use the systems bundle. Debian and all that base their CA bundle on it, like for example Arch, already include CACert. So the major ones left are Fedora/Red hat, CentOS, Windows and Ubuntu.
@flaburgan But don’t you think it would be reasonable for Diaspora users to once install the CACert root-certificate in their browsers if CACert is not accepted by default? - After all it’s as simple as visiting one link and clicking the accept-button.
In addition one could create a wiki-entry explaining to users why Diaspora is accepting and supporting CACert and giving a link to the root-certificates. - I also hope that with more projects like Diaspora supporting CACert at some point Mozilla (and others) will give in and accept CACert as certificate authority.
All firefox users + every windows and ubuntu users = 90 (95?)% of diaspora users. We can’t ask each one to add a new certificate authority. And as described by @mikemacgirvin accepting all certificate is really annoying. Moreover, it’s not accept once a new authority, it’s accept it on all machine you use: your computer, your mobile, your professional computer, etc.
I’m sorry but we should (or the guys from CaCert should) work on polish their certificate process to be accepted by Mozilla and Microsoft, and after that, we could accept CaCert…
Proposal: Optionally accept CACert as certificate authority
Make Diaspora pods optionally accept CACert-signed certificates.
In this way the Diaspora network does no longer depend on commercial SSL-certificates, as would be appropriate for an open, community-driven project as Diaspora.
Concerning security CACert could even be considered more secure than for example StartSSL because private keys never leave the host of the user, while with StartSSL it is possible to have private keys being created on the StartSSL website.
Make CACert support an optional configuration-setting (not accepting by default) to come up to the objections of some users not wanting to accept CACert as certificate authority as long as they are not “generally” accepted by Microsoft and Mozilla.
- Then once CACert is “generally” accepted we could make it the default behaviour for Diaspora pods to accept their certificates.
Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.
@Flaburgan Concerning your objections I think accepting CACert optionally (not accepting by default) would be a good compromise?
accepting CACert optionally (not accepting by default) would be a good compromise?
Don’t think so: content is coming from every pod, if only one accept it, the whole network needs to do so.
@Flaburgan At the moment no pod will accept CAcert and pods using CAcert will not be able to federate with other pods. - So yes, content is coming from every pod, also from CACert-pods, which are excluded from federation at the moment.
Right now, it seems that CACert is undergoing an audit in the hopes of being included in Mozilla Firefox. You can see the bug discussion here, and Mozilla’s policy here.
So long story short, I think for any of this to be practical, we will have to wait for greater browser support. When more browsers support CACert for inclusion, then I think it’ll be better for our end users.
Using Diaspora* should absolutely NOT require any actions from the user - except choosing a username. Any security popups coming up because of lazy podmins is going to not expand the network, but kill it. A big no.
@jasonrobinson I don’t think it’s fair to say that a podmin is being “lazy”. If CACert had better support, I’m sure more than a few podmins would be happy to not have to spend extra cash on a certificate.
OK not lazy then - but we cannot support technologies that do not perfectly suit the network. And to me this sounds like making an ugly compromise.
I’m very said about this block. I just want to mention that the majority won’t see security popups, because they don’t see them right now, embedding images from “unsecure” sites doesn’t provoke them. Everything else has been sad and was overshadowed by “OMFG, but Firefox doesn’t include it!” bullshit.
Just keep ignoring the first word in the proposals title and my first comment. And have fun with your snakeoil.
I think the general disagreement here stems from the fact that it hasn’t exactly been explained how CACert would be used exactly. I think many in this thread are talking about using CACert for a pod itself. Granted, if you navigate to anything using CACert using https, you’re going to get the big ugly dialog with a button saying “Get me out of here!” Some users (possibly many) wouldn’t know better, and would likely freak out if this were the case.
@jonnehass You’re talking about having the ability to communicate with pods that are using CACert themselves. Are there any technical implications (if any) to keep in mind when federating between a non-CACert and a CACert pod? If there isn’t any issue in federating back and forth, would having this optional feature of supporting CACert even really be a problem?