The actual answer is probably going to surprise you ...
The reason that the vast majority of rsync.net is not covered by https is because I personally have not yet decided how I feel, philosophically, about the notion of https-only websites.
As silly as it may sound to you, I very much like the fact that you can read rsync.net HOWTO pages with netcat. Or telnet'ing to port 80. Or grab them with old versions of 'fetch'.
I used to do all kinds of interesting and time-saving tasks on the pre-https internet with simple, static UNIX tools. As you can imagine, almost all of those workflows are now either broken or require a big huge pile of python libraries.
So in summary, I am sorry to deprive you of your righteous indignation. You can see from our properly implemented order form that we understand https just fine, thank you.
The real answer is that https-everywhere sounds like it's probably a good idea ... but also sounds like you should maybe get off of my lawn ... but I'm not sure yet.
If you want to support HTTP too, that's fine. But why redirect people who use HTTPS URLs back to the HTTP page?
In any case, modern software toolchains have no trouble with HTTPS. I can interact with it from the command line pretty easily with `wget` or `curl` and similar.
Man, you don't even understand basic security practices.
When going from a HTTP page to a HTTPS page, what guarantees can you give that I see the original content and clicked the proper link and that I was not MITM-ed?
A potential attacker can MITM and easily redirect me to any order page they want...
This is security 101.
I understand the attack you've outlined just fine.
What you don't understand is that people that don't notice being redirected to a different domain are not smart enough to be using rsync.net in the first place.
So it's not an issue.
Or, I should say, in the fifteen years that we have been providing "cloud storage"[1] it hasn't been an issue.
[1] It wasn't called "cloud storage" back then - our service predates the term.
Probably I (working in security and even checking certificates sometimes) would not even notice if it would point to a different domain like rsync-app.net or some random name with a valid cert. There are a ton of examples and valid points of putting different things to different TLDs. Why should I be suspicious? How should I know what domain, subdomain, whatever did you choose and why?
Maybe even https://order.rsync.net could be the link and YOU (the sysadmin of the service) might not even notice, because I'm pretty sure you don't check/monitor your DNS records every couple of minutes.
The reason "it did not happened yet", is not valid, because if could happen anytime in your service's lifetime. It's like an open door and no robbery happened yet, but the likelihood of it is happening is worse than if you at least close the door. It would be silly to complain "It has been open for a long time and there were no robbery." after it happened.
> "people that don't notice being redirected to a different domain are not smart enough to be using rsync.net in the first place."
This is just an assumption, I would not make that. You could be surprised. Sometimes even web developers don't understand how x509 certs and https work.
Your reasons may be plentiful, but if it's because you prefer the protocol, without the obstruction of handshake, I'd recommend using openssl s_client.
Obvious disclaimer: openssl binary may or may not be part of your system (although the same can be said about netcat and telnet)
The reason that the vast majority of rsync.net is not covered by https is because I personally have not yet decided how I feel, philosophically, about the notion of https-only websites.
As silly as it may sound to you, I very much like the fact that you can read rsync.net HOWTO pages with netcat. Or telnet'ing to port 80. Or grab them with old versions of 'fetch'.
I used to do all kinds of interesting and time-saving tasks on the pre-https internet with simple, static UNIX tools. As you can imagine, almost all of those workflows are now either broken or require a big huge pile of python libraries.
So in summary, I am sorry to deprive you of your righteous indignation. You can see from our properly implemented order form that we understand https just fine, thank you.
The real answer is that https-everywhere sounds like it's probably a good idea ... but also sounds like you should maybe get off of my lawn ... but I'm not sure yet.