Skip to content
This repository has been archived by the owner on Sep 30, 2020. It is now read-only.

strict-transport-security headers #165

Open
edunham opened this issue Aug 5, 2015 · 7 comments
Open

strict-transport-security headers #165

edunham opened this issue Aug 5, 2015 · 7 comments
Labels

Comments

@edunham
Copy link
Member

edunham commented Aug 5, 2015

Context: #148

CloudFront doesn't support HSTS (https://forums.aws.amazon.com/thread.jspa?messageID=651244). Could potentially proxy through doc.r-l.o like how static.r-l.o is doing. Current questions:

  • What's the performance impact of proxying vs letting cloudfront handle requests directly?
  • Are there other headers that we should include as well?
  • Does CloudFront plan on implementing this themselves, and if so, when?
@edunham
Copy link
Member Author

edunham commented Aug 5, 2015

Actually quite important; it's the one thing that makes us "mediocre" instead of "good" in https://httpswatch.com/programming#programming-languages

(see also rust-lang/rust#13180)

@zarvox
Copy link

zarvox commented Aug 5, 2015

In that line of thinking: perhaps doc.rust-lang.org should also redirect to HTTPS by default, in the same way that www.r-l.o and play.r-l.o do? (Are there any subdomains that shouldn't get the HTTPS-redirect-by-default treatment? Maybe this should be a separate issue.)

@edunham
Copy link
Member Author

edunham commented Aug 6, 2015

@brson, @alexcrichton Are there any subdomains that shouldn't use HTTPS? I can't think of any.

@zarvox
Copy link

zarvox commented Aug 6, 2015

If you want to have a subdomain that you want to be able to answer (plain) HTTP requests without requiring the HTTPS overhead (ideally because the content is being verified asymmetrically with e.g. GPG), then that would be one reason. For example most Debian mirrors are plain HTTP, since it has signed metadata for everything.

Another might be if any of the *.r-l.o properties are not hosted by Mozilla, you probably don't want to give them your TLS key, so they'd stay plain HTTP. But if any of those exist, I'd imagine you'd want to migrate them to Mozilla's stewardship instead.

Other than that, if you have scripts or tooling that specify plain-http and don't handle redirects, that would be something you'd want to update. But in general, HTTPS everywhere seems like a pretty solid plan.

@zarvox
Copy link

zarvox commented Aug 6, 2015

Oh, and blog.rust-lang.org is also currently on Github Pages, so it doesn't have working HTTPS yet either.

@brson
Copy link
Contributor

brson commented Aug 6, 2015

@edunham I can't think of any reason not to use TLS everywhere if we can.

FWIW rustup.sh does go straight to plaintext HTTP if gpg is available for verification, but not for any perf reasons. I don't have any objections to serving all our bins over HTTPS.

@davidalber
Copy link
Contributor

It looks like https://www.rust-lang.org/ is still hosted out of an S3 bucket fronted by CloudFront, so this seems like a relevant update.

AWS now has lambdas for CloudFront (called Lambda@Edge), which can be used to alter responses coming out of CloudFront. You could use that to add the Strict-Transport-Security header on the way out. There's a relevant answer about it here. It seems you don't need to be scared by comments on that answer stating that the limit is 100 TPS. According to this you can do 10,000 TPS now, which I imagine should have you covered.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants