rust-lang.org, the nightly archives, and rustup.sh should be served over https

[erickt]

I just noticed that the rust-lang.org, the nighty archives, and rustup.sh are not being served over https. We should set this up to protect users from man-in-the-middle attacks. Nominating for this to be done before we release 1.0.

• set up https for static.rust-lang.org
• change binary links on website
• change binary links on wiki
• change binary links in docs
• change rustup links in docs
• modify rustup.sh to download over ssl
• move rustup.sh to static.rust-lang.org
• deprecate www.rust-lang.org/rustup.sh
• change makefiles to download snapshots over ssl?

[pnkfelix]

P-hard P-tedious encoded as P-high, 1.0 milestone

[brson]

There's not a lot of information about how to make S3 + TLS + CNAMEs work, but it looks like it's possible. There's hints here: http://aws.amazon.com/s3/details/. It looks like we need a 'wildcard' cert and the S3 bucket needs to not contain periods (which sucks because our bucket is called 'static.rust-lang.org').

[alex]

https://aws.amazon.com/cloudfront/custom-ssl-domains/ is what you want I think? Looks like it's free with SNI, or pricey for dedicated IP.

[brson]

@alex I do not want that because it requires paying a lot more money (I think - paying for cloudfront at all).

[brson]

Oops, this is the link I meant before that talks about S3 + SSL http://docs.aws.amazon.com/AmazonS3/latest/dev/VirtualHosting.html

[brson]

The info on that page seems contradictory though: "When using virtual hosted–style buckets with SSL, the SSL wild card certificate only matches buckets that do not contain periods" and "Because Amazon S3 sees only the original host name www.example.com and is unaware of the CNAME mapping used to resolve the request, the CNAME and the bucket name must be the same".

The latter implies to me that SSL can't work because to use "virtual hosted-style buckets" you have to use periods.

[brson]

This page says it's not possible without cloudfront http://stackoverflow.com/questions/11201316/how-to-configure-ssl-for-amazon-s3-bucket

[brson]

Maybe we have to spin up an nginx proxy and do it ourselves. Not sure how the cost would compare to just funneling everything through cloudfront.

[tarcieri]

CloudFlare pro is $20/mo and includes SSL. They've also talked about making SSL free for OSS projects.

[brycefisher]

@brson, there's a lot of confusing and contradictory information on official AWS documentation. I've written up a detailed post describing to how to do this. Here are my responses to things you've asked/written above:

1. S3 buckets can't contain dots in the name if you want to use them with CloudFront.
2. You're also correct that S3 does not support SSL -- you must use a CDN of some sort to do that.
3. There's no need to use nginx for this kind of setup.

However, providing any serious amount of bandwidth over SSL is going to cost some money. The cost depends on two main factors: bandwidth and geographic coverage. If CoudFlare is serious about providing SSL free to OSS projects, they would be the only free option available. @tarcieri -- let us know if CloudFlare makes SSL free for OSS. Realistically though, I assume we'll have to pay for this.

If there's no funding forthcoming from Mozilla or another sponsor, perhaps we could start a crowdfunding campaign to pay for CDN costs.

[brycefisher]

As a short term workaround, I'm trying to encourage rustilians to access rustup.sh from the raw github site served over HTTPS: https://raw.githubusercontent.com/rust-lang/rust-www/gh-pages/rustup.sh

[brycefisher]

As noted in #16222, it makes little sense to access rustup.sh securely when rustc, rustdoc, and cargo are still served over HTTP.

[DaGenix]

From experience I can say that CloudFront is pretty easy to setup to support SSL infront of an S3 bucket. Assuming that you go for the SNI option, you can avoid the $600 / month cost for the dedicated ip. There are costs to transfer data from S3 to CloudFront, but assuming that all files are marked to be cached, I assume those would be minor. Bandwidth to serve files from S3 and CloudFront cost roughly the same amount with CloudFront actually being slightly cheaper (assuming that you only use the US and European endpoints). A difference is that S3 costs $0.004 / 10,000 GET requests while CloudFront charges $0.01 / 10,000 HTTPS GET requests.

[darnuria]

Also we can do like GNU/Linux distributions. Downloading over http.
But signing package on the build machine and verifying this signature.

[brson]

@brycefisher @DaGenix thanks for the info. I guess CloudFront is the best way forward, and that we're going to have to pay more for our traffic.

@brycefisher Even serving rust and cargo over TLS is not going to close the trust hole since everybody in the world has to trust our snapshots.

EDIT: That last point isn't really relevant here since if your d/ling an installer you are going to trust some binary.

[tarcieri]

You also might take a look at https://www.fastly.com

I believe they also do special deals for open source projects

[brycefisher]

Fastly is the practically the best CDN there is IMHO. Normally they're pricey ($50/mon minimum), but they have all the bells and whistles. I feel like a bona fide representative of rust should reach out to Fastly.

Their tech support is on Freenode IRC in #fastly room. Their sales people can be reached through [email protected].

[brson]

I've already started setting up CloudFront because I'd rather have one service than two. Hopefully there will be downward price pressure on CloudFront soon because of the prevailing trend of moving to SSL.

[brson]

We're not going to get the website itself under ssl without moving it from github, and I don't think we need to as long as we move rustup.sh.

[brson]

I've copied all the s3 data to a new bucket (with the correct name), updated buildbot to upload to it, connected it to a cloudfront distribution with a cert, and updated the DNS cname (which is still propagating).

[brson]

The final piece of this is #16427.

[l0kod]

Nice work!

A second step should be to sign all files needed for the installation. Each Rust versions are signed in the git repository. Great! If the "rustup.sh" is included in the git repository, it will be possible to anyone to verify the script (from a git tag) before executing it.

Maybe all (including nightly) underlying binaries hashes should "inherit" from the signature like with the "snapshots.txt" hashes? The main Rust repository or dedicated one could aggregate all hashes.

So, the guide could be improved by replacing the "curl" instruction with a "git clone + verify-tag". This add some extra MB to the download but worth it for more security to users.

cc #15204

[brson]

This is done. @l0kod if you want further security steps please file as a followup bug.

[brycefisher]

@brson, fantastic!! You're the man. I'll start issuing PR everywhere to use https://static.rust-lang.org/rustup.sh.

[steveklabnik]

isaacs/github#156 is relevant here.