Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

StackExchange is moving to HTTPS. #9085

Closed
bardiharborow opened this issue Mar 15, 2017 · 13 comments

Comments

Projects
None yet
8 participants
@bardiharborow
Copy link
Contributor

commented Mar 15, 2017

StackExchange is slowly rolling out site-wide HTTPS support. Per user2428118's report, the HTTPS Everywhere ruleset is going to need adjustment, especially this rule:

<!-- https links from other pages to these will cause MCB for important elements, hence the downgrades -->
<rule from="^https://([\w.-]+)\.([\w-]+)\.stackexchange\.com/" 
    to="http://$1.$2.stackexchange.com/" downgrade="1" />

https://security.meta.stackexchange.com is currently impacted (redirect loops).

@Bisaloo

This comment has been minimized.

Copy link
Collaborator

commented Mar 15, 2017

Also see this comment of a stack exchange dev.

Leaving him submit PR is the safest bet in my opinion. He knows the domain better than any of us and is less likely to introduce any bugs.

@jeremyn

This comment has been minimized.

Copy link
Contributor

commented Mar 15, 2017

I agree with @Bisaloo, let's wait for @NickCraver to submit changes to the ruleset(s) in question, since he said he would.

@NickCraver

This comment has been minimized.

Copy link
Contributor

commented Mar 16, 2017

Thanks for tracking this - we'll very likely be turning the entire network over about March 27th (right after some Mass Effect vacation here). We're testing it on many domains right now: superuser.com, security.stackexchange.com, meta.stackoverflow.com, and meta.stackexchange.com. The stall there is watching Google and incoming traffic effects (hopefully none).

But, we'll probably move all the child domains over to valid certificates tomorrow. For example, meta.security.stackexchange.com now points to https://security.meta.stackexchange.com/ (and 301s accordingly). All of the child metas will make this move, to the *.meta.stackexchange.com and *.meta.stackoverflow.com wildcards in our main certificate. When we move them, I'll force users to https:// via 301s. We should be able to rip out these at that point:

<exclusion pattern="^http://([\w.-]+)\.([\w-]+)\.stackexchange\.com"/>

<rule from="^https://([\w.-]+)\.([\w-]+)\.stackexchange\.com/" 
    to="http://$1.$2.stackexchange.com/" downgrade="1" />

For those curious: the secure cookie transition will happen after all the domains kick to 301 https://, since login is now on the second level domains for global auth across the network. The same for HSTS.

@numismatika

This comment has been minimized.

Copy link
Contributor

commented Mar 16, 2017

If you added a preload header, we would be able to kill it completely.

@NickCraver

This comment has been minimized.

Copy link
Contributor

commented Mar 16, 2017

@numismatika Once we switch everything over, I'll indeed be ramping up HSTS...so: coming! There's a short list of subdomains to move as well, almost finished there. Then we've got more header simplification options. But we can issue them from header from the app per-site orthogonal from that cleanup.

@NickCraver

This comment has been minimized.

Copy link
Contributor

commented Mar 16, 2017

All: a PR has been submitted here, hopefully I didn't screw anything up: #9110

@ymhuang0808

This comment has been minimized.

Copy link
Contributor

commented May 23, 2017

Stack Overflow is HTTPS by default.
Source: Blog post

@Bisaloo

This comment has been minimized.

Copy link
Collaborator

commented May 23, 2017

Interesting bit for HTTPS-Everywhere:

For the moment, I will be ramping up the HSTS max-age duration slowly to 2 years across all Q&A sites without includeSubDomains. I’m actually going to remove this setting from the code until needed, since it’s so dangerous. Once we get all Q&A site header durations ramped up, I think we can work with Google to add them to the HSTS list without includeSubDomains, at least as a start. You can see on the current list that this does happen in rare circumstances. I hope they’ll agree for securing Stack Overflow.

So this means that our HSTS preload utility (hsts-prune) won't detect this domain as preloaded.

@jeremyn

This comment has been minimized.

Copy link
Contributor

commented May 23, 2017

Browsing through the hsts-prune code, it may be more complicated than it needs to be. I don't fully understand what it's doing but I think it's both checking the actual lists of domains included with the browsers like Chromium's transport_security_state_static.json, AND it's checking the headers found on calls to the URLs. Do we really need both checks? Why not just check the browser lists? As a side effect, this would automatically cover any exception Google made for StackOverflow or anyone else.

@Hainish What do you think?

@Hainish

This comment has been minimized.

Copy link
Member

commented May 23, 2017

@jeremyn we do need to check the delivered headers. Here's the formal logic of the prune utility: #7126 (comment)

The reason for that is explained in https://hstspreload.org/:

Chrome has not yet removed any domains from the preload list for failing to keep up the requirements after submission, but there are plans to do so in the future.

Therefore we don't want to be removing domains that are preloaded now if they will be removed from the preload list in short course. This is why we check those headers.

@Hainish

This comment has been minimized.

Copy link
Member

commented May 23, 2017

Reading above, if need be we can carve out special exceptions for domains which have been added to the preload list despite not having the stated prerequisite directives.

This gets into a grey area though: if a domain is added as a special exception, where is this noted on the Chromium side? Is Mozilla always going to follow the same exceptions? What if somewhere down the line that knowledge gets lost or it is communicated to these companies that they'll have to abide by the formal directives definition, how would we know? I'm wary of deleting rulesets based on informal agreements that happen on one-off basis between the HSTS preload list maintainers and companies.

Perhaps @lgarron, the current HSTS preload maintainer, can shed some light?

@lgarron

This comment has been minimized.

Copy link

commented May 23, 2017

Perhaps @lgarron, the current HSTS preload maintainer, can shed some light?

I'm working on getting all exceptions documented. It remains to be seen what level of documentation is needed, and what Mozilla will accept.

@Hainish

This comment has been minimized.

Copy link
Member

commented May 23, 2017

@lgarron: if in addition to documentation you could provide a machine-parsable list, that would be helpful for us.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.