That website is not a read-only, public marketing site. It contains their order page, which asks for personal information: https://www.rsync.net/signup/order.html
Their unencrypted pricing page links to that encrypted order form page. We all agree there should be no http to http transitions like that, right?
If you'll note, that encrypted order page is on the same host as their unencrypted pages. Both rsync.net and www.rsync.net covered by the cert. They have SSL set up already, and they just purposely redirect away to http for their static pages. That is a well-known ssl antipattern.
When you say "on the same host" do you mean "have the same DNS name" or do you mean literally on the same server? It's possible it's just behind the same load balancer so I'm curious what the threat model that you're concerned about is specifically.
To be clear: I don't like transitions like that either but that concern is something I've only previously had with sites that do e-commerce or login portal that's not on a different (sub)domain. Apple and some banking sites are notable examples that used to concern me (though I doubt they are still like that).
The threat for http to https transactions is that man in the middle can rewrite, drop, or add data before the user reaches the https site. See sslstrip[0] for an example of this attack.
Their unencrypted pricing page links to that encrypted order form page. We all agree there should be no http to http transitions like that, right?
If you'll note, that encrypted order page is on the same host as their unencrypted pages. Both rsync.net and www.rsync.net covered by the cert. They have SSL set up already, and they just purposely redirect away to http for their static pages. That is a well-known ssl antipattern.