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

51–60 of 183 posts

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

#51

Post by mrbabbage »

Nick-Craver wrote: post #16
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...

Yep - we're aware. I thought about putting in our Content-Security-Policy-Report-Only findings about what all would break, but the post was already a tad long. It's quite a long list of crazy things people do. As the headers go, here's my current thoughts on each: - Content-Security-Policy: we're considering it, Report-Only is live on superuser.com today. - Public-Key-Pins: we are very unlikely to deploy this. Whenev…

> - Public-Key-Pins: we are very unlikely to deploy this. Whenever we have to change our certificates it makes life extremely dangerous for little benefit.

Is it possible to pin to your CA's root instead of to your own certificate? That would make rotating certs from the same CA easy but changing CAs hard (but changing CAs is already a big undertaking for big orgs).

Also, I see your five minute HSTS header ;)

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

#52

Post by maddyboo »

dzdt wrote: post #49

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.

Wow, that sounds ridiculous. What's the reasoning behind that policy?

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

#53

Post by Shoop »

dzdt wrote: post #49

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.

What sort of company do you work at? Why can't everyone just be told not to post code?

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

#55

Post by nfriedly »

dzdt wrote: post #49

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.

You should try this link from home: https://stackoverflow.com/jobs

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

#56

Post by vbernat »

hdhzy wrote: post #29
vbernat wrote: post #21

Earlier quoted context omitted.

Many headers presented here are questionable. X-Frame-Options should be replaced by CSP frame-ancestors. X-XSS-Protection: 1 is the default since a long time for browsers supporting it and Chrome blocks by default since two releases. Referrer-Policy is a matter of choice. It's a useful information for the target site as long as the referrer doesn't contain sensitive information. IMO, most sites shouldn't set this hea…

> X-XSS-Protection: 1 is the default since a long time for browsers supporting it and Chrome blocks by default since two releases. Do you have references to back this up? > Referrer-Policy is a matter of choice. It's a useful information for the target site as long as the referrer doesn't contain sensitive information. IMO, most sites shouldn't set this header. Exactly. I think its primary use is when the original si…

For X-XSS-Protection, see: https://bugs.chromium.org/p/chromium/issues/detail?id=654794. Currently implemented in M57, but you can still disable filtering. This should be removed in the future.

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

#57

Post by johncolanduoni »

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

Mere server-side logging can pick out something like this via User-Agent. Is it spying to count the number of times a request with "Windows NT 5.1" is sent to your server?

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

#58

Post by teraflop »

dzdt wrote: post #49

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.

Leaving aside all the reasons why this policy is super dumb (which I'm sure others will cover quite adequately), I guess your IT department can't figure out how to create their own CA certificate and do SSL interception?

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

#59

Post by DamonHD »

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

Earlier quoted context omitted.

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…

I explicitly try to ensure that for my sites the first 10kB sent (so less than 10 packets typically) is enough to render all the information above the fold. Anything essential should make it out in the first 2 packets for old TCP slow-start rules. (Lipstick and ads can arrive later, once the user is happy reading or whatever, IMHO.) Has been my policy since about the mid '90s!

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

#60

Post by [deleted] »

dzdt wrote: post #49

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.

[deleted]
Post reply on HN