HTTP based authentication/encryption protocol in a custom system

views:

answers:

+1 Q:

HTTP based authentication/encryption protocol in a custom system

+2 A:

Don't re-invent the wheal, use HTTPS.

The server can issue certificates to the client and store them in the Database. Clients can be distributed with the server's self-signed certificate for verification. The server can verify clients by using Apache's HTTPS Environment Variables.

Rook 2010-07-08 15:49:11

HTTPS isn't as flexible as is needed in our system.

kuratkull 2010-07-08 16:00:58

@kuratkull everything supports it, its 100% free, and most of all its secure.

Rook 2010-07-08 16:56:25

Like I said in response to Justice:I'm getting mixed responses on Python/Apache mutual SSL authentication possibilities. I would need it to work so that I distribute the PubKey to the clients beforehand and then the clients ONLY use that pubkey when they are trying to contact the server. The pubkeys cannot be personalised[eg. many clients have to be able to use the same pubkey]. Is it possible? And a third-party certificate authority is out of the question... the client side MAY NOT have access to outside networks. + It cannot be hard/frustrating to set up.I don't believe this is supported.

kuratkull 2010-07-08 17:09:17

@kuratkull If its only a client<->server model then a full blow PKI isn't necessary you can store the certificates in the database and the server could issue them to the client. On the apache side you can verify client certificates using environment variables (http://httpd.apache.org/docs/2.0/mod/mod_ssl.html)

Rook 2010-07-08 17:30:36

@kuratkull The client can have the server's https public key hard-coded for verification, a 3rd party isn't necessary.

Rook 2010-07-08 17:32:59

@The Rook - Very nice @"verify client certs" :)I also thought about distributing the pubkey fingerprint with the client, so the client can not not be MITM'ed. The client will then provide the server its RegKey in the SSL session for client authentication.Very nice. Thanks a bunch.

kuratkull 2010-07-08 17:41:07

@kuratkull your welcome, I'm happy to help.

Rook 2010-07-08 17:55:59

+1 A:

I don't think RegistrationKey adds any real security.
It needs more nonces (against replay attacks).
It needs more padding (or else the messages are small and thus easy to decrypt).
An algorithm can be proven to be secure, you may want to do this.
Most flaws in crypto are in the implementation, not in the algorithm (timing attacks, for example).

Sjoerd 2010-07-08 16:00:08

RegistrationKey is needed since only clients with the key can register.Nonces will be added in the process.Padding will be achieved with nonces, etc.Proven secure? Nice, will look into it.This is my own algorithm...so both are possible ;)

kuratkull 2010-07-08 16:03:59

+2 A:

No. Use SSL. Reinventing cryptosystems is a bad idea.

What you can easily do is set up a reverse proxy. Run your Django app on a higher port (e.g., 8080) and set it to respond only to connections from the loopback address (127.0.0.1). Run the reverse proxy on port 443 (standard HTTPS port) and proxy all requests to the Django app. But setup the reverse proxy with the site's certificate and have it be an SSL endpoint. The proxied requests going to the Django app would then just be "regular old" HTTP, not HTTPS.

Apache Mod_Proxy

NginX as a Reverse Proxy

Justice 2010-07-08 16:00:26

I'm getting mixed responses on Python/Apache mutual SSL verification possibilities. I would need it to work so that I distribute the PubKey to the clients beforehand and then the clients ONLY use that pubkey when they are trying to contact the server. Is it possible?And a third-party certificate authority is out of the question... the client side MAY NOT have access to outside networks.

kuratkull 2010-07-08 16:32:09

ansaurus

tags:

views:

answers:

HTTP based authentication/encryption protocol in a custom system

related questions