Why Static Websites Need HTTPS

CSP headers won't ever reach the browser if the attacker has MITM, so they are irrelevant.

Historically a Certificate Authority did whatever it pleased to validate control over the name. It is _definitely_ true that an adversary who "was on your gear" could get a certificate.

Once the CA/B Forum comes into existence (which is when those green bar "EV" certificates appear) there are rules for how to do this validation, but, crucially, those rules have a clause which says "Any other method". Yup, CAs were still free to do whatever they wanted.

By 2010 or so they could get a "free trial" certificate, which would be annoying for a real site owner but crooks don't care about that, the "free trial" period is long enough to get the job done, and if the site's actual owners get billed for exceeding their "free trial" well boo hoo.

In 2016 the CA/B voted on new rules for validation which got rid of "Any other method" but although the vote passed, it was tied up in lawyer hell because it turns out commercial CAs owned patents on lots of crappy methods.

In summer 2017 Mozilla got tired of the foot-dragging caused by lawyers and simply changed _their_ trust rules, which in effect unilaterally changes the rules for a public CA since "Our certificates don't work in Firefox" might as well say "We don't want to be in business any more, bye".

These new rules are the Ten Blessed Methods (but now only eight or nine are in use) but crucially Let's Encrypt, unlike a lot of commercial CAs, had been compliant from its creation, indeed its staff helped write them.

Your rosy view is totally wrong, here are two REAL examples of things actual publicly trusted CAs were doing prior to the Ten Blessed Methods which weren't even _prohibited_ even though they're worthless:

1. Send an email to administrator@example.com with a link in it. If the link is resolved, this validates that the legitimate owner of example.com wanted a certificate issued for any name under example.com

What if an "anti-virus" gateway dereferences the link to check if it's a viral payload before trying to even deliver the email?

"Hi, An Actual Criminal wants a certificate issued for login.yourbank.example. As the Administrator please click this link to authorise this certificate."

[ AV software dereferences link. Cert issued to An Actual Criminal. The system works... ]

"I'm sorry, administrator@yourbank.example doesn't exist"

[ Oh right, nobody at yourbank.example actually even saw the verification message. Well I'm sure it's fine ]

2. Tell the applicant to specify a URL where they can see a special one-time code, once the applicant confirms that's done check the one-time code is seen at that URL

What if the attacker suggests a URL that is just the one-time code, URL escaped, and the result is a 404 error reciting the code because that's just how your server's 404 errors work?

Nobody would accept a 404 error as proof? Right? Wrong. Well, OK, but once they fixed that it's fine, right? Wrong, lots of commercial HTTP servers don't send 404, they send a redirect and paste your message into the redirect, thus passing the test.

Let's Encrypt's design actually does a pretty good job here, if you feel this isn't enough then the reality is that before the Ten Blessed Methods many other trusted CAs were _worse_

At that distance the very physical latency limit is almost a second. You can literally not go below. The high latency will have a lot of protocols simply time out or consider the packet lost.

At that distance you need some well engineered ground equipment to handle the signal losses. A dish and a high powered transmitter that need to be within a degree of the target. If you're off by a degree you're likely going to hit very bad packet loss. A degree is not much and you could be cause by the ground below stretching and twisting over the day due to temperature changes. TV doesn't have to deal with sending data up the link other than using the massively more powerful and expensive dishes from TV networks.

Lastly, from ground to geostationary orbit you may find that your 40MHz band is full of crap. Not because someone else is sending but because you're sending through a solid belt of radiation and magnetic flux. You'll find that for a wide range of bands they either suck at penetrating the atmosphere, penetrating the magnetic field or get sucked up by interference from half the universe.

The layers above IP have ways to handle packet loss for a reason (although the reason was bad copper cables and bad MAC). Also, the MAC is another problem; you're not the only one who wants to use the very limited resources of the sat. One of the most common and effective forms of bandwidth limiting is dropping packets and it's normal. Packets drop all the time, every TCP connection drops packets. It happens and almost all protocols deal with it on one level or another.

What about HTTP2?