* Built-in TLS vs. nnimap security @ 2011-08-08 11:44 Romain Francoise 2011-08-18 0:30 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 4+ messages in thread From: Romain Francoise @ 2011-08-08 11:44 UTC (permalink / raw) To: ding 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Built-in TLS vs. nnimap security 2011-08-08 11:44 Built-in TLS vs. nnimap security Romain Francoise @ 2011-08-18 0:30 ` Lars Magne Ingebrigtsen 2011-09-29 9:07 ` Ted Zlatanov 0 siblings, 1 reply; 4+ messages in thread From: Lars Magne Ingebrigtsen @ 2011-08-18 0:30 UTC (permalink / raw) To: ding 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/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Built-in TLS vs. nnimap security 2011-08-18 0:30 ` Lars Magne Ingebrigtsen @ 2011-09-29 9:07 ` Ted Zlatanov 2011-10-06 21:23 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 4+ messages in thread From: Ted Zlatanov @ 2011-09-29 9:07 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Built-in TLS vs. nnimap security 2011-09-29 9:07 ` Ted Zlatanov @ 2011-10-06 21:23 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 4+ messages in thread From: Lars Magne Ingebrigtsen @ 2011-10-06 21:23 UTC (permalink / raw) To: ding 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/ ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-10-06 21:23 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-08-08 11:44 Built-in TLS vs. nnimap security Romain Francoise 2011-08-18 0:30 ` Lars Magne Ingebrigtsen 2011-09-29 9:07 ` Ted Zlatanov 2011-10-06 21:23 ` Lars Magne Ingebrigtsen
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).