Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTPS on Stack Overflow: The End of a Long Road

nickcraver.com

Post reply on HN
Print view View original

41–50 of 183 posts

Re: HTTPS on Stack Overflow: The End of a Long Road

#41

Post by ry_ry »

shortimer wrote: post #27
gatlinnewhouse wrote: post #26

Earlier quoted context omitted.

> We didn't think this would be a problem because the current version of the software wasn't compatible with WinXP any longer. > There was some debate internally whether the better fix was to including the legacy encryption protocols or just leave the HTTP version of the site running and use Strict-Transport-Security to move capable browsers to HTTPS. Where can I read about this? Is there any way to display a special…

At our place, we put a redirect on the front end networking device that detected if a browser couldn't support more modern encryption protocols, and sent them to an HTTP information page (instead of to the application itself) if so. This allowed us to update the core app to force newer protocols, while still providing some sort of UX for those left behind. We used Piwik to track the hits on the redirect page to get a…

We did a similar thing, but folded it into unsupported and deprecated - unsupported browsers will get an HTML page extolling the virtues of updating your browser once a decade, whilst deprecated browsers (basically IE10 at the time tbh) were treated to a popup explaining that whilst the site probably works just fine, their browser wasnt fully upto date and the experience might suffer.

Eventually, and I doubt we had anything to do with it, IE10 usage dipped below the magic .5% (when it costs is more money to support than it earns us) and it was finally unsupported.

The only crappy browsers we still officially support are ancient safari and IE11, both of which are still going relatively strong for reasons we've never been able to fully explain!

Re: HTTPS on Stack Overflow: The End of a Long Road

#42

Post by tomschlick »

skc wrote: post #40
tomschlick wrote: post #10

Just a reminder, HTTPS isn't enough. Be sure to turn the other security knobs with headers... https://securityheaders.io/?q=https%3A%2F%2Fstackoverflow.co...

Every site I've put in there gets a failing grade. From Google to Apple to Slashdot etc. Wonder what the point is then.

Github gets a good one: https://securityheaders.io/?q=github.com&followRedirects=on

Re: HTTPS on Stack Overflow: The End of a Long Road

#43

Post by nathan_f77 »

gatlinnewhouse wrote: post #26
mrunkel wrote: post #7

At $previous_job we once turned on HTTPS for our entire customer website and online store, only to have our customer support team be bombarded by phone calls claiming that our "website was down." After much teeth gnashing and research, we determined that a large segment of our user base was still using WinXP and the encryption protocols we offered weren't available to them. We didn't think this would be a problem bec…

> We didn't think this would be a problem because the current version of the software wasn't compatible with WinXP any longer. > There was some debate internally whether the better fix was to including the legacy encryption protocols or just leave the HTTP version of the site running and use Strict-Transport-Security to move capable browsers to HTTPS. Where can I read about this? Is there any way to display a special…

> Is there any way to display a special "Your browser is outdated" page for the users on WinXP?

https://browser-update.org/ is a great service that does this.

For the case where SSL was broken, unfortunately that wouldn't help at all, because they'd never be able to load the webpage.

Re: HTTPS on Stack Overflow: The End of a Long Road

#44

Post by Nick-Craver »

hdhzy wrote: post #30
mixmastamyk wrote: post #13

Earlier quoted context omitted.

Helpful site, but all these headers will slow down a site that doesn't need them. Too bad they aren't defaults. Hopefully http2 mitigates that enough.

Http2 compresses headers so it they are not changing the amount of overhead is negligible (see HPACK).

Well, yes and no - it depends on the length. Let's take 3 common examples. Here's GitHub's relevant headers (that we don't have):

Content-Security-Policy:default-src 'none'; base-uri 'self'; block-all-mixed-content; child-src render.githubusercontent.com; connect-src 'self' uploads.github.com status.github.com collector.githubapp.com api.github.com www.google-analytics.com github-cloud.s3.amazonaws.com github-production-repository-file-5c1aeb.s3.amazonaws.com github-production-user-asset-79cafe.s3.amazonaws.com wss://live.github.com; font-src assets-cdn.github.com; form-action 'self' github.com gist.github.com; frame-ancestors 'none'; img-src 'self' data: assets-cdn.github.com identicons.github.com collector.githubapp.com github-cloud.s3.amazonaws.com *.githubusercontent.com; media-src 'none'; script-src assets-cdn.github.com; style-src 'unsafe-inline' assets-cdn.github.com

Public-Key-Pins:max-age=5184000; pin-sha256="WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18="; pin-sha256="RRM1dGqnDFsCJXBTHky16vi1obOlCgFFn/yOhI/y+ho="; pin-sha256="k2v657xBsOVe1PQRwOsHsw3bsGT2VzIqz5K+59sNQws="; pin-sha256="K87oWBWM9UZfyddvDfoxL+8lpNyoUB2ptGtn0fv6G2Q="; pin-sha256="IQBnNBEiFuhj+8x6X8XLgh01V9Ic5/V3IRQLNFFc7v4="; pin-sha256="iie1VXtL7HzAMF+/PVPR9xzT80kQxdZeJ+zduCB3uj0="; pin-sha256="LvRiGEjRqfzurezaWuj8Wie2gyHMrW5Q06LspMnox7A="; includeSubDomains

Those are 1220 bytes. I'm not sure what they'll compress down to, but it's still non-trivial and not near 0 (anyone want to run the numbers?).

The same pair of headers are 969 bytes for facebook.com and 2,772 for gmail.com.

I don't know what ours would be - since we're open-ended on the image domain side it's a bit apples-to-oranges compared to the big players.

When you take into account that you can only send 10 packets down the first response (in almost all cases today) due to TCP congestion window specifications (google: CWND), they get more expensive as a percentage of what you can send. It may be that you can't send enough of the page to render, or the browser isn't getting to a critical stylesheet link until the second wave of packets after the ACK. This can greatly affect load times.

Does HPACK affect this? Yeah absolutely, but I disagree on "negligible". It depends, and if something critical gets pushed to that 11th packet as a result, you can drastically increase actual page render time for users.

If it helps, I did a blog post with some details about this a while back: https://nickcraver.com/blog/2015/03/24/optimization-consider...

Re: HTTPS on Stack Overflow: The End of a Long Road

#45

Post by y4mi »

mattmanser wrote: post #39
mrunkel wrote: post #7

At $previous_job we once turned on HTTPS for our entire customer website and online store, only to have our customer support team be bombarded by phone calls claiming that our "website was down." After much teeth gnashing and research, we determined that a large segment of our user base was still using WinXP and the encryption protocols we offered weren't available to them. We didn't think this would be a problem bec…

I know it's hindsight and all that, but why didn't you check your website analytics first? Seems a fairly massive assumption that should have taken 10 seconds to check.

Some people don't spy on their customers and don't have these kinds of information available for analyses

They're admittedly few though and their moral high ground is debatable considering that there are self hosted FOSS alternatives around nowadays

Re: HTTPS on Stack Overflow: The End of a Long Road

#46

Post by HalfwayToDice »

y4mi wrote: post #45
mattmanser wrote: post #39

Earlier quoted context omitted.

I know it's hindsight and all that, but why didn't you check your website analytics first? Seems a fairly massive assumption that should have taken 10 seconds to check.

Some people don't spy on their customers and don't have these kinds of information available for analyses They're admittedly few though and their moral high ground is debatable considering that there are self hosted FOSS alternatives around nowadays

Calling aggregate anonymous analytics "spying on your customers" is absurd nonsense.

Re: HTTPS on Stack Overflow: The End of a Long Road

#49

Post by dzdt »

Stack Exchange is no longer available from my workplace due to this change. We have a strict no-posting-code-fragments policy, and SE was viewed as too risky to allow without some restriction in place to make it read only. Before HTTPS, the IT department had worked out such a read-only restriction by blocking the SE login with firewall rules. But with HTTPS that kludge is no longer possible, so the site is blocked.

Re: HTTPS on Stack Overflow: The End of a Long Road

#50

Post by hdhzy »

Nick-Craver wrote: post #44
hdhzy wrote: post #30

Earlier quoted context omitted.

Http2 compresses headers so it they are not changing the amount of overhead is negligible (see HPACK).

Well, yes and no - it depends on the length. Let's take 3 common examples. Here's GitHub's relevant headers (that we don't have): Content-Security-Policy:default-src 'none'; base-uri 'self'; block-all-mixed-content; child-src render.githubusercontent.com; connect-src 'self' uploads.github.com status.github.com collector.githubapp.com api.github.com www.google-analytics.com github-cloud.s3.amazonaws.com github-product…

Oh I wasn't clear - I meant that for the same connection headers are not sent for every page but just references for previous values (see [0]). The initial page load is a different matter but that's part of the cost/risk analysis if you need CSP or HPKP (I agree it's not necessary and very easy to mess up).

[0]: https://http2.github.io/http2-spec/compression.html#indexed....

> When you take into account that you can only send 10 packets down the first response (in almost all cases today) due to TCP congestion window specifications (google: CWND), they get more expensive as a percentage of what you can send. It may be that you can't send enough of the page to render, or the browser isn't getting to a critical stylesheet link until the second wave of packets after the ACK. This can greatly affect load times.

I wonder how much of the page can be rendered in 10 packets...

Do you send Link preload headers?

Post reply on HN