Hi Justin, On Tue, Sep 04, 2012 at 09:45:39AM -0700, Justin Karneges wrote: > Usually, the most expensive operations in TLS are the public key ones at the > start of a negotiation (and possibly a renegotiation, though I'm not sure of > protocol details there). However, pretty much all other TLS traffic should be > fast to execute. I wonder if there is a way to differentiate these steps? > This > is how you'd ensure that a bunch of new https connections do not cause > slowdown of existing https connections.
I'd say that differently that TLS negociation is horribly slow and that the rest of the traffic is less slow. The performance ratio usually is in the order of 1/5 to 1/10 between TLS and clear. Even SSLv3 is much faster than TLSv1 without any renegociation (2000 vs 1200 TPS). I remember that SSL offloaders years ago used to degrade the SSL connection going to backend servers in order to make them work less. > I have tried in the past to use OpenSSL in an event-driven application in a > way that does not block the event loop. This was for a local desktop > application that used smart cards, where an OpenSSL call might block for 5 > seconds while it hits the hardware. Since the expected number of TLS sessions > in the application was small, I simply made one thread per TLS session, and > funneled all results back to the event-driven main thread. Of course a thread > per connection approach would not work if you want to handle thousands of > connections like HAProxy. One day I wanted to go back and rewrite my code > such > that I could send operations to separate threads or keep them in the main > thread based on a given TLS session state. This way, I could make it so only > the TLS handshakes (with the expensive RSA operations and such) would need > concurrency. Then the number of threads needed would be the number of > expected > simultaneous handshakes, which would be a far more manageable number (20?) > than expected simultaneous sessions (thousands). This is an interesting way of improving the behaviour for renegociations indeed. I'm not sure it's easy to implement in haproxy but I think that the principle of leaving all the TLS work in a dedicated process is already quite efficient and acceptable. > This is not an answer for you, but just a brain dump of my thoughts on the > subject. Your brain dump is welcome :-) Willy
