6 ms·

Here's a Mashable article about adopting HTTPS served via plain old HTTP: http://mashable.com/2011/05/31/https-web-security/ http://mashable.com/2011/05/31/htt

by maxt 10y ago

Here's a Mashable article about adopting HTTPS served via plain old HTTP: http://mashable.com/2011/05/31/https-web-security/ http://mashable.com/2011/05/31/https-web-security/ It worries me that major websites like this have still not made the switch to HTTPS/TLS yet. Quite irksome are the reasons (actually, excuses) site owners sometimes give like overhead, claiming switching over to HTTP/TLS will be costly and annoying, or even worse - that their threat model doesn't include HTTPS, and the burden is on the visitor to encrypt their connection to the site. The onus is on both parties to encrypt, instead of shunting the encryption to the visitor. As for threat models, the news can be a sensitive topic for some, and HTTPS can be of great service to visitors who enjoy their privacy. I enjoy initiatives like Secure The News[1] which is a small public awareness campaign urging news outlets to adopt HTTPS/TLS. Initiatives like Google's HTTPS Transparency Report[2] are great too and give us great insight into the adoption rate of HTTPS/TLS: [1] https://securethe.news/ https://securethe.news/ [2] https://www.google.com/transparencyreport/https/grid/ https://www.google.com/transparencyreport/https/grid/

waqas- 10y ago
im a lead dev for a large publisher. when we switched over to https we faced the following non-trivial issues: 1. a lot of third party advertisers/ad servers still run on http, these ads need to be embedded via DFP usually, which you can understand does not work out well. We made the switch months ago, to this date i am still making advertisers switch to https. 2. google says they give better ranking to https sites, thats simply not true so far as i have seen. in fact, in the short run your site takes a hit. not only that, in google webmaster console and google news, you cant shift from http to https, you have to make new accounts for ur https sites. to this day i do not know which ones is google crawling. For google news, my new https account has yet to be approved after months, it looks like google just magically shifts to https in google news. but if feels icky and hacky: explicit is always better than implicit. 3. microservices. remember those microservises that were all the rage? well, its a bunch of different servers and subdomains, you have to shift all to https when you shift the mothership to https. while above points are valid, i still pushed in my org to shift to https. we now use shiny stuff like http2 and web push, which is awesome. i'd recommend all publishers to do so. but its understandable that management finds all this scary, esp cuz its sounds like a major overhaul of your web assets (which is everything when ure a web publisher) - even though it isnt really actually an overhaul or anything.
- hannob 10y ago
  Are you using proper forwards from your old HTTP to your new HTTPS URLs? Wired also took a seo hit and this was probably their problem. If you use permanent forwarding (HTTP 301) then you should be fine.
  - waqas- 10y ago
    yes we have permanent 301 forwards set up since day 0. but still it happened in the short run.
- MichaelGG 10y ago
  I don't get point 3. Microservices are for the backend usually, right? You don't want multiple TCP/HTTP[S] connections from the client to all your services - pointless overhead. Worst case scenario, if you need direct client-microservice connectivity, then throw all the services behind nginx and terminate SSL there.
  - waqas- 10y ago
    im talking about when microservices expose apis consumed via ajax. then https-http connections dont work.
    - nugator 10y ago
      As the parent suggested I would terminate the HTTPS connection in an Nginx in front of all your microservices. No microservice needs to handle HTTPS then.
      - adaml_623 10y ago
        Maybe it's such a large publisher that they need separate Nginx instances in front of each of the micro-services.
        philplckthun 10y ago
T-hawk 10y ago
What are the performance characteristics of HTTPS/TLS as compared to plain HTTP these days? (Serious question, I don't know.) You gloss over the overhead, but that may not be insignificant. Every millisecond of latency counts for user engagement and bounce rate. Every round trip in the handshake hurts measurably. Particularly on slow cellular network connections, of course. It's quite possible that web sites exist where the performance penalty for TLS is worse for the business than simply running unsecured. And anything with an ad network (or even other resources like web fonts) runs into the mixed-content problem. If the page is served over HTTPS, then so must every other asset be, or else the browser throws up warnings. And then you're dependent on every partner asset on the page to keep its own TLS certificates valid, or else you get browser warnings again and lose some amount of user engagement. Security always has costs and tradeoffs.
- hannob 10y ago
  The overhead is so small that it's basically irrelevant if you are not youtube or netflix. If you have a performance problem with https then either you have a flaw in your software or some serious configuration mistake. In practice in many situations you can even get better performance with HTTPS, because many modern features (for performance notably HTTP/2 and Brotli) aren't available over plain HTTP.
  - umanwizard 10y ago
    I worked for junglee.com (a relatively unknown site owned by Amazon that used very little CPU) and extra latency on HTTPS was a massive, serious issue. What flaw in our software or serious configuration mistake do you think we had?
    - hannob 10y ago
      Based on the current configuration: No OCSP stapling and no elliptic curve key exchange. Also your setup suffers from TLS version intolerance, which by itself isn't a performance issue, but it is a hint that you're using a badly written TLS stack. https://www.ssllabs.com/ssltest/analyze.html?d=junglee.com&s=178.236.6.99&latest https://www.ssllabs.com/ssltest/analyze.html?d=junglee.com&s...
lmm 10y ago
Sites understandably don't want to mess with what works. We won't see a switchover unless and until not being HTTPS becomes something that hurts their bottom line.
eknkc 10y ago
We switched back to HTTP from HTTPS due to ad revenue difference. A lot of advertisers / ad networks still do not support https.

by maxt 10y ago

waqas- 10y ago

im a lead dev for a large publisher. when we switched over to https we faced the following non-trivial issues: 1. a lot of third party advertisers/ad servers still run on http, these ads need to be embedded via DFP usually, which you can understand does not work out well. We made the switch months ago, to this date i am still making advertisers switch to https. 2. google says they give better ranking to https sites, thats simply not true so far as i have seen. in fact, in the short run your site takes a hit. not only that, in google webmaster console and google news, you cant shift from http to https, you have to make new accounts for ur https sites. to this day i do not know which ones is google crawling. For google news, my new https account has yet to be approved after months, it looks like google just magically shifts to https in google news. but if feels icky and hacky: explicit is always better than implicit. 3. microservices. remember those microservises that were all the rage? well, its a bunch of different servers and subdomains, you have to shift all to https when you shift the mothership to https. while above points are valid, i still pushed in my org to shift to https. we now use shiny stuff like http2 and web push, which is awesome. i'd recommend all publishers to do so. but its understandable that management finds all this scary, esp cuz its sounds like a major overhaul of your web assets (which is everything when ure a web publisher) - even though it isnt really actually an overhaul or anything.

hannob 10y ago
Are you using proper forwards from your old HTTP to your new HTTPS URLs? Wired also took a seo hit and this was probably their problem. If you use permanent forwarding (HTTP 301) then you should be fine.
- waqas- 10y ago
  yes we have permanent 301 forwards set up since day 0. but still it happened in the short run.
MichaelGG 10y ago
I don't get point 3. Microservices are for the backend usually, right? You don't want multiple TCP/HTTP[S] connections from the client to all your services - pointless overhead. Worst case scenario, if you need direct client-microservice connectivity, then throw all the services behind nginx and terminate SSL there.
- waqas- 10y ago
  im talking about when microservices expose apis consumed via ajax. then https-http connections dont work.
  - nugator 10y ago
    As the parent suggested I would terminate the HTTPS connection in an Nginx in front of all your microservices. No microservice needs to handle HTTPS then.
    - adaml_623 10y ago
      Maybe it's such a large publisher that they need separate Nginx instances in front of each of the micro-services.
      - philplckthun 10y ago

T-hawk 10y ago

What are the performance characteristics of HTTPS/TLS as compared to plain HTTP these days? (Serious question, I don't know.) You gloss over the overhead, but that may not be insignificant. Every millisecond of latency counts for user engagement and bounce rate. Every round trip in the handshake hurts measurably. Particularly on slow cellular network connections, of course. It's quite possible that web sites exist where the performance penalty for TLS is worse for the business than simply running unsecured. And anything with an ad network (or even other resources like web fonts) runs into the mixed-content problem. If the page is served over HTTPS, then so must every other asset be, or else the browser throws up warnings. And then you're dependent on every partner asset on the page to keep its own TLS certificates valid, or else you get browser warnings again and lose some amount of user engagement. Security always has costs and tradeoffs.

hannob 10y ago
The overhead is so small that it's basically irrelevant if you are not youtube or netflix. If you have a performance problem with https then either you have a flaw in your software or some serious configuration mistake. In practice in many situations you can even get better performance with HTTPS, because many modern features (for performance notably HTTP/2 and Brotli) aren't available over plain HTTP.
- umanwizard 10y ago
  I worked for junglee.com (a relatively unknown site owned by Amazon that used very little CPU) and extra latency on HTTPS was a massive, serious issue. What flaw in our software or serious configuration mistake do you think we had?
  - hannob 10y ago
    Based on the current configuration: No OCSP stapling and no elliptic curve key exchange. Also your setup suffers from TLS version intolerance, which by itself isn't a performance issue, but it is a hint that you're using a badly written TLS stack. https://www.ssllabs.com/ssltest/analyze.html?d=junglee.com&s=178.236.6.99&latest https://www.ssllabs.com/ssltest/analyze.html?d=junglee.com&s...

lmm 10y ago

Sites understandably don't want to mess with what works. We won't see a switchover unless and until not being HTTPS becomes something that hurts their bottom line.

eknkc 10y ago

We switched back to HTTP from HTTPS due to ad revenue difference. A lot of advertisers / ad networks still do not support https.