Using firebug, you can see that something is seriously strange with tlwebadm. Most of the time is spent before the browser can send the request, i.e. during socket handling, process forking and TLS handshake. We should have a look at what's going on here.
I've noticed a couple of issue with the current code: a) We don't support TLS session caching b) The upstream example (which we used as a base) has changed pretty severely and now uses a different DH strategy and has removed support for the old broken-by-design "export" cryptos. These things might explain the problem.
(In reply to comment #1) > I've noticed a couple of issue with the current code: > > a) We don't support TLS session caching Found an interesting primer on this which might be helpful: http://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5077.html
Updated to the latest example code in r23602.
We might want to reconsider having any kind of session cache as it could cause problems for perfect forward secrecy. Need to investigate with care.
