SSL/TLS is super interesting. Because we often aren't set up to monitor it, it's kind of a black box in terms of performance. Here's some interesting stuff I've found lately:
1. In order to establish a chain of trust, the server is going to be sending your browser at least 2 (server cert, ca) if not more certificates, which contain a fair amount of plain text, so there is some bandwidth overhead here.
2. The most computationally expensive part of SSL setup is the challenge/response key verification step, which generally involves RSA (public/private keys) rather than AES (symmetric keys).
3. SSL session reuse is an interesting feature, on one hand it allows you to skip (2), but if those session keys aren't stored securely server side, it opens up an attack vector. So just remember to make sure those values are as secure as your server's private key.
1. In order to establish a chain of trust, the server is going to be sending your browser at least 2 (server cert, ca) if not more certificates, which contain a fair amount of plain text, so there is some bandwidth overhead here.
2. The most computationally expensive part of SSL setup is the challenge/response key verification step, which generally involves RSA (public/private keys) rather than AES (symmetric keys).
3. SSL session reuse is an interesting feature, on one hand it allows you to skip (2), but if those session keys aren't stored securely server side, it opens up an attack vector. So just remember to make sure those values are as secure as your server's private key.
4. In order to skip (2) many servers such as apache have support for a type of "memcached like" distributed key value store allowing instances to share session data called dc. http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslsession...