Gnus development mailing list
 help / color / mirror / Atom feed
From: Ted Zlatanov <tzz@lifelogs.com>
To: ding@gnus.org
Subject: Re: Built-in TLS vs. nnimap security
Date: Thu, 29 Sep 2011 04:07:26 -0500	[thread overview]
Message-ID: <87ty7vlnsh.fsf@lifelogs.com> (raw)
In-Reply-To: <m3mxf7tvci.fsf@stories.gnus.org>

On Thu, 18 Aug 2011 02:30:05 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Romain Francoise <romain@orebokech.com> writes:
>> Is it a feature or a bug that when the built-in GnuTLS support is loaded
>> in Emacs, nnimap happily connects to my test imaps server even though the
>> certificate is self-signed and doesn't match the hostname?

LMI> It's a ... er ... missing feature.  :-)

>> Actually, shouldn't `open-gnutls-stream' do these checks by default
>> anyway? It's a new implementation, it doesn't have to follow the (poor)
>> historical defaults set by tls.el.

LMI> Yes, it's meant to do that, but nobody has actually implemented the
LMI> needed callbacks, I seem to remember?  Or did Ted do that, and I missed
LMI> it?  I was going to do the `open-network-stream' querying thing after
LMI> the required callbacks were in place.  The last thing I seem to vaguely
LMI> recall was Ted saying something about different verification callback
LMI> structures in different versions of the gnutls libraries, which made
LMI> things awkward.

We need the callbacks for custom certificate verification, but what
Romain describes simply needs the :verify-flags, :verify-error, and
:verify-hostname-error flags to `gnutls-negotiate'.
`open-gnutls-stream' doesn't pass them currently.  So the question is,
should they be:

1) always enabled, and the user has to Customize to turn them off per
host or globally

2) always disabled, and the user has to Customize to turn them on per
host or globally

3) when connecting to an unknown hostname, the user is asked and then we
save the results

Similarly we should make the :priority-string and :min-prime-bits
customizable per host, right now they are global as you and Lawrence
Mitchell implemented them.

Similarly we should have a way to set :trustfiles, :crlfiles, and
:keylist per host or globally.  For all these settings I don't know if
(1) or (2) or (3) is the best approach.

Obviously for (3) it would be annoying to ask all these questions so we
would make it a profile choice: "insecure," "intranet," or "internet."

Ted




  reply	other threads:[~2011-09-29  9:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-08 11:44 Romain Francoise
2011-08-18  0:30 ` Lars Magne Ingebrigtsen
2011-09-29  9:07   ` Ted Zlatanov [this message]
2011-10-06 21:23     ` Lars Magne Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ty7vlnsh.fsf@lifelogs.com \
    --to=tzz@lifelogs.com \
    --cc=ding@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).