>> 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 c

>> 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).