bug#16978: 24.3; SSL/TLS with multiple man-in-the-middle vulnerabilities

bug#16978: 24.3; SSL/TLS with multiple man-in-the-middle vulnerabilities

[Jens Lechtenboerger]

I'm using GNU Emacs 24.3.1.  This affects Gnus v5.13 as well as Ma
Gnus v0.9.

I'm using Emacs to send e-mail via smtpmail.el with
smtpmail-stream-type set to starttls, read e-mail via
imap with :port 993 and :stream ssl, and send/read news via port 563
with nntp-open-tls-stream for nntp-open-connection-function.

In all these cases, SSL/TLS "secured" connections are used that
accept any certificate without checking the CA.  Thus,
man-in-the-middle (MITM) attacks will be successful and will go
unnoticed.

I don't find that acceptable.  I vote to ship Emacs with certificate
checking by default.  That way, we would be protected from Mallory
with self-signed, forged keys.  I even vote for certificate pinning
by default, which can protect us from Mallory with "trusted" keys
(Mallory who pays, bribes, tricks, compels, forces, or operates an
official CA).  This can be accomplished via gnutls-cli with
trust-on-first-use:

gnutls-cli --tofu opens a TLS connection and asks whether the
certificate can be trusted.  If so, it is added to
~/.gnutls/known_hosts.  On subsequent connections, the presented
certificate is compared against the stored one; in case of
mismatches, the user is asked whether to trust the new one.  To
prevent the process from hanging while waiting for the user's reply,
option --strict-tofu (introduced in GnuTLS 3.2.12) can be used.
I'm describing my view on certificate pinning in general and some
details on TOFU with GnuTLS in more detail in my blog:
https://blogs.fsfe.org/jens.lechtenboerger/?p=208

For Emacs, here is my personal workaround (a real fix would
probably require a unified, secure-by-default treatment of TLS
throughout all libraries):

Smtpmail uses network-stream-open-starttls, which calls
gnutls-negotiate (from gnutls.el) later on.  The function
gnutls-negotiate has parameters VERIFY-HOSTNAME-ERROR and
VERIFY-ERROR, which might be useful to detect MITM attacks, yet they
are not used.

Also nntp-open-connection calls gnutls-negotiate without checking
certificates.

Thus, I disable gnutls.el entirely:
(if (fboundp 'gnutls-available-p)
    (fmakunbound 'gnutls-available-p))

However, the problem is not restricted to gnutls.el.
Once I disable that library, different fallbacks are used in
different libraries.

Smtpmail falls back to starttls-open-stream from starttls.el.
In my case, that library uses gnutls-cli, and --strict-tofu can be
added to starttls-extra-arguments:
(setq starttls-extra-arguments '("--strict-tofu"))

NNTP does not fall back to starttls.el but to open-tls-stream from
tls.el.  That library makes use of tls-program, which defaults to
gnutls-cli with the switch --insecure.  That switch is called
"insecure" for a good reason and should be removed, IMO.  Better
yet, enable certificate pinning:
(setq tls-program '("gnutls-cli --strict-tofu -p %p %h"))

The library imap.el makes use of openssl's s_client via
imap-ssl-program.  While s_client is great to debug SSL/TLS
connections, it is useless for everyday encryption as it prints an
error message if certificates cannot be verified, but it opens the
connection anyways.  And, those errors are not shown in Emacs.
So, switch to gnutls-cli with certificate pinning:
(setq imap-ssl-program '("gnutls-cli --strict-tofu -p %p %s"))

(Note that tls-program expects %h where imap-ssl-program uses %s.)

Best wishes
Jens

bug#16978: 24.3; SSL/TLS with multiple man-in-the-middle vulnerabilities

[Glenn Morris]

Please see http://debbugs.gnu.org/13374

bug#16978: 24.3; SSL/TLS with multiple man-in-the-middle vulnerabilities

[Jens Lechtenboerger]

On Mo, Mar 10 2014, Glenn Morris wrote:

> Please see http://debbugs.gnu.org/13374

I wasn't aware of that, sorry.

I'm now on GNU Emacs 24.3.50.1.  I can't get gnutls-verify-error to
work.  So far I only tried that with NNTPS, not SMTP.  If I set
gnutls-verify-error to t, the TCP connection to port 563 is closed
immediately (on the wire I see FIN/ACK immediately after the
three-way handshake; no TLS related data at all).
Afterwards, the server is shown as offline in the server buffer.
gnus-server-open-server fails as long as gnutls-verify-error is t.

imap.el is still using openssl's s_client.

tls.el is still using the switch --insecure for gnutls-cli.

Best wishes
Jens

bug#16978: 24.3; SSL/TLS with multiple man-in-the-middle vulnerabilities

[Ted Zlatanov]

On Mon, 10 Mar 2014 07:52:43 +0100 Jens Lechtenboerger <jens.lechtenboerger@fsfe.org> wrote: 

JL> I don't find that acceptable.  I vote to ship Emacs with certificate
JL> checking by default.

Hi Jens,

that's how it's planned, but please realize we have to be careful with
the large population of Emacs users that would be surprised by sudden
failures.  So 24.4 is the first version where we'll start doing this.

JL> gnutls-cli --tofu opens a TLS connection and asks whether the
JL> certificate can be trusted.  If so, it is added to
JL> ~/.gnutls/known_hosts.  On subsequent connections, the presented
JL> certificate is compared against the stored one; in case of
JL> mismatches, the user is asked whether to trust the new one.  To
JL> prevent the process from hanging while waiting for the user's reply,
JL> option --strict-tofu (introduced in GnuTLS 3.2.12) can be used.
JL> I'm describing my view on certificate pinning in general and some
JL> details on TOFU with GnuTLS in more detail in my blog:
JL> https://blogs.fsfe.org/jens.lechtenboerger/?p=208

That's wonderful, but please realize this doesn't work for Emacs because
often, interactive prompting would not be available.  The consensus so
far has been to abort the connection and tell the user how to allow a
host specifically.  Can you suggest a cleaner way, perhaps using TOFU
with some C automation?

(`gnutls-cli' should not be assumed to be available)

JL> For Emacs, here is my personal workaround (a real fix would
JL> probably require a unified, secure-by-default treatment of TLS
JL> throughout all libraries):

I appreciate all your review.  It's too late to make these changes for
24.4, but I think if you can review the state of things in 24.4, maybe
we could discuss an expedited 24.5 release with security fixes (that
would be up to the Emacs maintainers, of course).

Thanks
Ted

bug#16978: 24.3; SSL/TLS with multiple man-in-the-middle vulnerabilities

[Ted Zlatanov]

On Tue, 11 Mar 2014 18:04:25 +0100 Jens Lechtenboerger <jens.lechtenboerger@fsfe.org> wrote: 

JL> I'm now on GNU Emacs 24.3.50.1.  I can't get gnutls-verify-error to
JL> work.  So far I only tried that with NNTPS, not SMTP.  If I set
JL> gnutls-verify-error to t, the TCP connection to port 563 is closed
JL> immediately (on the wire I see FIN/ACK immediately after the
JL> three-way handshake; no TLS related data at all).
JL> Afterwards, the server is shown as offline in the server buffer.
JL> gnus-server-open-server fails as long as gnutls-verify-error is t.

Hi Jens,

I've tested this:

(require 'gnutls)
(setq gnutls-verify-error t)
(open-gnutls-stream "tls" "tls-buffer" "imap.gmail.com" "imaps")
(open-gnutls-stream "tls" "tls-buffer" "localhost" "imaps")

I just made a small change to allow the t in the above, so please update
to the latest.

Can you please run `gnutls-serv' with the right options and hit it
directly, and see if that replicates the issue?

Thanks
Ted

bug#16978: 24.3; SSL/TLS with multiple man-in-the-middle vulnerabilities

[Jens Lechtenboerger]

On 2014-03-17, Ted Zlatanov wrote:

> On Mon, 10 Mar 2014 07:52:43 +0100 Jens Lechtenboerger
> <jens.lechtenboerger@fsfe.org> wrote:
>
> JL> gnutls-cli --tofu opens a TLS connection and asks whether the
> JL> certificate can be trusted.
> JL> [...]
> JL> to prevent the process from hanging while waiting for the
> JL> user's reply, option --strict-tofu (introduced in GnuTLS
> JL> 3.2.12) can be used.
>
> That's wonderful, but please realize this doesn't work for Emacs because
> often, interactive prompting would not be available.  The consensus so
> far has been to abort the connection and tell the user how to allow a
> host specifically.

Hi Ted,

are you outlining plans for the future?  According to what I
observed so far, I’m either vulnerable to MITM attacks or I cannot
use servers with self-signed certificates.

I see three partially contradictory requirements here:
1. No interactive prompting.
2. Allow self-signed certificates.
3. Protect against MITM attacks (at least those involving
   self-signed forged certs; better yet, also with “trusted” forged
   certs).

Among those three, at most two can be guaranteed simultaneously.

From http://debbugs.gnu.org/13374 I got the impression that (2) is a
must.  (I rely on self-signed certs as well.)  In addition, in my
view (3) is a must.  Others may disagree and choose the convenience of
(1) over the security of (3).  If Emacs defaults to (1) over (3)
based on a deliberate decision, that decision needs to be documented
prominently.

Coming back to your comment, I believe that --strict-tofu satisfies
precisely what you describe: It aborts the connection, and you can
add the new certificate with --tofu.

> Can you suggest a cleaner way, perhaps using TOFU
> with some C automation?

I’m not really sure what you are looking for.

> (`gnutls-cli' should not be assumed to be available)

Sadly, that’s true.  But it could (a) be recommended and (b) be used
if it is available (and (c) be used in a safer way).

> I appreciate all your review.  It's too late to make these changes for
> 24.4, but I think if you can review the state of things in 24.4, maybe
> we could discuss an expedited 24.5 release with security fixes (that
> would be up to the Emacs maintainers, of course).

I’ll certainly work with 24.4.  Just let me know what kind of input
you need then.

Best wishes
Jens

bug#16978: 24.3; SSL/TLS with multiple man-in-the-middle vulnerabilities

[Jens Lechtenboerger]

On 2014-03-17, Ted Zlatanov wrote:

> (require 'gnutls)
> (setq gnutls-verify-error t)
> (open-gnutls-stream "tls" "tls-buffer" "imap.gmail.com" "imaps")
> (open-gnutls-stream "tls" "tls-buffer" "localhost" "imaps")
>
> I just made a small change to allow the t in the above, so please
> update to the latest.
>
> Can you please run `gnutls-serv' with the right options and hit it
> directly, and see if that replicates the issue?

Hi Ted,

I don’t see `gnutls-serv'.  The following works for me:
(open-gnutls-stream "tls" "tls-buffer" "imap.gmail.com" "imaps")

It also catches MITM attacks with self-signed certs:
(error "Certificate validation failed imap.gmail.com, verification
code 66")

That’s good.

Thanks
Jens

P.S. Self-signed certs are unusable now, e.g., this fails:
(open-gnutls-stream "tls" "tls-buffer" "news.gmane.org" "nntps")
Of course, this is to be expected, but Gnus aborts the connection
without any user-visible clue, and the server is reported to be
offline.

P.P.S. I’m using imap.el, which knows of various ways to establish
SSL/TLS connections, but gnutls.el is not among them.

bug#16978: 24.3; SSL/TLS with multiple man-in-the-middle vulnerabilities

[Ted Zlatanov]

On Tue, 18 Mar 2014 22:04:08 +0100 Jens Lechtenboerger <jens.lechtenboerger@fsfe.org> wrote: 

JL> I see three partially contradictory requirements here:
JL> 1. No interactive prompting.
JL> 2. Allow self-signed certificates.
JL> 3. Protect against MITM attacks (at least those involving
JL>    self-signed forged certs; better yet, also with “trusted” forged
JL>    certs).

JL> Among those three, at most two can be guaranteed simultaneously.

Right, of course.  That's the challenge.  Oh, and it must work for
everyone out of the box without ever checking release notes and the
manual :)

I think the self-signed certificates are the one we can omit, it's a
fairly rare use case.  We can provide a *simple* certificate manager UI
to list, display, and add/modify/remove certificates to make it easy,
but otherwise we can reject these with a suitable message "this
certificate can't be verified; to accept it run COMMANDHERE SITEHERE".
The certificate manager UI could do the TOFU interaction.

Once we have that we can reject unverified certificates, after 24.4 is
out.  Until then it has to be nil by default IMO.

JL> From http://debbugs.gnu.org/13374 I got the impression that (2) is a
JL> must.  (I rely on self-signed certs as well.)  In addition, in my
JL> view (3) is a must.  Others may disagree and choose the convenience of
JL> (1) over the security of (3).  If Emacs defaults to (1) over (3)
JL> based on a deliberate decision, that decision needs to be documented
JL> prominently.

JL> Coming back to your comment, I believe that --strict-tofu satisfies
JL> precisely what you describe: It aborts the connection, and you can
JL> add the new certificate with --tofu.

>> Can you suggest a cleaner way, perhaps using TOFU
>> with some C automation?

JL> I’m not really sure what you are looking for.

You provided the workflow above.  Now the question is, how can Emacs
implement it in a way that works interactively and non-interactively?

For storage of the certificates, I think
~/.emacs.d/certs/hostname.somextension is the right place.  I asked this
on gnutls-devel a while ago so we can revisit the discussion when we
have the UI worked out.

For the UI I suggested a certificate manager mode.  Maybe that's
overkill, I don't know.

>> I appreciate all your review.  It's too late to make these changes for
>> 24.4, but I think if you can review the state of things in 24.4, maybe
>> we could discuss an expedited 24.5 release with security fixes (that
>> would be up to the Emacs maintainers, of course).

JL> I’ll certainly work with 24.4.  Just let me know what kind of input
JL> you need then.

How to automate the TOFU, so far.

JL> I don’t see `gnutls-serv'.  The following works for me:
JL> (open-gnutls-stream "tls" "tls-buffer" "imap.gmail.com" "imaps")

JL> It also catches MITM attacks with self-signed certs:
JL> (error "Certificate validation failed imap.gmail.com, verification
JL> code 66")

JL> That’s good.

Wonderful!

JL> P.S. Self-signed certs are unusable now, e.g., this fails:
JL> (open-gnutls-stream "tls" "tls-buffer" "news.gmane.org" "nntps")
JL> Of course, this is to be expected, but Gnus aborts the connection
JL> without any user-visible clue, and the server is reported to be
JL> offline.

Hmm.  That seems a Gnus bug :) Can you submit it separately, to keep the
books clean, after testing with the latest Gnus?

JL> P.P.S. I’m using imap.el, which knows of various ways to establish
JL> SSL/TLS connections, but gnutls.el is not among them.

I think you're on an old Gnus then, which is strange considering you're
testing with a recent Emacs.  What's `M-x gnus-version'?

Ted

bug#16978: 24.3; SSL/TLS with multiple man-in-the-middle vulnerabilities

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I think the self-signed certificates are the one we can omit, it's a
> fairly rare use case.

No, it's quite common for mail servers and the like.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#16978: 24.3; SSL/TLS with multiple man-in-the-middle vulnerabilities

[Ted Zlatanov]

On Thu, 20 Mar 2014 15:39:28 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I think the self-signed certificates are the one we can omit, it's a
>> fairly rare use case.

LMI> No, it's quite common for mail servers and the like.

OK.  With a certificate manager UI, do you think this use case is
handled as I proposed, or do we need a more thorough solution here?

Ted

bug#16978: 24.3; SSL/TLS with multiple man-in-the-middle vulnerabilities

[Jens Lechtenboerger]

On Thu, 20 Mar 2014 09:43:50 -0400, Ted Zlatanov <tzz@lifelogs.com> said:

TZ> For storage of the certificates, I think
TZ> ~/.emacs.d/certs/hostname.somextension is the right place.  I
TZ> asked this on gnutls-devel a while ago so we can revisit the
TZ> discussion when we have the UI worked out.

Hi Ted,

GnuTLS uses the file ~/.gnutls/known_hosts.  I did not look into
this, but why do want to duplicate that functionality in Emacs?

JL> P.S. Self-signed certs are unusable now [...]

TZ> Hmm.  That seems a Gnus bug :) Can you submit it separately, to
TZ> keep the books clean, after testing with the latest Gnus?

Done: http://debbugs.gnu.org/17061

JL> P.P.S. I’m using imap.el, which knows of various ways to
JL> establish SSL/TLS connections, but gnutls.el is not among them.

TZ> I think you're on an old Gnus then, which is strange considering
TZ> you're testing with a recent Emacs.  What's `M-x gnus-version'?

v5.13 and Ma Gnus v0.10.  I’m using imap among `mail-sources' via
imap.el, not nnimap.  (The latter is on my todo list.)

Best wishes
Jens

bug#16978: 24.3; SSL/TLS with multiple man-in-the-middle vulnerabilities

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 20 Mar 2014 15:39:28 +0100 Lars Magne Ingebrigtsen
> <larsi@gnus.org> wrote:
>
> LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> I think the self-signed certificates are the one we can omit, it's a
>>> fairly rare use case.
>
> LMI> No, it's quite common for mail servers and the like.
>
> OK.  With a certificate manager UI, do you think this use case is
> handled as I proposed, or do we need a more thorough solution here?

No, a certificate manager UI is just what we need.  >"?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no