Adblock Plus and (a little) more
Mercurial over HTTPS - ouch, SSL isn't always secure · 2009-11-18 08:43 by Wladimir Palant
I set up my Mercurial server as HTTPS only. The idea behind it was that establishing a secure communication channel outweighs the disadvantages (server load, more traffic and somewhat slower pull operations) for a small server like that. But then I had second thoughts — I am using a StartCom certificate that isn’t yet accepted everywhere, what if somebody cannot pull the repository because of that?
So the question is which certificate store Mercurial is using to validate certificates. A quick Google search didn’t bring up anything relevant, I simply had to test it. And I discovered that Mercurial doesn’t validate server certificates at all! It doesn’t matter whether the server uses a self-signed certificate or whether the certificate is issued to a different server, Mercurial accepts them all. Which makes using HTTPS rather pointless, there are MITM tools that will easily intercept that connection if you are on a public WLAN network for example.
I originally planned to allow push via HTTPS if I need to give other people access, this is easier to set up. With what I learned now however I will better take the time and configure push via SSH. I just wished there would be a warning about this in the Mercurial documentation, as it is now the documentation suggests that publishing repositories via HTTPS is secure while the same thing over HTTP isn’t. And it is not like the developers aren’t aware of the problem (last two paragraphs).
Comment [5]
Commenting is closed for this article.
Justin Dolske · 2009-11-18 10:19 · #
Yeah, we discovered this in bug 450645, when looking at locking down pulls from Mozilla’s Hg repo. It’s quite disappointing.
Gijs · 2009-11-18 13:06 · #
Of course, the developer is also right in what he says… your average webbrowser is also vulnerable. How does the browser know to trust your cert? Because the CA is represented in its cert store. How did it get there? It was there on install (most likely). How did you get your browser? Over insecure ftp/http… oops! If you’re actually paranoid, you should be verifying certs out-of-band. :-)
The real question is, is someone going to care enough about your hg repo that they will go to the trouble of MITM’ing it. From where? To whom? For what purpose? It’s always a cost-benefit thing, and mercifully, most of us and/or most of our activities are not important enough to be hacked.
Reply from Wladimir Palant:
You download the browser only once (if ever) and you usually do it at home/office where you have a relatively secure internet connection. You use the source code repository all the time, including occasions where you are on an unencrypted public WLAN (conferences, airports). So while it is true that you are at risk on both occasions – these risks aren’t comparable.
If somebody MITMs a repository push via HTTPS (not necessarily targeting Adblock Plus, just generally trying to listen in on all HTTPS connections) he will get the username/password for the repository. This is an increasingly common scenario to get access to mail accounts and such, there are fully automatic tools to achieve that. If that person recognizes what he got there he could use it to upload his own change to the repo at any point in future. In the best-case scenario we are talking about 1000+ malware infections (development builds are generated automatically). In the worst-case scenario (if I don’t catch the manipulation before release) the number of infections will go into millions. That’s a risk I really don’t like, and IMO the chances aren’t as low as you think.
Reply from Wladimir Palant:
Oh, and don’t forget that the browser is signed – if it doesn’t say “Mozilla Corporation” when I try to install I will certainly check twice. This certificate is validated using the certificate store that comes with the OS, usually either pre-installed or installed from CD. This works quite well on Windows and I think OS X is similar.
Robert O'Callahan · 2009-11-19 06:06 · #
I use HTTPS for all my pulls just because it stops my ISP’s broken transparent caching proxy from breaking them.
Jan · 2010-03-28 07:16 · #
This is now finally possible with Mercurial 1.5:
put
[web]
cacerts = somefilewithpemencodedcerts
in your .hgrc and trusted certificates (PEM-format) in that file.
You’ll need Python 2.6 for it to work.
Greetings
Jan
Reply from Wladimir Palant:
Thank you, good to know – but too late now (and still too complicated). I’ve set up Mercurial over SSH a while ago, that should be the more secure alternative.
Manuel Reimer · 2010-10-22 10:16 · #
And with Mercurial 1.6.4 finally the hostname is properly verified. This really was a long way to get “secure HTTPS” on mercurial…
Yesterday, I used 1.6.4 for securely updating my SeaMonkey repository from Mozilla HG and it worked well. As nearly any Linux system comes with a preconfigured certificate file, anything, I had to do, is to point to this file in my .hgrc