BearWare
SSL certificate verification
We can't really add domain verification without a client update, but how about a trusted certificates list and a prompt to trust a new certificate? That way if something changes, the user will know about it and can make an intelligent decision. Right now if someone's SSL cert changed or someone were intercepting my traffic for some reason, I would have no idea.
Server side verification of clients has been merged to master (ssl_verify branch). Client-side support for private-key, certificate and CA file(s) is still pending.
@Simon818 how would you prefer that clients get their private key and certificate? Should users send a client certificate request to you or do you plan to send private key and certificate to clients?
Hmm, I think this should be a system a user can put in place as a login method if they wish and server owners can enforce if they want extra security (much like SSH keys). I wasn't actually thinking about client-side verification when I wrote this, though it is important and something I'd probably put in place. I think if the client could generate--or use--its own set of keys and allow the user to send theirs to an administrator, that would work. Am I misunderstanding? You also know way more about this than I do, so I would welcome your thoughts on how it should or shouldn't work. I just want to make sure it's secure but also easy for non-administrators to deal with and set up. If you can point me at the documentation in question I can also take a look and probably be way more constructive than this.
I've written a guide here on how you configure encryption in the tt5pro server: https://bearware.dk/test/teamtalksdk/v5.6.1.5007/docs/C-API/serversetup.html#ttsrvencrypt
As you can see it's a complicated process to do peer verification.
This issue will not be part of v5.7 since it has to be thought more through how it should be used.
Do I miss-understand if I say the original suggestion was a verification about the domain used to connect? If the certificate is for teamtalk.example.com and I use another host name pointing to the IP which is not par of the common name nor alternative names specified in the certificate, the client would show a prompt to ask for confirmation before connecting.
Auto-signed certificates would show a warning but with Letsencrypt it is possible to have a free signed certificate for the desired host name. IMHO having (and pay) for encryption in server would have more sense if it was not only to encrypt traffic but also to legitimate the host clients are connecting to.
