On 2009-10-22 12:09 PDT, Ambroz Bizjak wrote: > On Oct 22, 7:22 pm, Nelson B Bolyard <nel...@bolyard.me> wrote: >> What kind of system? What CPU? What clock speed? What memory speed? >> >> Are you doing client authentication with a client certificate? >> Are you using Diffie-Hellman Ephemeral cipher suites? >> 100ms is indeed a long time if you're not.
> My program is acting as a server which requires client authentication. > I've generated all certificates with certutil without requesting any > specific ciphers, so they are RSA 1042 bit. In the server I also don't > override any defaults. Does that mean you're using only export cipher suites? What cipher suite(s) are your connections actually using? > On average, the complete handshake in local network takes about 400 ms. > I've noticed this is considerably greater than on other systems I have. > With the server program running on an AMD Sempron 2800 (1.8 GHz), > complete handhshake takes only about 50ms (though it is 64-bit while my > Atom system is not). I find this surprising; perhaps there is some > performance regression with Atom processors? I know the board is > relatively low-performance, but is really that slow? Yes, CPU multiplication performance alone could account for much of it. Make sure you're not doing unnecessary stuff. Disable all export cipher suites. Disable all export suite support. Use SSL_NO_STEP_DOWN. >> A reactor? What's that? (nuclear? :) > It's the part of the program that blocks on all resources and calls > associated handlers when > an operation can be performed without blocking; no nuclear reactions > involved :) see http://en.wikipedia.org/wiki/Reactor_pattern Oh, a new name for the oldest server software design pattern of all. :-/ > I went through the handshake with a debugger and found the following: > - when a new client is accepted, SSL_ConfigSecureServer takes about > 200 ms. > - the first SSL_ForceHandshake is fast; I assume it receives some data > from the client and requests a certificate > - the second SSL_ForceHandshake takes about 200 ms. This is probably > because it's verifying the client's certificate. That's a public key operation, which shouldn't be too slow. The private key operations are what usually hurt, and if you're doing export cipher suites with a 1024 bit key in your cert, then you're doing TWO private key operations for each full handshake. > I think I could get rid of the SSL_ConfigSecureServer delay by first > performing it on a dummy SSL file descriptor and pass it as a model to > SSL_ImportFD for every accpeted client. Yes, that's exactly what you should be doing. > But what's with the SSL_ForceHandshake delay? Lots of slow multiplication, I suspect. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
