On Sat, May 23, 2015 at 2:10 PM, Ian Kelly <ian.g.ke...@gmail.com> wrote: >> Sigh. I blame this as much on the browser. There's no inherent reason >> why a connection to a site secured with a self-signed certificate is >> insecure. In fact it's definitely not. > > Sure it is. Without some prior reason to trust the certificate, the > certificate is meaningless. How is the browser to distinguish between > a legitimate self-signed cert and a self-signed cert presented by an > attacker conducting a man-in-the-middle attack? > > There is still some value in TLS with a self-signed certificate in > that at least the connection is encrypted and can't be eavesdropped by > an attacker who can only read the channel, but there is no assurance > that the party you're communicating with actually owns the public key > that you've been presented.
To be fair, certificates never actually tell you that the owner is legitimate - all they do is move the problem. Self-signed certs move the problem to "how do you get a guaranteed copy of this exact server's certificate", which makes it an out-of-band issue (if you meet someone you know in person and get a copy of the cert on a USB stick, then manually install it, you can be sure it's safe); externally-signed certs move the problem to the certificate chain and its reliability (how well do the CSAs check ownership prior to issuing a certificate?). Both are still problematic, just in different ways. Self-signed certs are ideal if you're packaging your own client - you could keep the IP address and certificate in the same VCS repository. Anyone who can change the cert can also change the IP address, so you lose no security there. But they're way WAY more hassle for https on the public internet. ChrisA -- https://mail.python.org/mailman/listinfo/python-list