-1

Does SSL deployment for secure server-client communication incur any performance overhead? I ask myself, why not just use HTTPS for standard web browsing when it is proven that it protects our privacy?

For example, I am writing this post now and will post it toward StackOverflow server using insecure HTTP. In other words, it seems most communication on the Internet is straightforward using HTTP (Well, except when security is needed like online banking or so)!

Anders
  • 64,406
  • 24
  • 178
  • 215
Michael
  • 403
  • 2
  • 9
  • 3
    Perhaps you mean SSL, or even more correct: TLS? – Teun Vink Jan 17 '17 at 21:27
  • @TeunVink Both can serve the same purpose, secure transmission over public network, right? If I am not mistaken, SSL/TLS is proven to be slow. – Michael Jan 17 '17 at 21:31
  • 5
    You are mistaken. You have not googled enough. spend 5 minutes googling. Not just about performance but about how the protocols work. – Z.T. Jan 17 '17 at 21:33
  • 1
    SSH stands for secure shell, used for logging into remote devices securely. That's something different than TLS, which is used for end-to-end encryption of a connection, for example from a webbrowser to a webserver. – Teun Vink Jan 17 '17 at 21:33
  • 1
    See also: https://istlsfastyet.com/ TL;DR: There is overhead, but with sufficient engineering work it is small compared to the benefit. – Xiong Chiamiov Jan 17 '17 at 22:10
  • Possible duplicate of [understanding and getting over the SSL performance issue](http://security.stackexchange.com/questions/52992/understanding-and-getting-over-the-ssl-performance-issue) – Steffen Ullrich Jan 18 '17 at 05:15
  • Similar to http://security.stackexchange.com/questions/4369/why-is-https-not-the-default-protocol also compare http://webmasters.stackexchange.com/questions/1823/https-for-entire-site vs http://webmasters.stackexchange.com/questions/3148/does-ssl-really-matter-for-most-websites – dave_thompson_085 Jan 18 '17 at 17:45

4 Answers4

5

Does SSL deployment for secure server-client communication incur any performance overhead?

Why not just use HTTPS for standard web browsing when it is proven that it protects our privacy?

Traditionally, people haven't cared about HTTPS because it:

  • Involves more work like getting certificates, reinstalling new certs after they expire etc.
  • is difficult (or sometimes not possible) to set it up on the shared hosting servers.

This is changing fast though, thanks to initiative like letsencrypt which make certificates easy to create and free.

Also, Google chrome is doing great work by pushing people to adopt HTTPS. There are two initiatives in pipeline that will make/force many website owners to move to https. From this announcement:

  • Beginning in January 2017 (Chrome 56), we’ll mark HTTP pages that collect passwords or credit cards as non-secure List item
  • Eventually, they plan to label all HTTP pages as non-secure, and change the HTTP security indicator to the red triangle that we use for broken HTTPS. List item

Given these initiatives, we should see a very healthy adoption of https in coming future.

CodeExpress
  • 2,422
  • 13
  • 10
1

I am assuming from the question that you meant SSL. SSH or secure shell is an alternative to telnet to get remote administrative interface. It is no way related to web traffic or browsing.

Regarding your query, yes there is a performance overhead when HTTPS is used instead of HTTP.

The reason for this is the handshakes and communication involved in setting up an SSL connection.

While accessing a normal HTTP website the client will complete the TCP three-way handshake, establish the communication and start sending HTTP requests.

On the other hand, onn an https website, there is an additional renegotiation for establishing the security parameters for TLS. This is resource consuming and that results in computational overhead.

hax
  • 3,851
  • 1
  • 16
  • 34
  • Well, you can tunnel HTTP requests over an SSH tunnel (I do this sometimes for accessing a web service that's only listening on localhost). But that doesn't make sense as a general use, because you'd need to have a shell account on every website. – Xiong Chiamiov Jan 17 '17 at 22:08
  • @XiongChiamiov The web could have worked using HTTP over SSHv2 with no-shell account with anonymous user auth (or standardised username "www" and password "www"). It is an accident that in the 90s, three groups independently worked on the network security problem and came up with separate SSL, SSH and IPSec. They could have cooperated instead. – Z.T. Jan 17 '17 at 22:23
0

Google's head of network crypto code for both Chrome and the servers wrote in 2010 that the CPU overhead of TLS at Google was 1%.

TLS has not been slow for a very long time. Saying it's slow is almost like saying "I heard that the 8087 is slow so I don't use floating point number in my code". Also, it would take you 1 minute to Google this fact.

SSH has a very different use case than the web. It is for technical users accessing internal systems. It is always deployed in a way that requires authenticating the client to the server and not just the server to the client.

The technology inside modern SSH and modern TLS is the same, equally secure and fast: AES-GCM or ChaCha20-Poly1305 for bulk confidentiality and integrity, RSA or ECDSA or EdDSA digital signatures for authentication, ECDHE over P-256 or X25519 for key exchange and forward secrecy. Modern Intel CPUs do more than 2GB per second per core of AES and a few thousands of RSA handshakes per second. EdDSA is faster than RSA but will only be available for TLS next year.

SSH were quicker with standardizing X25519 and EdDSA, but adoption of newer versions and cipher suites is quicker with TLS, both things for complicated non-technical reasons.

Both protocols allow clients to be authenticated by the server using pre-shared keys or public keys, with the private key potentially being on a smartcard.

Both protocols can use pre-shared keys or trust-on-first-use or PKI. SSH defaults to trust-on-first-use. The Web defaults to distributed cached trust-on-first-use via domain validated webpki certificates. Clients can and often do non-default authentication (e.g. pinned certificates issued by corporate CA).

Since the Snowden revelations, some organizations, most notably Google, have declared war on unencrypted traffic and are pushing everyone to use TLS. Sites that support TLS should default to TLS and maybe not support plaintext. Why doesn't stackexchange.com default to TLS? I don't know.

Z.T.
  • 7,768
  • 1
  • 20
  • 35
  • FYI '1 minute ... Google' gives http://security.stackexchange.com/questions/67066/why-is-stackoverflow-not-using-https-for-all-its-page and thence http://nickcraver.com/blog/2013/04/23/stackoverflow-com-the-road-to-ssl/ – dave_thompson_085 Jan 18 '17 at 17:51
  • @dave_thompson_085 Thanks for the link! That post is 3.75 years old now. I think if TLS was a priority, they could have switched to TLS by now. – Z.T. Jan 19 '17 at 08:28
0

The answer to your question is "yes". The actual question not whether it is slow as that can be attributed to multiple variable factors such as network speed, bandwidth and traffic load. However, if you ask "Is it slower?" then the answer is yes. However, on a sufficiently capable network the difference is negligible.

To be fair, @Z.T. has the right of it though it may be more technical detail than you are looking for.

Richard L. Dawson
  • 1
  • 1