Self-signed server certificates

[mkrautz]

The way we currently handle self-signed server certificates is pretty cumbersome. Ideally, what we'd like to do is this:

• First time a user connects to a server with a self-signed certificate, tell the user what happened and allow the user to accept or deny the certificate.
  • If the certificate was accepted, store it in a "servers" table along with a hostname/port combo. (This should probably also be done on servers with a CA signed certificate, so we can detect certificate changes).
  • If it wasn't accepted, drop the connection.
• Next time a user connects to that server, we tell MumbleKit to not verify the certificate chain of the server. Instead, when the TLS handshake is done, we'll do the verification we need ourselves.
  • Check that the certificate chain correspond to the one we've stored in the database.
  • Check the notAfter and notBefore dates of the certificate.
  • Check the common name / subject alt names whether they match the hostname.
  • (More?)
• If all of these pass, log in the user. If not, show an appropriate error message.

[mkrautz]

This is basically implemented now, with a few changes.

• First time a user connects to a server with a self-signed certificate, they're presented with a dialog that allows them to:
  • Ignore it (and connect anyway)
  • Trust it (store its SHA1 digest in the DB)
  • Cancel (do nothing)
• If a certificate has been "trusted" by a user, it is (as noted above) stored in the DB. Next time the user connects to the server (and is told that the OS could not verify the authenticity of the certificate chain), it will try to match the server's leaf certificate hash with what's stored in the DB.
  • If it matches, great! Let the user in by ignoring SSL verification errors on the connection, and reconnecting.
  • It it doesn't match, present a dialog similar to the one they were presented with in the first place, but now telling them that the certificate hash of the server does not match the one stored on our DB.

We don't perform any validation of our own on the certificate chain once it's been marked as "trusted" by the user. Maybe we should. (Something that comes to mind is to verify that the notBefore date is not in the future before we store the cert in the DB, and to verify that the notAfter date isn't exceeded when silently connecting to "trusted" server...)