self-signed certificates and SNI

Haszlakiewicz, Eric EHASZLA at transunion.com
Mon Jan 24 12:01:37 CST 2011


>-----Original Message-----
>From: mercurial-bounces at selenic.com [mailto:mercurial-bounces at selenic.com]
>
>I agree that we could add a "when I connect to server X then it is ok if
>I get server Y instead" configuration option:
>
>--- a/mercurial/url.py
>+++ b/mercurial/url.py
>@@ -538,6 +538,7 @@
>                  self.sock = _ssl_wrap_socket(sock, self.key_file,
>                          self.cert_file, cert_reqs=CERT_REQUIRED,
>                          ca_certs=cacerts)
>+                self.host = self.ui.config('certalias', self.host,
>self.host)
>                  msg = _verifycert(self.sock.getpeercert(), self.host)
>                  if msg:
>                      raise util.Abort(_('%s certificate error: %s') %
>
>(we shouldn't change self.host, but this shows the idea.)
>
>BUT it would add complexity to something that already is complex and few
>understand. And if the primary use case is supporting configurations
>that uses features that we don't support then it might not be worth it.

This feature would be useful even without SNI in the picture.  There have been many times where I've needed to access a server in a way where the "hostname" I use doesn't match up with the certificate name (think: broken DNS over VPN tunnels), and being able to tell hg "yes, I really do want to connect to that machine, ignore the cert problem", is kind of critical.

Take an example from Subversion.  If there's a certificate problem when running a svn command, it tell me what's wrong, then prompts me to see whether I want to continue or not.  It also gives me the option to permanently store the exception.  IMO, from a usability perspective that's the right way to handle this.

eric



More information about the Mercurial mailing list