21

I have an HTTPS website and I want to reduce the SSL time of this website. The SSL certificate has been installed on AWS ELB.

If I access the site from Netherlands, the SSL Time is high but if I access the same site from other countries then the SSL time is low. Why is that?

I am basically trying to minimize the time which is showing in this page

http://tools.pingdom.com/fpt/#!/ed9oYJ/https://www.google.com/index.html

user3847894
  • 986
  • 4
  • 16
  • 37
  • Are you sure it's because of SSL? Have you tried comparing the plain HTTP response times? The difference could simply be because the site is being served off of a CDN in NL. –  Apr 17 '16 at 04:24
  • We are not using CDN in our website and I compared the site load time using pingdom website(http://tools.pingdom.com/fpt/) and there it is showing the SSL load/handshake time. – user3847894 Apr 17 '16 at 04:35
  • I checked our SSL certificate as well and I don't find any issues. – user3847894 Apr 17 '16 at 04:37
  • Can you share more info? What webserver, is there a cdn, what AWS region? – tedder42 Apr 17 '16 at 05:05
  • @tedder42, we are using jetty server and the AWS region is North Virginia. We are not using any CDN for this website. There is one ELB on which SSL certificate has been installed and there are two jetty server behind the elb. – user3847894 Apr 17 '16 at 14:05
  • 1
    Define "high"? A few hundred milliseconds is normal. Which other countries, how are you testing it, how can you see it's slower and by how much? – Barry Pollard Apr 18 '16 at 14:52
  • @BazzaDP, I have edited my post and pasted the link of the tool that I am using to test this. I tried to access the site from Australia, US, Netherland etc. The SSL time from Netherlands is 180 ms but in other countries it is below 40 ms. – user3847894 Apr 18 '16 at 16:30
  • SSL time of 180ms really is not a lot and doubt you'll get any better between Europe and North America! I really think you must have a super time critical app if this is causing a problem and a super optimised site if this is where you think you can make any significant performance gains! I would also guess that 40ms is nowhere near representative of the ssl time your real users are experiencing and for that number are caught chasing artificial numbers just for the sake of chasing numbers. If you were experiencing delays of 10 times that or more it may be worth optimising but not for 180ms. – Barry Pollard Apr 18 '16 at 18:08

3 Answers3

30

Many things influence the SSL time including:

Infrastructure (this won't affect just SSL but ALL network traffic):

  • Standard network issues (how far away your server is from client, how fast the network is in between... etc) as the SSL/TLS handshake takes several round trips. You have little control over these except changing hosting provider and/or using a CDN. AWS is, in my experience fast and you are only asking to improve SSL rather than general access times so maybe skip this one for now.
  • Server response time. Is the server under powered in CPU, Ram or disk? Are you sharing this host? Again general issue so maybe skip past this but SSL/TLS does take some processing power though, with modern servers it is barely noticeable nowadays.
  • Server OS. Newer is better. So if running Red Hat Linux 4 for example then expect it to be considerably slower than the latest Red Hat Linux 7, with improved networking stack and newer versions of key software like OpenSSL.

SSL set up (run your site through https://www.ssllabs.com/ssltest and you should get a state of health of this):

  • Ciphers used. There are older and slower ciphers and faster and new ones. Can get complicated here really quickly but generally you should be looking for ECDHE ciphers for most clients (and preferable ECDHE...GCM ones) and want to specify that server order should be used so you get to pick the cipher used rather than the client.
  • Certificate used. You'll want a RSA 2048 cert. Anything more is overkill and slow. Some sites (and some scanning tools) choose RSA 4096 certificates but these do have a noticeable impact on speed with no real increase in security (at this time - that may change). There are newer ECDSA certs (usually shown as 256 EC cert in ssllabs report) but these faster ECDSA certs are not supplied by all CAs and are not universally supported by all clients, so visitors on older hardware and software may not be able to connect with them. Apache (and very recently Nginx from v 1.11.0) supports dual certs to have best of both worlds but at the expense of having two certs and some complexity of setting them up.
  • Certificate Chain. You'll want a short certificate chain (ideal 3 cert long: your server, intermediary and the CAs root certificate). Your server should return everything but the last cert (which is already in browsers certificate store). If any of the chain is missing, some browsers will attempt to look the musing ones but this takes time.
  • Reliable cert provider. As well as shorter cert chains, better OCSP responders, their intermediaries also are usually cached in users browsers as they are likely to be used by other sites.
  • OCSP Stapling saves network trip to check cert is valid, using OCSP or CRL. Turning it on won't make a difference for Chrome as they don’t check for revocation (mostly but EV certificates do get checked). It can make a noticeable difference to IE so should be turned on if your server supports them but do be aware of some implementation issues - particularly nginx’s first Request after restart always fails when OCSP Stapling is turned on.
  • TLSv1.2 should be used and possibly TLSv1 .0 for older clients but no SSLv2 and SSLv3. TLSv1.1 is kind of pointless (pretty much everyone that supports that also supports the newer and better TLSv1.2). TLSv1.3 is currently being worked on and has some good performance improvements but has not been fully standardised yet as there are some known compatibility issues. Hopefully these will be resolved soon so it can be used. Note PCI compliance (if taking credit cards on your site) demands TLSv1.2 or above on new sites, and on all sites by 30th June 2018.

Repeat visits - while above will help with the initial connection, most sites require several resources to be downloaded and with bad set up can have to go through whole handshake each time (this should be obvious if you're seeing repeated SSL connection set ups for each request when running things like webpagetest.org):

  • HTTP Keep-Alives should be turned on so the connection is not dropped after each HTTP Request (this should be the default for HTTP/1.1 implementations).
  • SSL caching and tickets should be on in my opinion. Some disagree for some obscure security reasons that should be fixed in TLSv1.3 but for performance reasons they should be on. Sites with highly sensitive information may choose the more complete security over performance but in my opinion the security issues are quite complex to exploit, and the performance gain is noticeable.
  • HTTP/2 should be considered, as it only opens one connection (and hence only one SSL/TLS setup) and has other performance improvements.

I would really need to know your site to see which if above (if any) can be improved. If not willing to give that, then I suggest you run ssllabs test and ask for help with anything it raises you don't understand, as it can require a lot of detailed knowledge to understand.

I run a personal blog explaining some of these concepts in more detail if that helps: https://www.tunetheweb.com/security/https/

Wade Williams
  • 3,943
  • 1
  • 26
  • 35
Barry Pollard
  • 40,655
  • 7
  • 76
  • 92
  • What about ECDSA certificates ? – Tom Apr 17 '16 at 19:31
  • Mentioned them as "256 EC" certificate. Will edit to note the ECDSA name though. They are not commonly available nor universally supported yet though. – Barry Pollard Apr 17 '16 at 19:35
  • You're right, I've read too fast. They are not universally supported but by all modern browsers : https://community.letsencrypt.org/t/elliptic-curve-cryptography-ecc-support/34/12?u=tdelmas and Let's Encrypt will soon deliver them (or maybe they do already?) and at least one commercial CA. – Tom Apr 17 '16 at 19:47
  • 1
    Yeah but whether AWS ELB does is another thing. LE has literally just added them and only when you generate the CSR on your side so not fully supported there. And also would restrict access to older clients (e.g. older android and XP/IE8). They are good, client support is surprisingly good and do think they're the future. But not quite there yet - especially given poor server support of running dual certs. – Barry Pollard Apr 17 '16 at 20:05
  • @BazzaDP, Currently we are in EC2 classic so will it make any difference if we move to VPC? – user3847894 Apr 18 '16 at 11:27
  • @BazzaDP, Sorry I can't disclose my website. Does CDN, really going to make difference in ssl load time or in general site load time? In our case I didn't find any issues with RAM and CPU usage. We do have servers launched in 2010 so like you suggested we need to have a new ec2 machines. Can we enable OCSP Stapling in AWS ELB? We do have SSLv2 and SSLv3 on otherwise old browsers will not able to open our website. Keep alive is on in our case and we will consider using HTTP/2. In the meantime I am also checking ssllabs test for any clue. – user3847894 Apr 18 '16 at 14:35
  • Can you include a redacted copy of the SSL labs report? It's the best source of SSL info. Everything else is really down to general site load time. – Barry Pollard Apr 18 '16 at 14:50
2

You say that you're not using a CDN, but I believe you should be. Here's why:

Connecting via TLS/SSL involves handshaking a secure connection, and that requires extra communication between the client and server before any data can begin flowing. This link has a handy diagram of the SSL handshake, and this link explains the first few milliseconds of an HTTPS connection.

Jordan Sissel wrote about his experiences with SSL handshake latency:

I started investigating the latency differences for similar requests between HTTP and HTTPS. ... It's all in the handshake. ... The point is, no matter how fast your SSL accelerators (hardware loadbalancer, etc), if your SSL end points aren't near the user, then your first connect will be slow.

If you use a CDN, then the handshaking can be done between the client and the nearest edge location, dramatically improving the latency.

Mattias Andersson
  • 2,331
  • 1
  • 17
  • 27
  • so you are saying we should use CDN in front so that the traffic flow would be from CDN to ELB then to EC2. Where should I keep my SSL certificate then? Should it be on ELB or on CDN? – user3847894 Apr 18 '16 at 11:19
  • Previously I tried this setup(Request-->CDN-->ELB--->EC2) but it does not seem to solve my problem – user3847894 Apr 18 '16 at 16:31
  • If you choose to just us another server as a CDN you may find this helpful. It is what I used to upload wildcard certificates in Plesk https://stackoverflow.com/questions/76329006/automate-certificate-uploads-into-plesk-using-selenium-ide-not-working – MeSo2 Aug 10 '23 at 16:37
2

You can try ECDSA certificates: https://scotthelme.co.uk/ecdsa-certificates/

But the cost of https is only visible on the first requests: session tickets avoid that cost for all other requests. Are they activated? ( you can check it with ssllabs.com )

If you can you should use SPDY or http2, it may improve the speed too.

ECDSA keys, SPDY and http2 reduce the number of round trip necessary so it should reduce the difference between the two location.

Tom
  • 4,666
  • 2
  • 29
  • 48
  • Those are interesting ideas, but none of them seems to address the key geographical factor being asked about in the question: "If I access the site from Netherlands, the SSL Time is high but if I access the same site from other countries then the SSL time is low." – Mattias Andersson Apr 17 '16 at 19:19
  • @MattiasAndersson I've add a clarification about that point. With these optimisations the numbers of roundtrip and the size of the requests should be close (or fewer) than http. His question was specifically about https but yes, in general, even for an http website, being closer to the visitors helps. – Tom Apr 17 '16 at 19:29
  • 1
    I'd also add that there is far too little detail in OPs question to address the geographical factor. How do we know they are like for like comparisons? – Barry Pollard Apr 17 '16 at 19:42
  • @Tom, I will try your suggestion for http2 or SPDY. Regarding the use of ECDSA certificate I am bit confused as I was comparing our website with two other website and they both are using the similar certificate as that of us. – user3847894 Apr 18 '16 at 10:58
  • @Tom, Are our customers with old browsers will be able to connect to the ELB if I use ECDSA certificate? – user3847894 Apr 18 '16 at 11:22
  • @user3847894 sadly no : windows xp and really old android will probably fail https://community.letsencrypt.org/t/elliptic-curve-cryptography-ecc-support/34/12?u=tdelmas – Tom Apr 18 '16 at 16:00
  • 1
    As better stated in Barry's answer, either caching _or_ tickets (and best both) will allow resumption aka abbreviated handshake which is faster and cheaper, and almost all clients support caching but only a few do tickets. – dave_thompson_085 Apr 22 '18 at 09:52