Yggdrasil Auth

[xoft]

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

[tigerw]

Let MCS store the trusted fingerprint in the executable? Extra settings that no one will ever change apart from the developers I think will only confuse users.

[xoft]

The fingerprint changes at least every year - the certificate validity is limited to 1 year for regular HTTPS certs.

[daniel0916]

I think the setting of the server and adress is unnecessary. New members think maybe they need to modify anything etc..
My PR is now also compiling. When i should delete the config option then say it.

[worktycho]

For verifying the certificate polarssl can do most of it for you so I don't think it would any more dangerous than the rest of the ssl systems.

[xoft]

PolarSSL can do it *if* you give it the root CAs to verify against, and the CRLs. We don't have those and I'm not sure if all the platforms we support even have any of those system-wide. That's the problem with certs - you need infrastructure around them.

[tigerw]

If the fingerprint has to be updated occasionally, it is even better to put it in the executable since developers can easily update it without having to rebuild the config or add extra code to selectively modify the config.

[xoft]

The devs can modify it, but it means that your executable needs to be rebuilt each time. Can you imagine the people swarming our forum each time the cert changes, saying "my server stopped working, do something!"
Much better if you give them the chance to fix it themselves.

[worktycho]

Root certificate is Starfield Technologies, Inc. The Certs can be downloaded here: https://certs.starfieldtech.com/anonymou...sitory.pki. Then use the polarssl parse cert function to parse it. It's valid until 2034 and I suspect mojang will change something between now and then.

[bearbin]

Also, is it possible for the servers to have multiple valid certificates?