The "new" Yggdrasil auth is being developed, and it begs answers to a few questions:
1. Do we want the auth server and URL settable in the config?
2. Should we do any SSL cert checking / protection?
Ad 1: I don't think this "feature" is worth it, is there anyone at all who uses an alternate server for auth? It'd need to be a complete community who use a modified client (so that it connects to the alt server, too). Somehow, I don't think this is happening at all.
Ad 2: There are basically two approaches to verifying the authenticity of a cert: Either verify that it is signed by a third party - that's what a normal web browser does when you connect to a HTTPS server, the browser has a list of "trusted root certificates" that it uses to verify the authenticity of the site's certificate. We don't have such list yet.
Another approach is used by SSH - it calculates the fingerprint of the certificate and if it doesn't match a fingerprint it has for the server (either connecting for the first time, or the cert has changed) it asks the user whether to trust that certificate or not.
The problem is that the first approach is very difficult to get right and if you don't get it right, you'll have vulnerabilities in your code. The second approach needs user interaction, which is something MCS cannot do, really.
I've come up with a solution that could work for us using the second approach: Let MCS store the "trusted" fingerprint of the HTTPS cert in the settings.ini file (we can put the correct fingerprint there and maintain it if it changes, in the source repo). Then when a cert is received that doesn't match the fingerprint, the server will output a big fat red warning to the log and shut down (better shut down than run in offline mode). The warning itself will provide instructions for the admin to insert the new fingerprint (also shown in the warning) into the settings.ini file, if they trust it.
So what are your thoughts?
As for the cert chain verification pitfalls, a nice read is here: http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf
1. Do we want the auth server and URL settable in the config?
2. Should we do any SSL cert checking / protection?
Ad 1: I don't think this "feature" is worth it, is there anyone at all who uses an alternate server for auth? It'd need to be a complete community who use a modified client (so that it connects to the alt server, too). Somehow, I don't think this is happening at all.
Ad 2: There are basically two approaches to verifying the authenticity of a cert: Either verify that it is signed by a third party - that's what a normal web browser does when you connect to a HTTPS server, the browser has a list of "trusted root certificates" that it uses to verify the authenticity of the site's certificate. We don't have such list yet.
Another approach is used by SSH - it calculates the fingerprint of the certificate and if it doesn't match a fingerprint it has for the server (either connecting for the first time, or the cert has changed) it asks the user whether to trust that certificate or not.
The problem is that the first approach is very difficult to get right and if you don't get it right, you'll have vulnerabilities in your code. The second approach needs user interaction, which is something MCS cannot do, really.
I've come up with a solution that could work for us using the second approach: Let MCS store the "trusted" fingerprint of the HTTPS cert in the settings.ini file (we can put the correct fingerprint there and maintain it if it changes, in the source repo). Then when a cert is received that doesn't match the fingerprint, the server will output a big fat red warning to the log and shut down (better shut down than run in offline mode). The warning itself will provide instructions for the admin to insert the new fingerprint (also shown in the warning) into the settings.ini file, if they trust it.
So what are your thoughts?
As for the cert chain verification pitfalls, a nice read is here: http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf