We are planning to use 2 way ssl instead of username/password token for authentication. Does anyone know what is the performance penalty for using 2 way SSL?
If by "2-Way" you mean "SSL with certificate-based client authentication", then you can expect the following overhead:
- Server sends a
CertificateRequestmessage which contains the list of the names of the root CA that the server will use to validate the client certificate. Depending on the list of such CA, this message may have a non-negligible size (say 10 kilobytes). Of course, in any reasonable setup, the server should accept only one or two CA, leaving this message size way below 1 kilobyte (but many Windows/IIS are not very reasonable).
- Client sends its certificate as part of a chain. Typical size of a certificate is 1 to 2 kilobytes, and the client chain will contain between 1 and 4 certificates (it may contain more, but if it does, then you are doing weird things with your PKI).
- Client will compute a signature, and the server will verify the signature. On a basic PC, with RSA, signature generation time will be a few milliseconds, and verification will be at least 20 times faster than that. If the client uses a smartcard, then signature generation time will probably be around 1 second or so (main bottleneck is I/O speed with the card).
- The signature from the client is also sent by the client (around 260 bytes for a 2048-bit RSA).
The client authentication with certificates incurs no extra roundtrip, but it does mean some more data during the initial handshake (as explained above, up to a few dozens of kilobytes) and some extra CPU (in amounts similar to what the server must compute anyway). Once these certificate games have been played, the rest of the connection is identical to what would occur without a client certificate. No further impact.
- Once a client and a server have done one handshake with certificates, they both know a shared secret, which they can reuse. Further connections will use the abbreviated handshake which implies no asymmetric cryptography, and is faster (in particular, one less network roundtrip). This keeps the overall cost low in a typical server.
- In many setups, certificate-based client authentication is done with a renegotiation: the client first connect "anonymously" to the server, and then the server asks for a new handshake within the connection, this time with a client certificate. This is often needed in an HTTPS context, because the server will learn the target URL only when the first handshake has been completed, and only then will the server know that the client wants to reach a part of the site which requires client authentication with certificates. With a renegotiation, the second handshake means two extra network roundtrips.
Login+password authentication has bigger overheads because you will have to send a redirection to a login page, and then verify the password. The processing of the login page, the extra graphical interface work on the client, and the slow hashing on the server for password verification, will incur network and CPU overheads which totally dwarf out the costs for client certificates. Thus, switching from login+password to certificates is likely to lower network and CPU costs on your server.
(But certificates mean certificate management and PKI, and that's again much bigger costs.)
Client certificates are used for authentication and key negotiation in SSL. A session key is still used, thus their should be no difference after a connection is established. I'm not sure how much, if any, penalty there would be for the authentication phase, but I wouldn't expect it to be significant compared to having to run a secure hash on a password. It may well be faster.