Copying nosy from issue643.

@mpm: It took me a second to follow your reasoning: Since all available clients
implement https weakly, it's the server's responsibility whether it offers https
access. I can live with that line.

I still believe we should issue a warning in the client to make the users aware
of the problem. https_warning2.patch does this and adds some documentation to
the pull command to point out the issue.

@mnordhoff: Sounds promising.

Add nosy from issue630, which is about the same thing.

Python's stdlib doesn't have any way to verify SSL certs. However, Python 2.6
will gain the 'ssl' module, which does support it, and it's been backported all
the way back to Python 2.3.5. Maybe hg could start to use it.

http://pypi.python.org/pypi/ssl/
http://docs.python.org/dev/library/ssl.html

I don't think this is the right approach, sorry.

The risk and responsibility is almost entirely on the server side. So any config
burden should be there as well.

Attached is a patch how I would issue such a warning.

It asks users of the https scheme if they want to proceed.
In non-interactive mode hg aborts.
Additionally the config option "use_insecure_https" can be set to always proceed.

Note that the patch breaks existing scripts using https (which you may want to
avoid). On the other hand I think people should be aware of the issue.

The patch still misses the docs and we have to decide which section the
use_insecure_https-option belongs to (XXX=ui?).

I don't expect much from the httplib in the near future, since the issue is know
for a longtime (at least they have a warning in their docs):
http://groups.google.com/group/comp.lang.python/browse_thread/thread/6b71417b251ce68d/3366c0161cf72598?lnk=gst&q=https#3366c0161cf72598

As for using "openssl s_client", the openssl man-page states:
"It’s [s_client] intended for testing purposes only."
So I'm not sure if we want to rely on that.

Correct on all counts. If you have suggestions on where to best document the
problem, I'd like to hear them.

It may be possible to make a quick hack around the problem by opening a pipe to
'openssl s_client -connect server:port' and using that for communications. This
is pretty analogous to what we do for ssh, actually.

As far as I understand:
Using the https protocol in hg is less secure than users are used to (from
browsers), since it does not rule out a man in the middle attack.

Usually the client can check, that he really talks to the server by making sure,
that his certificate is signed by a trusted CA. Hg does not make these checks.

Https in hg is still "more secure", than plain http since a man in the middle
attack requires more effort (though it's usually feasable).

A short solution would be to save the fingerprint of the certificate in the
.hgrc the first time the server is contacted and check against it in future
tries (similar to what ssh does). Unfortunally the python httplib does not seem
to be able to produce these fingerprints (which is IMHO a serious shortcomming
that should be fixed upstream).

So for now, I personally would like to have a warning displayed when the user
uses https, along the lines:
 "the https implementation in hg is less secure than you might expect, please
consider using ssh".

I didn't try to do a proof of concept man in the middle attack, so I might be
missing something.