Do we need valid SSL certificates?


(Jonne Haß) #1

The header says it all, what’s the benefit we gain? Does it really add more security or is the encryption we get enough?

I’ll list the pros of disabling host and peer verification, waiting for your cons.

  • Hassle free SSL setup, self-signed certificates would be possible to use.
  • Related to point one, installers and appliances could generate them.
  • cacert.org support would not be a matter of distributions including their root.
  • Tolerant against setup faults, a missing intermediate cert is a common error.
  • Setups running on old libcurl & libopenssl could interoperate with setups requiring SNI support.
  • More fun for everybody (SCNR).

Note: This discussion was imported from Loomio. Click here to view the original discussion.


(Justin Thomas) #2

SSL has a lot of problems, but it’s pure security theatre without a trusted certificate chain. Without a way to validate the certificate, MITM attacks become trivial (which is the one thing that SSL certificates are meant to protect against).

If we do go down this route, I would definitely want a configuration setting to allow me as a pod owner to reject communication with pods with invalid certificates.


(raven24) #3

just thinking out loud:
what if we set up our own CA and issue ‘Diaspora certs’ - it could work automatically like startSSL, where you have to at least confirm the email address, and you only get one per domain…


(Jonne Haß) #4

Having it a configuration setting is the compromise I’ aiming at, but ya know, you only get the half of what you say you want :stuck_out_tongue:

I’m unsure a custom CA would solve anything that wouldn’t be solved by automagically appending CAcert’s root to the system bundle.

For the man-in-the-middle attacks, be aware that for Diaspora they wouldn’t mean a total breach unless you put them in place for the very very first moment and already fake the public keys in the profiles. Everything that’s send unencrypted is public data anyway, one could “only” gather who is talking privately with who and how frequently does he do that. Not saying this isn’t data we should protect, but it is one we can protect less strongly IMO.


(Justin Thomas) #5

I believe the public/private keys in D* are only used for signing - Conversations (i.e., not intended to be public) are transferred in clear text (unless they are sent over a proper SSL connection).

And authentication credentials could also be captured if SSL were done wrong.

Florian, the only problem with a Diaspora CA would be that no one’s browser would have that already configured as a trusted source. If we could overcome that, it’s not a bad idea.


(raven24) #6

I was thinking our own CA for SSL so we are able to use TLS for federation. But I guess as long as we don’t automate certificate generation with some kind of RPC API and an installer, this would just complicate the setup process.
I view the browser cert issue is a different one, and that should be dealt with by the podmin.

Anyway, personally I don’t like to ‘just allow’ self-signed certs, I guess I’d be ok with CAcert.


(Justin Thomas) #7

Today, the same certificate is used for federation and browser (by virtue of the same web server being used for both). I suspect it would be non-trivial to try to separate those functions.


(Jonne Haß) #8

Justin,


https://github.com/diaspora/diaspora/blob/develop/lib/postzord/dispatcher.rb#L31
https://github.com/diaspora/diaspora/blob/develop/lib/hydra_wrapper.rb#L34
https://github.com/diaspora/diaspora/blob/develop/lib/postzord/dispatcher/private.rb#L11
https://github.com/diaspora/diaspora/blob/develop/lib/salmon/slap.rb#L24
https://github.com/diaspora/diaspora/blob/develop/lib/salmon/encrypted_slap.rb#L64