XML::RPC encryption

ruby-talk
1

Hi all,

On the topic of encryption, has anyone every tried adding an encryption
layer (if that’s the right term) into XML::RPC? I’m thinking of a
simple public/private key mechanism using openssl, where the server
stores a list of public keys - one per authorized IP address. Clients
would then pass their key as the first argument to any method call so
that the server could authenticate them. Messages passed back and forth
would be encrypted.

Has anyone done this?

If so, how did it affect performance? (I haven’t actually tried it
yet).

Is this something that could be optionally integrated into the main
XML::RPC libs, or is it best left at the application level?

Regards,

Dan

2

Daniel Berger wrote:

Hi all,

On the topic of encryption, has anyone every tried adding an encryption
layer (if that’s the right term) into XML::RPC? I’m thinking of a
simple public/private key mechanism using openssl, where the server
stores a list of public keys - one per authorized IP address. Clients
would then pass their key as the first argument to any method call so
that the server could authenticate them. Messages passed back and forth
would be encrypted.

Has anyone done this?

If so, how did it affect performance? (I haven’t actually tried it
yet).

Is this something that could be optionally integrated into the main
XML::RPC libs, or is it best left at the application level?

Regards,

Dan

Quick addendum: I’m talking about a stand-alone server (in case anyone was
gonna pipe in with Apache, etc).

3

Hi all,

On the topic of encryption, has anyone every tried adding an encryption
layer (if that’s the right term) into XML::RPC? I’m thinking of a
simple public/private key mechanism using openssl, where the server
stores a list of public keys - one per authorized IP address. Clients
would then pass their key as the first argument to any method call so
that the server could authenticate them. Messages passed back and forth
would be encrypted.

Is this really secure? The clients’ public keys are public, so how do
you authenticate them?

The server should first create a random key and send this to the client,
encrypted with it’s (the client’s) public key. So, only the client can
decrypt it (with it’s private key) and extract the random key, which
from now on encrypts the following traffic, using a symetrical
algorithm.

Has anyone done this?

Something very similar: A (simplistic) SOAP authentification service
using tickets.

It behaves as follows:

Client requests a ticket that the server generates randomly.
The client then encrypts this ticket with his password and sends it
back to the server.
Now the server decrypts the ticket and compares it with the original
one, if both are equal, the client is authentificated.

If so, how did it affect performance? (I haven’t actually tried it
yet).

Not tested, as even the encryption algorithm (RC4) is implemented in
Ruby so that the benchmarks would not be very expressive.

Is this something that could be optionally integrated into the main
XML::RPC libs, or is it best left at the application level?

XMLRPC::Client supports SSL, but only on a low-level.
I don’t think that integrating it into XMLRPC would be a good idea.
But it should be no big thing to add to an existing application. The
service methods, for example, could be wrapped using AspectR where the
first argument is taken and used for authentification. Similarily on the
client side, where you could create a Client::Proxy instance, passing it
the public-key as argument, which will then be prepended to every method
call performed on that proxy object.

Regards,

Michael

···

On Tue, 2002-11-05 at 21:57, Daniel Berger wrote:

4

Not confuse folks with the similarity of our names… :wink:

…but I believe folks have used TLS (SSL replacement) for this…

And I suspect, based on how others have treated it that it would not be directly incorporated… of course, no one is writing APIs with encryption in mind (as you propose) but I’m also not sure there any great benefit to doing it that way.

d.

···

Daniel Berger wrote:

Hi all,

On the topic of encryption, has anyone every tried adding an encryption
layer (if that’s the right term) into XML::RPC? I’m thinking of a
simple public/private key mechanism using openssl, where the server
stores a list of public keys - one per authorized IP address. Clients
would then pass their key as the first argument to any method call so
that the server could authenticate them. Messages passed back and forth
would be encrypted.

Has anyone done this?

If so, how did it affect performance? (I haven’t actually tried it
yet).

Is this something that could be optionally integrated into the main
XML::RPC libs, or is it best left at the application level?

Regards,

Dan

Quick addendum: I’m talking about a stand-alone server (in case anyone was
gonna pipe in with Apache, etc).

5

Sounds like what you really want is certificates. Each client has a private
key, and presents its certificate on connecting to the server. On the server
you either keep the public key of the CA which signed the certificates, or
allow the clients to present self-signed certificates (in which case you
keep one certificate for each client, or just the fingerprints of those
certificates). Either way, you have proved that the client has a trusted
private key, without actually sending it over the wire.

All that's standard TLS functionality from openssl, and is likely to be much
more secure than rolling your own crypto authentication mechanism.

···

On Wed, Nov 06, 2002 at 07:05:07AM +0900, Michael Neumann wrote:

> I'm thinking of a
> simple public/private key mechanism using openssl, where the server
> stores a list of public keys - one per authorized IP address. Clients
> would then pass their key as the first argument to any method call so
> that the server could authenticate them. Messages passed back and forth
> would be encrypted.

Is this really secure? The clients' public keys are public, so how do
you authenticate them?