server). It can then be used to encrypt further data during the session.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6492 542714f4-19e9-0310-aa3c-eee0fc999fb1
{Client.setRequireSecureAuth} then if the client fails to create a secure channel with the server,
an auth request with no credentials will be sent. The supplied Authenticator will need to handle
this situation to send the appropriate response back to the client (ie: tell it to download the
latest version).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6480 542714f4-19e9-0310-aa3c-eee0fc999fb1
when sent to the server.
To implement a secure authentication channel:
- Create a key pair using the com.threerings.presents.tool.KeyPairGen tool. You will need to
distribute the public key with your client, and the private key with the server.
- On your server during initialization, use PresentsConnectionManager.setPrivateKey to set the
private key. It can take the key string gerenated by KeyPairGen. This will return true if the
key was sucessfully set and the server supports the encryption necessary.
- On your client before authenticating, use Client.setPublicKey to set the public key. As with
setPrivateKey, it will return true if the client supports the encryption necessary.
That's it! You should now be authenticating over a secure encrypted channel. The server can
still accept unsecured authentication attempts (for the purpose of telling the client it needs a
new version to get the server's public key). A failure to decrypt the client credientials on the
server will return a new "m.failed_to_secure" authentication code.
Handshake process:
- The client generates a random 128-bit key, and encodes it with the public key using a 32-bit
salt (PublicKeyCredentials). This is sent to the server as a SecureRequest.
- The server decrypts the i128-bit key using its private key and verifies it against the salt. If
verification fails, a failed secure response is returned and the client will authenticate over a
clear channel. If verification succeeds, the server generates a random 128-bit AES key and
encodes it with the 128-bit key sent from the client. This is sent back to the client as a
SecureResponse.
- The client will decode the AES key sent from the server (using the random key it generated at
the start of the handshake). Using the AES key, the client will encrypt their credentials using
an AESAuthRequest and send it to the server.
- The server can now decrypt the credentials from the client and pass the AESAuthRequest to the
configured authenticators to complete authentication. If the server fails to decrypt the
credentials a "m.failed_to_secure" authentication code is returned to the client.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6477 542714f4-19e9-0310-aa3c-eee0fc999fb1
calls on the Java side, to match this added convenience we introduced to the
ActionScript side some time ago.
Before arms are raised into the air and waved like they really do care, bear
the following in mind:
Nothing will change at all on your project until you take some action to do so.
That action could include any of the following:
1. Continue to use narya-tools-1.2 to run genservice and you'll get the old
style "pass a Client reference for every service method invocation" marshallers
and you can continue to live happily in the past.
2. Leave some of your stuff un-regenerated, but generate new stuff using the
new tools and use the Client-reference-free style for new services. This is
likely to engender some PITA if you're trying to use both styles in the same
project because genservice just wants to operate on everything, but I offer it
as an option in case some other PITA motivates the tolerance of this
(presumably smaller) PITA.
3. Embrace the brave new world of simplicity and wield your good friend sed for
fun and profit:
(make necessary build.xml updates to start using narya-tools-1.4-SNAPSHOT)
% find src -name '*Service.java' | xargs sed -i 's:Client client, ::g'
(this will remove the Client argument from most of your services, some manual
fixes may be needed)
% ant genservice
% find src -name '*.java' | xargs sed -i 's:_ctx.getClient(), ::g'
(this will fix most of the places that pass a client reference into an
invocation service, some manual fixes will probably be needed)
I did this on Vilya and it magically took care of like 95% of the places where
changes were needed. The remaining half dozen changes were painless. Clearly
something like Yohoho vastly dwarfs Vilya in scope, but someone looking for an
hour or two of mindless typing to distract them on a lazy Sunday afternoon
would likely breeze through even that vast codebase without breaking a sweat.
Two more notes:
1. I'm going to switch Narya and Vilya over to the new style, and I'll be
fixing all the projects that use their services.
2. I lied (a teeny bit) about nothing changing. I made the old Client-taking
sendRequest methods deprecated, so projects that don't switch to the new style
will be presented with a large number of deprecation warnings. If this is too
terrible a burden to bear, I can remove the deprecation annotations on those
methods.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6395 542714f4-19e9-0310-aa3c-eee0fc999fb1
errors with duplicate receiver entries on reconnect in Spiral Knights, and
I'm hoping this will fix them.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6301 542714f4-19e9-0310-aa3c-eee0fc999fb1
ActionScript bits remain belligerent, but the Java stuff is mostly shipshape.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6222 542714f4-19e9-0310-aa3c-eee0fc999fb1
Dave Hoover