I'm working on a web application with simple API needing authentication. For my application nature, users have two RSA keys, for signing and encrypting messages. My protocol works based on it. The web application has access to public keys.

One solution to achieve authentication and kill MITM is to build SSL over the application API and build an authentication method using user's keys. Simple messages passing. But I'm thinking about another method... Make authentication based on SSL client certification. I'd used client certificates for previous projects but I've some problems deciding whether to use it for this project:

  1. Is it bad idea to use one of user RSA keys to generate certificate for it?

  2. Is there any web-server (as SSL wrapper) that can allow me to extend functionalities during SSL negotiation with external program? I mean when user sends SSL request, I look for his certificate in a database (a) and if found insert a record to a database as session ID and the web application use this (b). This means not just give access to some users, but finding out which user is logged in. ANSWER: At-least nginx supports passing received client certificate to the web application. I went by this.

  3. Analysis about performance. I doubt about large number of users and this certificate based authentication performance, but authentication is some part in my application that should be done and SSL is too. What extra load and latency can I expect when using client and server certificates compared to just using server certificates? ANSWER: See MadHatter's answer.

Thanks for your suggestions and sorry for my bad English.

  • I'm afraid the question is not clear. From the comments, it sounds like your real question is: I already have a RSA keypair that I'm using for other purposes, is it OK to reuse it as a SSL client cert? It might help to explain how the existing RSA keypair is already being used (what is it being used for? what applications are using it?). That may affect the answer. Also, you asked multiple questions here (server-side stuff, performance, security, etc.). In the future please separate these out into separate questions.
    – D.W.
    Commented Mar 9, 2013 at 20:05
  • @D.W. Yes. I have a simple protocol that uses RSA keys. This is an application for sending and receiving encrypted messages between parties (two users). Each user checks his inbox (encrypted) by requesting server. Key exchange done by another request to server and stuffs like that.. Keys used for encrypting and signing messages by users since I (The web application) must not see content of messages and make each party sure message received from who.
    – reith
    Commented Mar 10, 2013 at 10:47

1 Answer 1

  1. The normal method of doing client certificate validation is to create your own Certification Authority (CA), and use that CA to mint client certificates, which are distributed to the clients. The server then only has to check that a client certificate has a valid signature from the pre-configured CA, or has a valid chain of trust leading back to that CA, to know that the client certificate is good.

  2. See above.

  3. Very little extra overhead, at least when done as above. All clients have certificates (public keys) anyway, they're just (usually) self-signed and are used only for encryption rather than encryption and authentication; if a client uses a certificate with a valid signature on it instead, having the server validate that certificate is a very small extra overhead.

  • Thanks. I don't explained my concerns well. 1. I heard using same key for both signing and encrypting is a bad idea. My concern was about possible and similar attacks since I must use user's signature (or encryption ) key for negotiating SSL connection without weakening his keys for their main purpose. 2. My real problem was about a software solution to help managing sessions during SSL negotiation, by using DB of user public keys (a part of web software) and marking user as logged in here. This is about moving application layer session management to SSL after CA done his works.
    – reith
    Commented Mar 5, 2013 at 19:23
  • @Reith, I don't understand. Why can't you have users generate a totally new keypair solely for use as a SSL client cert? (I don't see any reason why you need to reuse an existing keypair.)
    – D.W.
    Commented Mar 9, 2013 at 7:49
  • @D.W. That's possible. It's just a metter of managing keys on client application and working with two keys is easier than three keys :) If user wants set passphrase on keys, remembering one password is eaiseer than two password.. Beside this, since I test user's keys during registration procedure, this approach comes to my mind first. Do you know possible attacks on this methodology?
    – reith
    Commented Mar 9, 2013 at 10:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .