Loomio
Mon 5 Aug 2013

Make CAcert a valid certificate-authority now!

A
Alex Public Seen by 142

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!

ST

Sean Tilley Mon 5 Aug 2013

Why were they considered invalid in the first place?

MM

Mike Macgirvin Mon 5 Aug 2013

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.

JH

Jonne Haß Tue 6 Aug 2013

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.

A

Alex Wed 7 Aug 2013

@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!

F

Flaburgan Wed 7 Aug 2013

While the browsers do not recognize CaCert, it's really hard to use it...

JH

Jonne Haß Wed 7 Aug 2013

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.

F

Flaburgan Wed 7 Aug 2013

90% of our users :p

A

Alex Wed 7 Aug 2013

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

F

Flaburgan Thu 8 Aug 2013

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

A

Alex started a proposal Thu 8 Aug 2013

Optionally accept CACert as certificate authority Closed Thu 22 Aug 2013

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.

Results
Agree - 11
Abstain - 11
Disagree - 11
Block - 11
33 people have voted (11%)
A

Alex
Agree
Thu 8 Aug 2013

A

Alex Thu 8 Aug 2013

@Flaburgan Concerning your objections I think accepting CACert optionally (not accepting by default) would be a good compromise?

DU

[deactivated account]
Abstain
Thu 8 Aug 2013

N

NicoAlto
Abstain
Thu 8 Aug 2013

JH

Jonne Haß
Agree
Thu 8 Aug 2013

FTL

FÁBIÁN Tamás László
Agree
Thu 8 Aug 2013

F

Flaburgan Thu 8 Aug 2013

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.

SVB

Steffen van Bergerem
Agree
Thu 8 Aug 2013

F

Flaburgan
Disagree
Thu 8 Aug 2013

I don't want to request any action from the user. We need to open our network to non-geek people. Joe Average will not accept a warning certificate, he will simply not you the application, especially if he has to do it on desktop, mobile, etc...

G

goob
Abstain
Thu 8 Aug 2013

I'm afraid I don't know enough about the pros and cons of this, so am happy to go with whatever the rest of you decide.

A

Alex Thu 8 Aug 2013

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

ST

Sean Tilley Thu 8 Aug 2013

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.

MS

Mikhail Shirkov
Agree
Thu 8 Aug 2013

We should support federation with CACert certificates! It can be useful for small instances, with loyal user base, or for cypherpunk communities.

SM

Seth Martin
Disagree
Thu 8 Aug 2013

Need to wait until there is greater browser support. We should not be driving away new users that don't understand and get scared with browser warnings.

JR

Jason Robinson Thu 8 Aug 2013

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.

JR

Jason Robinson
Block
Thu 8 Aug 2013

ST

Sean Tilley Thu 8 Aug 2013

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

JR

Jason Robinson Thu 8 Aug 2013

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.

JH

Jonne Haß Thu 8 Aug 2013

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.

ST

Sean Tilley Fri 9 Aug 2013

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?

A

Alex Fri 9 Aug 2013

@jasonrobinson Another certificate authority is not a new technology.

Just to clarify again:
This is not about pods using CACert certificates, which is possible anyhow. It's about allowing interpod-communication (federation) with pods using CACert-certificates.

JR

Jason Robinson Fri 9 Aug 2013

Still totally against this. Anything that makes it likely that some users will not see some posts or will get security popups will just help to kill Diaspora* and make it just another geeky hackerspace.

A

Alex Fri 9 Aug 2013

@jasonrobinson Actually at the moment users will not see posts from users on CACert-pods. And referring to @jonnehass embedding content from CACert pods will not provoke popups! - So I don't see your point!?

JR

Jason Robinson Fri 9 Aug 2013

Can someone explain why there will not be a warning given to user for posts coming from a pod without a "valid" cert? In terms that even I can understand. Maybe we have no votes who just don't understand the issue.

F

Flaburgan Fri 9 Aug 2013

I think the current problem with Firefox 23 not allowing HTTP-content in an HTTPS page is a great example for what we risk: a broken stream. Imagine a user accepted CaCert authority in his desktop browser. Then he uses his mobile and see that there are missing images (they are linked directly from the origin pod), but have no idea why. We don't want that, so what should we do? Warn him it's because he didn't add cacert authority? Then explain him how to do that? On a mobile browser, not obvious. I'm almost even sure that you can't with the default browser.

We have to avoid creating different behaviors depending on the user configuration. It's the game of the web, have the same rendering in every platform...

JH

Jonne Haß Fri 9 Aug 2013

So here's a test page https://social.mrzyx.de/test.html

Looks like IE and Safari completely block, no "security popups" in Chrome, Firefox and Opera. I guess I'm just going to give up.

SVB

Steffen van Bergerem Fri 9 Aug 2013

@jonnehass In Firefox 23 the two images with an CACert certificate are blocked without an popup

JH

Jonne Haß Fri 9 Aug 2013

Yes, that is expected. But the point is that for the large majority there won't be any popups. On my list of things to include in the explanation when mentioning that CACert would be a possibility was the fact that remote people won't see the images, I was very aware of that from the start.

JR

Jason Robinson Fri 9 Aug 2013

So what is the conclusion? If this motion passes and the implementation is done correctly, the ONLY effect is that some people will not see images from pods with CACert?

If this is so I'll change my vote.

F

Flaburgan Fri 9 Aug 2013

@jasonrobinson except for podmin using cacert for their domain name, but this would be pod specific and not impacting the whole network.

G

goob Fri 9 Aug 2013

@jonnehass I got two security popups for your test page using Opera 12.14.

JH

Jonne Haß Fri 9 Aug 2013

Interesting, I didn't for Opera 15

F

Flaburgan Fri 9 Aug 2013

No security pop up but no image for Firefox 23 :(

JR

Jason Robinson
Abstain
Fri 9 Aug 2013

If we can guarantee no popups for modern(ish) browsers, mobile too, ok for me.

ST

Sean Tilley
Agree
Fri 9 Aug 2013

G

goob Fri 9 Aug 2013

My version of Opera is the last one before they shifted to Webkit, which might explain the difference. I think a fair few people decided not to upgrade at that point, so there are probably others who use older versions.

G

goob Fri 9 Aug 2013

Well 12.14 only came out 6 months ago, so isn't really old... but I've just discovered there is now a 12.16, which came out last month, so have updated to that, and still get the warnings.

The changelog mentions fixing a problem with signing certificates in this release - not sure if it's related to this: http://www.opera.com/docs/changelogs/unified/1216/

I'm keen not to move up to 15 because I like Opera with the Presto engine, and have read that Webkit is causing issues so would rather not upgrade further. As I say, it seems as though a fair number of Opera users feel the same.

JR

Jason Robinson Fri 9 Aug 2013

Doesn't sound very good

SM

Seth Martin Sat 10 Aug 2013

I'm sorry, "the majority won't see security popups" isn't good enough for me. Dolphin/Android browsers are very popular and missing photos confuses people too. I don't have a mobile apple device to test their very popular browser. If it can be demonstrated that no users will get warnings, I will change my vote.

SVB

Steffen van Bergerem
Abstain
Sat 10 Aug 2013

G

goob Sat 10 Aug 2013

Testing Dolphin 5.0 in iOS 4.2 (out of date, I know), I get no popups but the last two images don't load.

Opera Mini 7.0.5 (same OS): no warnings, all images load fine.

Safari (latest version for my OS version; not sure which version number): no warnings, last two images don't load.

I realise this doesn't answer your Android query directly, but it adds to the browsers tested.

H

hewiak
Abstain
Sat 10 Aug 2013

JR

Jason Robinson Sat 10 Aug 2013

I think we have a big problem. I tested the default Android browser that comes with 4.2.2 (CyanogenMod, but prob no different?) - and two popups are generated.

pic
pic

Android being the most popular mobile operating system around I really don't think we should do this now. Rather when the situation changes, we should adapt. If we start accepting cacerts now and the situation gets worse - we cannot go back and have locked D* into a popup heaven.

Other browsers I tested (on Ubuntu) are Firefox 23, Chromium 28, Midori 0.4.3 and Epiphany 3.6.1 - no popups in any of those but also of course no images shown.

Of course we could filter out posts from the stream based on user agent but that is getting a bit hacky.

JR

Jason Robinson
Block
Sat 10 Aug 2013

A big no since Android default mobile browser will not work

DU

[deactivated account]
Disagree
Mon 12 Aug 2013

A

Alex
Disagree
Mon 12 Aug 2013

Given all the problems I was not aware of when opening the discussion I changed my mind ...

M

matl
Abstain
Mon 12 Aug 2013

DM

David Morley
Disagree
Tue 13 Aug 2013

S

SuperTux88
Agree
Wed 14 Aug 2013

EG

Erwan Guyader
Agree
Wed 14 Aug 2013

RB

Roger Braun
Disagree
Thu 15 Aug 2013

Cypherpunk networks can just trust the necessary Certs themselves. If this was official, users would get security errors/warnings when seeing content from CACert pods. I agree that the state of SSL and the Cert system sucks, but we can't change that.

RB

Roger Braun Thu 15 Aug 2013

I'm sad that I had to vote no on this. Having CACert as a valid CA would have been perfect for my usecase, which is hosting a private pod on a subdomain without giving big money to snakeoily CAs. But as the system is set up right now, we can't do anything about the content that the user receives directly from the CACert-certified pods, and they most probably would get error messages or warnings. If images would be proxied through the users own pod, this might be viable, so maybe this should be implemented.

A

aj Fri 16 Aug 2013

i know of a couple of pods on the network using self signed certs

i think they had to do some tweeks with the openssl, but they appear to be fully functioning pods

JH

Jonne Haß Fri 16 Aug 2013

@aj I highly doubt that. Examples?

A

Airon90
Abstain
Sat 17 Aug 2013

N

Nick
Agree
Sat 17 Aug 2013

R

Ruxton
Abstain
Mon 19 Aug 2013

A

AlexB
Disagree
Tue 20 Aug 2013

FS

Florian Staudacher
Abstain
Wed 21 Aug 2013

I can live with it either way ;)

C

CodeHero
Agree
Wed 21 Aug 2013

TS

Tom Scott
Block
Wed 21 Aug 2013

I would rather not ship code that can cause warnings (albeit benign) on Android's stock browser. Seems like this whole idea is broken, evidenced by the big red warning I get when I visit http://cacert.org =P

RF

Rasmus Fuhse
Abstain
Wed 21 Aug 2013

I would say yes to the proposal, because non-commercial certs are very nice. But in fact I think, this proposal is about changing the protocol. And maybe we should ask ourselves, if we still need certs in the protocol.

BB

Brent Bartlett
Block
Thu 22 Aug 2013

Sorry, this just seems like a bad idea. I don't see what the upside to this would be. Having sites that pop up warnings would just create dead ends in the Diaspora network.

RS

Raphael Sofaer
Disagree
Thu 22 Aug 2013

D

diasp_eu
Disagree
Thu 22 Aug 2013

T

thomas
Disagree
Thu 22 Aug 2013

not at this moment at least.

TA

Theodotos Andreou
Agree
Thu 22 Aug 2013

In the after NSA leaks era, I don't think that any of the commercial CAs are to be trusted. I vote in favour of CAcert to be accepted in diaspora

C

Christophe
Agree
Thu 22 Aug 2013

I am a big supporter of CAcert, I received my first certificate in 2006 and I'm an assurer. I'd love to see CAcert support in pod to pod communication, as XMPP is doing it at the moment.

M

matl
Agree
Thu 22 Aug 2013

A

aj Thu 22 Aug 2013

could someone tell me please what exactly are the protocol features do not work with CA or self signed certs?

besides browser warning for the client i mean

i have contacts on pods using CA and self signed certs and communicate with them regularly

i was not aware of any problem, i get their posts and they get mine?

JH

Jonne Haß Thu 22 Aug 2013

@aj I've never seen that working. So again, examples?

JH

Jonne Haß Thu 22 Aug 2013

Note that you may receive a bit incoming traffic, but your pod should be unable to send anything to them.

A

aj Thu 22 Aug 2013

thanks. i'm trying to understand better.

i arrive here today because this post
https://iliketoast.net/posts/67848

was reshared to diapod.net via here
http://diaspora.linuxmaniac.net/posts/54793

so the later was able to receive from one pod and send the post to another

perhaps it is being done without encryption at all?

although i thought this should not be allowed?

JR

Jason Robinson Thu 22 Aug 2013

unencrypted Diaspora pod - nice :P

A

aj Thu 22 Aug 2013

well.. i procrastinate too long and missed the vote! he! :)

i would vote NO to this because i think the fact that you need to setup a trusted cert gives the network community good integrity

not to say that a community of diaspora pods using CA would not be very cool, it would

but i would think of it as a separate network community

JH

Jonne Haß Thu 22 Aug 2013

We do highly recommend HTTPS, but we do not force it. Private posts are always encrypted for the target user anyway.

A

aj Thu 22 Aug 2013

i think i sort of get it now. thanks. it's kind of mind boggling :)

i do hope to see CA Certs accepted as a trusted authority by the major browsers

i don't know why there is such a fuss about that :)

RB

Roger Braun Thu 22 Aug 2013

Because CAs want to make lots of money for an essentially free service...

S

Strubbl Wed 28 Aug 2013

CAcert would be nice.

A

aj Wed 28 Aug 2013

i think it comes down to the issue of browser support

there seems to be no problem with pods communicating with whatever kind of certificate they like to setup

JH

Jonne Haß Wed 28 Aug 2013

@aj Trust me there is. It's the number one setup problem.

A

aj Wed 28 Aug 2013

i'm not saying that you can use a CA cert to communicate with all of the existing pods

it would have to be agreed on by both ends

but this might be preferable to using no encryption as they seem to be doing now

JR

Jason Robinson Wed 28 Aug 2013

It's not just encryption - it's about offering users good usability. As talked earlier some browsers just don't like links to other pod resources with CA certs. Doesn't help if the podmin has agreed to opt-in if the user has to suffer. We can't control which pods open their registrations.

A

aj Thu 29 Aug 2013

ya. i was meandering over the technical possibilities :)

i would still vote no to this.

i like the trust structure, and i think the real issue is whether or not CAcert should be included in the bundles for the major operating systems and web browsers

if/when it is, then this issue resolves itself :)