Built-in TLS vs. nnimap security

Built-in TLS vs. nnimap security

[Romain Francoise]

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? Apparently it's
because nnimap uses `open-gnutls-stream' (via network-stream.el), which
doesn't enable any of the verification flags...

In the old world of tls.el, it was possible to get a secure connection by
setting `tls-checktrust' and removing --insecure from the `tls-program'
invocation. How can I get that back?

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.

Re: Built-in TLS vs. nnimap security

[Lars Magne Ingebrigtsen]

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?

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.

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

But I may be misremembering.  Anybody?  :-)

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

Re: Built-in TLS vs. nnimap security

[Ted Zlatanov]

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

Re: Built-in TLS vs. nnimap security

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> 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

I think the user should be queried if the certificate is "wrong".  I.e.,
if it's for the wrong hostname or expired and stuff like that.  And then
we should save the result.

> 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.

Yeah, the per-host storage thing is slightly tricky...

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