Server Down?
Well, I tried to get on today, and noticed a message popped up when I tried to log in.
It said the server was temporarly unavailable, or I have no connection. "Ws_ServerReq - - No Server Specified"
It's either the server, or its my account, because I've been getting alot of "Unable to fetch authentication list" or something now, so I have to log in twice to actually get in.
Anyone else getting this?
It said the server was temporarly unavailable, or I have no connection. "Ws_ServerReq - - No Server Specified"
It's either the server, or its my account, because I've been getting alot of "Unable to fetch authentication list" or something now, so I have to log in twice to actually get in.
Anyone else getting this?
Comments
I hope they don't close down Tribes forever!
Yep. The login server used to go down back in the day every now and then, but it gave a different error code.
I'll throw up a server that you guys can join in offline mode by IP tonight.
The BC server you guys can get on from offline mode by adding the IP (Go to the join tab, make sure no queries are running and click in the middle to make it active, then press insert to bring up the IP adding popup):
24.108.140.239:28000
You won't be able to use the clientsaves of course since you won't have a GUID, but if I'm around you can ask me to look for it. If any of the admins wants the admin password you can hit me up through a PM on here, through IRC or one of the messengers.
Such a script would have bundles of other uses too.
That would be great for those morons who like to piss us off by spamming all the time.
On the other hand, those who intend to cause actual harm to the servers and players should be handled with considerably less tolerance.
My plan for an authentication infrastructure replacement is designed primarily around resilience. There will be an "authentication" server, but it would only serve an active role in registration. The clients will have a "trusted" authentication server, and the game servers will have the same "trusted" authentication server.
When a client wants to play on this alternate authentication system, they will create a client "certificate". This certificate is stored encrypted on their computer with their desired password (providing access control). This certificate contains the name they want to use, a unique identification number (similar to GUID), and a set of cryptographic data. The registration process is simply sending the "public" parts of the client certificate (name, UIDN, and the public part of the crypto data) to the authentication server, and having it signed by the authentication server. Some of the cryptography data is private and never transmitted in the plain anywhere.
The authentication server will verify that the name and UIDN is not in use, then send back a digital signature verifying that the client certificate is authorized. Once the certificate is authorized, the client never needs to communicate with the authentication server again. Optionally, the client may upload an encrypted version of their (entire) certificate to the authentication server (in case they lose the copy of the cert on their computer, or don't want to transfer it manually if they play on their system). If the cert isn't uploaded to the authentication server, and it is lost, it will be essentially impossible to recover -- this is by design.
Once a client is registered, and they have an authorized copy of their certificate, they can join any game server that trusts/supports the given authentication server. As part of the join process, the client will send its public certificate to the game-server. The game-server will verify the authentication server signature (through the use of the authentication server's public crypto data) on the client's authorized certificate (to make sure the client didn't forge the certificate) and perform a keyed hash message authentication exchange with the client. Only a client with the private (which is kept secret and secure on the client's computer) part of the certificate will be able to produce the correct response to the keyed exchange.
So, if the client has a certificate that is signed/authorized by an authentication server that the server trusts, and the client has the private part of the certificate (verified by the keyed exchange), the client's name and other data is set according to the value in the certificate.
This explanation is rather long, so I'll break it down by party:
The Client has:
1) Client's private certificate (stored encrypted, requiring their password to decrypt)
2) Client's public certificate (name, UIDN)
3) Authentication server's public certificate.
4) A digital signature on the client public certificate (so others can verify the authentication server accepted the certificate).
The Game Server has:
1) Authentication server's public certificate.
2) Client's public certificate.
The authentication server has:
1) Authentication server's private certificate.
2) Authentication server's public certificate.
3) [Optionally] Password encrypted version of Client's public+private certificate (to allow the client to re-download their certificate if lost).
As part of the joining process:
1) Client sends digitally signed public certificate to game server.
2) Game server verifies digital signature came from authentication server (by using the auth server public key).
3) Game server generates random numeric value (with a time signature) and encrypts it using the client's public certificate.
4) Client decrypts the server's generated random value using the client's private certificate, then sends the decrypted string back to the server.
5) Server checks if decrypted string matches the generated string, and accepts the client's certificate if it does.
It is important to note that with the proper implementation, it is effectively impossible to derive a private key from a public key. If you had 10,000,000 computers, you might be able to crack a private key before the sun burns out. It is this proper implementation that would require a big-integer script with the capability to do fast (under a second or two) modular exponentiation.
This means that it would be impossible to impersonate a client, and would also not require any centralized server for actually playing. If the authentication server vanished off of the face of the planet, anyone with a signed key could continue to login and play without any issues.