RFC: fully secure SMTP connection for "hg email"

Matt Mackall mpm at selenic.com
Tue Mar 19 13:00:23 CDT 2013


On Tue, 2013-03-19 at 16:14 +0900, FUJIWARA Katsunori wrote:
> At Mon, 18 Mar 2013 15:11:19 -0500,
> Matt Mackall wrote:
> > 
> > On Mon, 2013-03-18 at 01:42 +0900, FUJIWARA Katsunori wrote:
> > >   3. do nothing any more in Mercurial
> > > 
> > >      for fully secure SMTP connection, users should use some external
> > >      tools supporting STARTTLS/SMTPS with valid cacerts
> > > 
> > >      it should bore users, especially on Windows (for limited/un-easy
> > >      options)
> > 
> > Here are the possible things a MITM attacker can do here:
> > 
> > a) tamper with an email
> > b) blackhole an email
> > c) read a secret email
> > d) forge an email
> > e) intercept SMTP auth login credentials (for plain auth modes)
> > 
> > But if we presume MITM capability, we can usually do (a) through (c) on
> > the insecure delivery side of the SMTP server instead. And of course, we
> > don't need MITM at all for (d).
> > 
> > So I would rate (a) through (d) as "meh". These are the sort of things
> > we're supposed to use GPG for (there's a good little project for
> > someone).
> 
> I agree.
> 
> > But (e) continues to be a real concern that we should aim to prevent.
> 
> I agree. 
> 
> I also understand that just encrypting SMTP connection by SSL can't
> ensure direct connection to peer, and it can't prevent MITM from
> intercepting auth information (username and/or password), so
> certificate of peer should be verified before auth step in SMTP. I'm
> right, ain't I ?

Yes, for the simplest auth modes (like plaintext, which is likely the
only one we support!), a MITM attacker can steal your auth credentials.
So we should validate the peer's certificate at connection setup time.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list