Thanks for this, it seems a lot of discussions miss the point.
"You can achieve the exact same thing in C, you just have to be careful."
Of course you can. You can also drive at 160km/h safely or use an axe to chop onions in your kitchen "you just need to be careful" (with the subtle implication of "I can be careful, can you?". Narrator: no, you can't, you aren't as careful as you think)
And the other favourite of mine "HTTPS self-signed certs are useless, you're not authenticating the origin" while forgetting about the whole encryption thing. Yeah.
We're at a point in the diversity of tooling in software that subjectiveness is a genuine reason to choose one thing over another. Nitpicking fine points of performance is a very common way to miss the point. I could totally achieve the same thing in C, I just don't want to.
>> "HTTPS self-signed certs are useless, you're not authenticating the origin" while forgetting about the whole encryption thing.
The problem is that not validating the origin can make you vulnerable to a MitM attack. If the attacker can place themselves between you and the server, the attacker could intercept the real certificate from the origin server (containing the real public key) and then instead of forwarding you the origin server's certificate, the attacker could forward their own malicious certificate to you (containing the attacker's own public key) but pretending to be the origin server. Because the attacker's certificate would be self-signed, the browser cannot automatically authenticate that the certificate and public key provided actually belong to the (also self-signed) origin server and not some random attacker.
Then when the encryption begins, there will be encryption (that's true) but the encryption will happen between you and the attacker's machine and this is why it defeats the point.
It does not defeat the point if your attack vector is closer to your connection than closer to your server (e.g. untrusted connection). And in this case you can be your own CA and verify your own certificate.
It does not defeat the point because your regular HTTP server can be MitM in the same way so not having self-signed HTTPS because of that is moot.
>> And in this case you can be your own CA and verify your own certificate
If you want encryption for yourself only when accessing your own website, sure you can add yourself as a CA in your own browser and then you also get he benefit of authentication... That is a very niche use case though; not a typical/general use case. Also where the attacker is located doesn't matter. If your browser doesn't have the origin server's CA added in its certificate list then the attack can also be done in close proximity to your machine (e.g. WiFi endpoint). So while not always incorrect, your argument is generally incorrect.
>> It does not defeat the point because your regular HTTP server can be MitM in the same way so not having self-signed HTTPS because of that is moot.
For a typical use case, you add almost no security by having a self-signed certificate compared to using plain HTTP. The only difference between an attacker who is able to carry out a MitM attack over HTTP vs an attacker who can do the same attack over self-signed HTTPS is a few additional lines of code in the attacker's software to proxy the fake certs; basically they can break it just as easily just by having better software. It doesn't matter at all where the attacker is located; whether closer to the server (like an employee of an ISP) or the user's machine (like near a WiFi endpoint).
"You can achieve the exact same thing in C, you just have to be careful."
Of course you can. You can also drive at 160km/h safely or use an axe to chop onions in your kitchen "you just need to be careful" (with the subtle implication of "I can be careful, can you?". Narrator: no, you can't, you aren't as careful as you think)
And the other favourite of mine "HTTPS self-signed certs are useless, you're not authenticating the origin" while forgetting about the whole encryption thing. Yeah.