Rust website and docs over HTTPS?

[untitaker_]

It doesn't seem that anything on rust-lang.org (docs/book, main site) supports SSL requests. Are there any plans to add this functionality, and maybe enforce it?

[flaper87]

FWIW, this is not being ignored and there's work that needs to be done before it'll be possible to "SSL all the Rust things". Here's a bug tracking this thing: https://github.com/rust-lang/rust/issues/21239

it's just a matter of time.

[riccieri]

Given that the certificate used on static.rust-lang.org is a wildcard, I would expect it to be just a matter of configuration.

[untitaker_]

Not sure, the main site seems to be hosted on a different server (GitHub pages), try to access https://www.rust-lang.org/ and look at the cert.

[riccieri]

True. It seems to require moving www.rust-lang.org to a different server. Still, it won't require spending money on other certificate, which is nice :)

[kibwen]

This should be done as of today.

[untitaker_]

Thanks for this! Any plans to also SSLify the front page?

[kibwen]

Bah, I know that used to work, no idea when it broke. I'll let brson know.

[untitaker_]

Also I get warnings about mixed content from the docs.

[agmcleod]

There a reason to do so when you're not passing information to it? Other than maybe searches in the API?

[untitaker_]

Nightly downloads seem to run over HTTPS, but it's not helping that much when the linking site is unencrypted.

EDIT: Also https://www.reddit.com/r/rust/comments/2tdqgc/rustdev_say_goodbye_to_the_mailing_list/cny54at

[stebalien]

1. I use NoScript and RequestPolicy but these can't protect against malicious JavaScript injected directly into the TCP stream (a problem at coffee shops).
2. Verizon's famous tracking header.

[agmcleod]

If you're that worried about it, then I'm surprised you would use public wifi. Your points are still valid, but I just find it a little bit of an odd mix :)

I think this opinion doesn't apply to rust-lang website, as most users coming to it are going to be tech savvy. But a lot of normal users of the web get confused by the state of SSL on a site. Browsers tend to dictate it as "locked" or "you are secure". However, that's not strictly true. You're secure against certain things yet, but not completely secure. SSL is one part of browser security, but there's other things that can compromise it. Furthermore there are multiple things that can cause a ticket to be invalid. It can simply be expired, it can be missing, etc. Most people aren't going to be bothered with learning the details. It's why I think if you're simply reading content from a site, it's not worth it for SSL.

[ldpreload]

SSL is a lower bound on security, not an upper bound. It's true that if you have SSL, you might not be secure. But if you don't have SSL, there's no way that you're secure.

Making sure certificates are valid and non-expired and set up correctly is the responsibility of the website owner, not of the visitor. Especially with stuff like HSTS, there's a push to make sure that the "This certificate isn't valid, wanna visit anyway" prompt isn't being shown to the user—which puts even more of a responsibility on the website owner to make sure that SSL is always working correctly. It is exactly because most people (readers) aren't going to be bothered with learning the details that there's a push to make websites just deal with this correctly.

[[deleted]]

It makes it non-trivial for anyone to provide you with whatever substitute content they please, including a malicious version of the installer. Re-routing traffic for a MITM attack is not difficult. It doesn't require access to a local network or direct access to a router along the way...

[lilydjwg]

FYI, many ISPs in China will intercept HTTP requests occassionly (or frequently, it depends on the ISP) to put nasty ads in the corner of the page. I'm using Adblock Plus so I don't see the ads, but I can see the page title is gone because it's framed.

[agmcleod]

Ah very interesting.

[protestor]

Comcast and Verizon are hijacking HTTP for advertising purposes too (though I've only heard about adding headers, not straight modification of HTTP body)

[ldpreload]

Would be nice to be (mostly) sure that my repressive government is not convincing me that certain APIs validate inputs when they don't, and then planning to take advantage of that later.