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.

> 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.

So not only the ads collect personal data, slow down web experience and make every non-adblocked site a pain to watch... you go the extra step to not even encrypt transfer due to them?

Adblocking in 2016: using a HTTP firewall, blocking all HTTP requests by default.

How wonder how much you could learn about a person based on the ads they get served?

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.

im talking about when microservices expose apis consumed via ajax. then https-http connections dont work.

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.

I thought it was recommended to use https between microservices for all communication? Otherwise the user might think their data is encrypted even though it travels plain-text through networks after the first server, as not all services will run in a separated network.

That's entirely up to the app. With Cloudflare it's not even normal for HTTPS to mean your data got to the server encrypted.

And anyways you can solve it in the same way: nginx LBs to terminate SSL internally.

Maybe it's such a large publisher that they need separate Nginx instances in front of each of the micro-services.

That goes against the basics of load balancing... And it shouldn't even be an issue to have multiple Nginx instances with similar HTTPS configs.

Honestly, #3 can be solved completely by putting your own HAproxy or Nginx reverse proxy in front of the microservice or API. You shouldn't be directly exposing your containers to clients anyway - you want a reverse proxy or load balancer to be able to throttle the traffic and provide basic security.

Also, if you have an ad network that can't serve https, just stick another reverse proxy like HAproxy in place and convert their http content into https for your clients. It works very easily for that type of thing as well - in fact, you can even do path-based routing like https://www.mysite.com/ad/* goes to http://ad-network.com (while https://www.mysite.com goes to your regular back-end), and HAproxy will do all the rewriting for you.

Ad networks generally won't let you do that. To them it looks like click fraud.

Also, most ads are now html5 with many resources and scripts etc. for interactivity. You can't just host it on another domain - there will likley be lots of internal absolute paths and paths assembled with JavaScript that one can't practically rewrite.

Remember most sites use an ad-exchange, so we aren't talking fixing up one or two ads here - there are probably over 1 billion unique creatives to fix up.

This is really sad and disturbing to read. Especially the ad networks side of things. But I really hope that people like you pressure these advertisers into providing HTTPS. It's not this "hip new web tech".

It's an established standard and now completely free to set up (thanks to Let's Encrypt ;)). I don't see how these two (yes, frankly, two reasons. let's really ignore the third one) can keep anyone from providing HTTPS connections to their dear readers and users.

> now completely free to set up (thanks to Let's Encrypt)

To be fair, I would expect any reasonably large company to obtain an EV (Extended Verification) certificate, which is very much not free. Let's Encrypt only does DV (Domain Verification). EV includes verification that you're actually the incorporated company that you're telling everyone you are.

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.

yes we have permanent 301 forwards set up since day 0. but still it happened in the short run.

> google says they give better ranking to https sites, thats simply not true so far as i have seen

I believe Google says they use HTTPS as yet another signal they use to rank your site, not that they will significantly push up HTTPS sites over other signals they use, like 'quality of content'.

Point 3 makes no sense...

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.

"In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that."

https://www.imperialviolet.org/2010/06/25/overclocking-ssl.h...

This is only server-side CPU. What about client-side latency? TLS involves extra hops to establish a connection.

In TLS 1.3, when the client sends its list of supported cipher suites, it guesses which one the server will pick and includes keying material for it in the initial ClientHello. The server does the same in its ServerHello. That reduces a full handshake to 1 round-trip when the guesses are right (vs. 2 RTTs in TLS 1.2).

TLS 1.3 also supports 0-RTT connections for servers the client has connected to before using a static "pre-shared key". There is some additional vulnerability to replay attacks (newly introduced with 0-RTT) and loss of forward secrecy (the same as 1-RTT session resumption in TLS 1.2) of the application data sent in the initial ClientHello. The rest of the data sent in the connection has the full set of TLS security guarantees. The pre-shared key approach has less overhead for servers and a simpler synchronization problem for load-balancers than the session IDs and session cookies of TLS 1.2.

See, e.g., https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/ for more.

1 extra round trip is a lot when your users are on shitty connections in India. 0 extra round trips for servers the client has connected to before doesn't matter when most of your users are first-time visitors.

Not to mention that TLS 1.3 isn't supported on IE8, a complete deal-breaker for things I've worked on.

You're thinking of 1.2. 1.3 isn't finalized yet.

Huge JS ad injectors, JS template renderers and other dynamic stuff adds about 100x more latency on most web pages than anything TLS related.

Not for first-byte latency.

If you care about client-side latency you should be using HTTP/2. And HTTP/2 is HTTPS-only.

HTTP/2 is not HTTPS-only, the browsers implementations may be.

https://http2.github.io/faq/#does-http2-require-encryption

it's HTTPS-only in all browsers that support it. http://caniuse.com/#feat=http2

Not supported on IE8. Total deal breaker.

IE8 is not supported, along with Windows XP.

so?

The overhead can be minimized on subsequent connections if you pin a client to one server handling TLS termination for the session (you can either pin to one application server, or a specific load balancer) and your servers have enough memory to keep an adequate number of sessions in memory. You probably take up roughly 10KB of memory per TLS session that's active, so 100 active sessions per 1MB or so which isn't too bad.

> subsequent connections

What if most of your users are first-time visitors coming from google results?

You take an extra hit the first time a TLS session key is established, after that all subsequent HTTP requests can do a fast resume. This has nothing to do with users over a period of time.

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.

Yep, Netflix even switched to 100% HTTPS for video streams (and the sky didn't fall) [0].

[0]: http://techblog.netflix.com/2016/08/protecting-netflix-viewi...

Netflix has performance needs that are not representative of every site in the world. For example, first-byte latency probably doesn't matter much for them.

Youtube uses QUIC for most of its comms (to Chrome and to the Android YT player; possibly to the iOS one too, I don't remember), which does implement TLS with 0-1 RTTs for connection setup (practically speaking, no additional delay).

And IIRC, encryption overhead is pretty insignificant if you have a CPU with AES instructions, which is to say, pretty much anything from the past 5+ years.

> pretty much anything from the past 5+ years

With a cave-at: Intel's low-cost CPUs didn't include AES-NI until pretty recently. Which is why, in 2014, I went for a cheap Athlon instead of a Celeron for my custom-built homeserver with full-disk encryption.

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?

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...

And how much do those increase first byte latency? (which is the real problem)

Tough to say without knowing more about the stack. But in terms of first byte latency, some things you can look at:

* TLS False Start

* HTTP/2 + ALPN

* Optimizing TLS record size

Some 2013-era advice for nginx here: https://www.igvita.com/2013/12/16/optimizing-nginx-tls-time-...

And some other advice and links here: https://istlsfastyet.com/

Pretty much all of them matter for first byte latency. OCSP & the key exchange both happen before any data can be exchanged.

HTTP/2 significantly reduces the issue of repeated handshakes. See: https://www.httpvshttps.com/

Obviously, that site is picking a specific case to make a point, but the point is significant.

The existence of the request itself (for the handshake) is most of the cost. If a client is on the other side of the world, hundreds of ms. Otherwise if you have servers everywhere, still probably 50-70ms for the handshake.

Edit: in my experience.

    "TLS has exactly one performance problem: it is not used widely enough"

https://istlsfastyet.com/

Downvoted.

The information in that site doesn't actually back up the headline. It handwaves away the extra-round-trip issue with "well, there are experimental ways in the works to eliminate one of those extra round trips" which is worlds away from saying there are "no performance problems" with TLS in practice.

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

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.