3 ms·
I'm implementing a similar solution. My only concern is that the ssl handshake takes an anywhere been 600 and 1000ms - far too long as far as I'm concerning. do
by strooltz 16y ago
I'm implementing a similar solution. My only concern is that the ssl handshake takes an anywhere been 600 and 1000ms - far too long as far as I'm concerning. does anyone have a suggestion to improve this?
My setup
1) Linode $20/mo REE box (will bump up in production)
2) Nginx
3) RoR 3.0.3
4) SSL Through Geotrust. It is a "chained" cert but i don't believe this is the bottleneck.
thanks in advance...
- WALoeIII 16y agoYour chained cert might actually be the bottleneck if the total data exceeds 4K and the user has to do a second round trip to ACK the cert. http://journal.paul.querna.org/articles/2010/07/10/overclocking-mod_ssl/ http://journal.paul.querna.org/articles/2010/07/10/overclock... Basically, unless you are certain you need it 4096 bit security, use a 2048 bit key (1024 is not secure anymore) and only include the minimum number of intermediate certs you can get away with. OSCP stapling doesn't seem worth it if it cause you to over flow the initial TCP window.
- strooltz 16y agothis is a really great piece of advice. i'll check this out.
- agl 16y agoOCSP is probably the bulk of that time. On Chrome Linux you can start a fresh instance, load the HTTPS page then open a tab with about:histograms and search for OCSP. The time taken should be in there. (Otherwise, use a packet sniffer and don't forget to account for the DNS lookup too.) OCSP stapling is the best answer, although one can only staple a single response and many chains these days require two responses. So a better answer is to get a CA which issues certificates with 24-48 hour validity and doesn't use an out of band revocation system. If you can find such a thing, please tell me where.