5 ms·

Our community has to shoulder part of the blame for the lack of adoption of HTTPS in many governments both federal and local. In my jobs at two different univer

Our community has to shoulder part of the blame for the lack of adoption of HTTPS in many governments both federal and local. In my jobs at two different universities they both expressed vague concerns of "We heard that it hinders performance" as a reason to nix doing it. This should never have been a conversation about performance and it was the technical folks making it one of performance. The only issue raised should have been about proper certificate management. Fortunately at the university we pushed through https on the product despite the pushback, but it never would have even been a struggle in the first-place if not for the focus on the wrong metric.

adventured 12y ago
I still run into technical people very regularly that believe HTTPS is a big performance hit. I'm not sure what's perpetuating that myth (present day myth, 15 years ago it was true). I build everything side-wide HTTPS, and have rarely run into a situation where it caused even a 1% performance loss, and at those levels it's simply irrelevant in comparison to the benefit.
- belorn 12y ago
  In 2010, google switched to https for gmail and publishes the performance cost for it. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10 KB of memory per connection and less than 2% of network overhead. Many people believe that SSL/TLS takes a lot of CPU time and we hope the preceding numbers (public for the first time) will help to dispel that.
- Dylan16807 12y ago
  Was it true 15 year ago? Are you sure?
  - acdha 12y ago
    Yes. Remember that 15 years ago doesn't mean only that processors were much slower but also that you don't have the heavily-optimized software implementations and hardware acceleration for the most common implementations. You can run OpenSSL today on an embedded processor which might appear to be as slow as a 90s server processor but it's still likely to have things like AES support in the CPU, an optimized bignum library, tuned assembly implementations for the most common algorithms and at least the very least the compilers in use now generate much better code. I'd be surprised if you wouldn't see a significant benefit taking some 90s crypto code and compiling it with a current version of clang/gcc.
    - Dylan16807 12y ago
      Well I've done some research to get exact numbers. The 2010 Google announcement that gets cited a lot talks about cores capable of doing 1500 handshakes per second (1024 bit RSA), and only needing 1% of CPU power. I found a couple sources claiming that a Pentium 3 should be capable of 200 handshakes per second max (1024 bit RSA), and also that it could hash over 50Mbps with 3DES or well over 100 with RC4-MD5. I can't find if those Google servers had AES acceleration, but the chips with it had only just come out. So looking at the year 2000: Pentium 3 is about 10x slower at handshaking, and somewhere around 10x[1] slower at encrypting depending on algorithm. So if you can spare 10-20% CPU, I don't see any major problems with going full-SSL. [1] This one can vary more depending on exactly what you compare. Could be close to equal speed if you accept a worse algorithm for 2000, and don't have brand new AES-NI chips in 2010. Could be a huge multiplier between 3DES and AES-NI, but your server doesn't need a gigabyte per second of SSL traffic.
mauricemir 12y ago
Switching an existing site to https properly is a fair amount of work from my experience helping migrate a major hotels chain site. you also really need to use spdy and have a plan to move to http 2
- falcolas 12y ago
  With the combination of nginx and various load balancers supporting ssl termination, I've yet to find this a major problem. The trick is to be willing to refactor how the infrastructure routes.
  - sigzero 12y ago
    He didn't say it was a "problem". He said it was a "fair amount of work". Time is money and sometimes there is no money to do it.
    - mauricemir 12y ago
      And in our case the initial attempt was dropped on us with less than 2 week notice - it was also a radical restructuring of the site at the same time.
- Someone1234 12y ago
  It really doesn't have to be a fair amount of work. Just leave your existing HTTP property exactly as it is. Add a load balancer in front. Have the load balancer receive HTTPS and then send the traffic through to the property as HTTP, and finally restrict all other external access to the HTTP sites (i.e. load balancer only). You can buy off-the-shelf appliances which will do this for you. Except for maybe a firewall change, no changes would have to be made to existing code or servers.
  - snowwrestler 12y ago
    You also need to scrub the existing site for content embedded with HTTP links, because active mixed content is blocked by default in Firefox and Chrome (as it should be). We did our first site HTTPS-only the exact way you describe, but didn't anticipate half our embedded content disappearing. The situation is getting better fast, but even a year ago a number of pretty well-known services like Scribd and Storify didn't fully work over HTTPS. Video is the worst; every TV network has its own embeddable video player, and most of them did not work at all over HTTPS until very recently. Again, that's getting better pretty fast.

adventured 12y ago

I still run into technical people very regularly that believe HTTPS is a big performance hit. I'm not sure what's perpetuating that myth (present day myth, 15 years ago it was true). I build everything side-wide HTTPS, and have rarely run into a situation where it caused even a 1% performance loss, and at those levels it's simply irrelevant in comparison to the benefit.

belorn 12y ago
In 2010, google switched to https for gmail and publishes the performance cost for it. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10 KB of memory per connection and less than 2% of network overhead. Many people believe that SSL/TLS takes a lot of CPU time and we hope the preceding numbers (public for the first time) will help to dispel that.
Dylan16807 12y ago
Was it true 15 year ago? Are you sure?
- acdha 12y ago
  Yes. Remember that 15 years ago doesn't mean only that processors were much slower but also that you don't have the heavily-optimized software implementations and hardware acceleration for the most common implementations. You can run OpenSSL today on an embedded processor which might appear to be as slow as a 90s server processor but it's still likely to have things like AES support in the CPU, an optimized bignum library, tuned assembly implementations for the most common algorithms and at least the very least the compilers in use now generate much better code. I'd be surprised if you wouldn't see a significant benefit taking some 90s crypto code and compiling it with a current version of clang/gcc.
  - Dylan16807 12y ago
    Well I've done some research to get exact numbers. The 2010 Google announcement that gets cited a lot talks about cores capable of doing 1500 handshakes per second (1024 bit RSA), and only needing 1% of CPU power. I found a couple sources claiming that a Pentium 3 should be capable of 200 handshakes per second max (1024 bit RSA), and also that it could hash over 50Mbps with 3DES or well over 100 with RC4-MD5. I can't find if those Google servers had AES acceleration, but the chips with it had only just come out. So looking at the year 2000: Pentium 3 is about 10x slower at handshaking, and somewhere around 10x[1] slower at encrypting depending on algorithm. So if you can spare 10-20% CPU, I don't see any major problems with going full-SSL. [1] This one can vary more depending on exactly what you compare. Could be close to equal speed if you accept a worse algorithm for 2000, and don't have brand new AES-NI chips in 2010. Could be a huge multiplier between 3DES and AES-NI, but your server doesn't need a gigabyte per second of SSL traffic.

mauricemir 12y ago

Switching an existing site to https properly is a fair amount of work from my experience helping migrate a major hotels chain site. you also really need to use spdy and have a plan to move to http 2

falcolas 12y ago
With the combination of nginx and various load balancers supporting ssl termination, I've yet to find this a major problem. The trick is to be willing to refactor how the infrastructure routes.
- sigzero 12y ago
  He didn't say it was a "problem". He said it was a "fair amount of work". Time is money and sometimes there is no money to do it.
  - mauricemir 12y ago
    And in our case the initial attempt was dropped on us with less than 2 week notice - it was also a radical restructuring of the site at the same time.
Someone1234 12y ago
It really doesn't have to be a fair amount of work. Just leave your existing HTTP property exactly as it is. Add a load balancer in front. Have the load balancer receive HTTPS and then send the traffic through to the property as HTTP, and finally restrict all other external access to the HTTP sites (i.e. load balancer only). You can buy off-the-shelf appliances which will do this for you. Except for maybe a firewall change, no changes would have to be made to existing code or servers.
- snowwrestler 12y ago
  You also need to scrub the existing site for content embedded with HTTP links, because active mixed content is blocked by default in Firefox and Chrome (as it should be). We did our first site HTTPS-only the exact way you describe, but didn't anticipate half our embedded content disappearing. The situation is getting better fast, but even a year ago a number of pretty well-known services like Scribd and Storify didn't fully work over HTTPS. Video is the worst; every TV network has its own embeddable video player, and most of them did not work at all over HTTPS until very recently. Again, that's getting better pretty fast.