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