Ah Python, you have spoiled me for all other languages

[Chris Angelico]

On Sat, May 23, 2015 at 2:10 PM, Ian Kelly <ian.g.kelly at 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