Cannot pull/push to https server with self-signed certificate

[Gilles Moris]

On Sunday 09 January 2011 03:55:22 pm Yuya Nishihara wrote:
> > > Looking around at Yuya's debug print patch, I think we can achieve at
> > > least 1,2&3. We could check if this is self-signed certificate before
> > > connecting, and if the user agrees continue, use this PEM instead of
> > > the cacert from the hgrc. I'll give it a try.
> >
> > cool.
>
> Nice, but many people have been trained to click 'continue' button without
> knowing the risk. I'm afraid that this feature can lead to a security
> weakness.
>

OK, but what do you propose then ?
I was thinking about a kind of list of trusted host addresses in the hgrc

> > > I am not a fan poking around automatically in the hgrc file.
> >
> > I'm not a fan of it either, but I think we've started doing that for
> > username.
> >
> > Dumping *other* files onto the file system (pems) is IMO worse than
> > encoding lines into the file.
> >
> > doing this encoding is similar to how .ssh/known_hosts works
>
> SSH shows key fingerprint at initial connection.
> But my debug print patch provides no data enough to trust the remote host.

The whole X509 model for validation seems to be based on a hierarchical 
network of trust. As soon as you start creating a self-signed certificate, 
you just blow up the whole validation model.
I think that people that creates self-signed certs usually wants to have a 
point-to-point secure channel. If we do not relax the security constraint 
here, we risk to lose part of our users, or they will just use plain http 
instead.

So my proposal would be:
- read the server certificate before opening the socket
- if this is a self-signed certificate, look if is in a list of trusted hosts.
-- if yes, disable any validation (cacerts=None)
-- if no, just continue, as the connection will be rejected anyway during the 
validation when the socket will be opened.

Regards.
Gilles.