Re: gnus/starttls.el and net/tls.el

Re: gnus/starttls.el and net/tls.el

[Simon Josefsson]

(I'm cc'ing emacs-devel since there appears to be other threads
discussing this already.)

Richard Stallman <rms@gnu.org> writes:

> Can you tell me how these two files relate to each other?

They both create a TLS encrypted network socket using external tools,
but there is some differences:

tls.el starts talking TLS to the server directly.  starttls.el, however,
does not begin talking TLS until the application calls
starttls-negotiate.  In other words, starttls.el allows an unencrypted
phase before the encrypted phase starts.

tls.el can use openssl and gnutls.  starttls.el can use gnutls and a
tool called 'starttls'.

They serve (slightly) different purposes, but there is some code
duplication.  They probably should be merged eventually, but it requires
some effort (especially testing on many operating systems) and I'm
afraid I don't have time to work on it.

/Simon

Re: gnus/starttls.el and net/tls.el

[Richard Stallman]

    tls.el starts talking TLS to the server directly.  starttls.el, however,
    does not begin talking TLS until the application calls
    starttls-negotiate.  In other words, starttls.el allows an unencrypted
    phase before the encrypted phase starts.

Would it be hard to extend tls.el to provide a way to do this?

    tls.el can use openssl and gnutls.  starttls.el can use gnutls and a
    tool called 'starttls'.

What is the point of `starttls'?  For what purpose is it useful
to use that, rather than GNUtls?

Re: gnus/starttls.el and net/tls.el

[Simon Josefsson]

Richard Stallman <rms@gnu.org> writes:

>     tls.el starts talking TLS to the server directly.  starttls.el, however,
>     does not begin talking TLS until the application calls
>     starttls-negotiate.  In other words, starttls.el allows an unencrypted
>     phase before the encrypted phase starts.
>
> Would it be hard to extend tls.el to provide a way to do this?

It would require some work, but it is possible.  (Alas, I don't think I
have time to do it.)

Semantically, the tls-package could be implemented via starttls.el by
calling the 'open' and then the 'negotiate' function.  However, tls.el
and starttls.el differ by supporting different external tools, so some
users may get upset if, e.g., the 'starttls' or 'OpenSSL' way stops
working.

I'm not sure I understand the reason though.  Is it to avoid having two
files?  If so, how about moving the code in starttls.el into tls.el?
That would make it easier to slowly re-factor the code to avoid code
duplication.  On the other hand, starttls.el is used by a couple of
packages already, which may break.

>     tls.el can use openssl and gnutls.  starttls.el can use gnutls and a
>     tool called 'starttls'.
>
> What is the point of `starttls'?  For what purpose is it useful
> to use that, rather than GNUtls?

Today, I don't think there is any reason, but I may be biased towards
favoring GnuTLS.  gnutls-cli didn't used to support starttls operations,
but it does today.  As far as I remember, 'starttls' doesn't verify
server certificates, so starttls may be considered insecure.

/Simon

Re: gnus/starttls.el and net/tls.el

[Richard Stallman]

    I'm not sure I understand the reason though.  Is it to avoid having two
    files?

It is to avoid the code duplication.

	    If so, how about moving the code in starttls.el into tls.el?

I don't exactly object, but I am not sure that is the best way.

    Today, I don't think there is any reason, but I may be biased towards
    favoring GnuTLS.  gnutls-cli didn't used to support starttls operations,
    but it does today.  As far as I remember, 'starttls' doesn't verify
    server certificates, so starttls may be considered insecure.

It sounds like the thing to do is to reimplement the useful features
of starttls.el in tls.el.

Re: gnus/starttls.el and net/tls.el

[Simon Josefsson]

Richard Stallman <rms@gnu.org> writes:

>     I'm not sure I understand the reason though.  Is it to avoid having two
>     files?
>
> It is to avoid the code duplication.
>
> 	    If so, how about moving the code in starttls.el into tls.el?
>
> I don't exactly object, but I am not sure that is the best way.
>
>     Today, I don't think there is any reason, but I may be biased towards
>     favoring GnuTLS.  gnutls-cli didn't used to support starttls operations,
>     but it does today.  As far as I remember, 'starttls' doesn't verify
>     server certificates, so starttls may be considered insecure.
>
> It sounds like the thing to do is to reimplement the useful features
> of starttls.el in tls.el.

The problem is the different set of external dependencies:

 tls.el: use gnutls-cli (GnuTLS) or s_client (OpenSSL)
 starttls.el: use gnutls-cli (GnuTLS) or starttls

As far as I can tell, OpenSSL does not support the general starttls
behaviour, so we cannot switch to that tls.el and starttls.el both
support gnutls+openssl.  Depending on which mode you want to support
(direct tls or the starttls approach) the tls.el code need to change
which tool it uses.  Merging the code paths will lead to a rather
complex code-path, which is tricky to code and debug.  It will likely
also lead to new or different user variables, which will break existing
users configurations, which is another problem.

I'm afraid I don't have time to work on this now.  If someone else likes
to do it, I could try to help in discussions.

/Simon

Re: gnus/starttls.el and net/tls.el

[Richard Stallman]

I guess we are stuck with the duplication.

Could you write some text to compare the capabilities
and uses of tls.el and starttls.el, so people can tell which
is best for a given use, and insert that in the comments section
of both tls.el and starttls.el?

Re: gnus/starttls.el and net/tls.el

[Sascha Wilde]

Simon Josefsson <simon@josefsson.org> wrote:
> The problem is the different set of external dependencies:
>
>  tls.el: use gnutls-cli (GnuTLS) or s_client (OpenSSL)
>  starttls.el: use gnutls-cli (GnuTLS) or starttls
>
> As far as I can tell, OpenSSL does not support the general starttls
> behaviour, so we cannot switch to that tls.el and starttls.el both
> support gnutls+openssl.

I'm not sure that I properly understood the problem (and I haven't read
the whole thread), but OpenSSL supports StartTLS, like:

  openssl s_client -starttls smtp -connect mail.example.com

does this do what you need to support s_client in starttls.el?

cheers
sascha
-- 
Sascha Wilde : The sum of intelligence on earth is a constant; 
             : population is growing

Re: gnus/starttls.el and net/tls.el

[Simon Josefsson]

Sascha Wilde <wilde@sha-bang.de> writes:

> Simon Josefsson <simon@josefsson.org> wrote:
>> The problem is the different set of external dependencies:
>>
>>  tls.el: use gnutls-cli (GnuTLS) or s_client (OpenSSL)
>>  starttls.el: use gnutls-cli (GnuTLS) or starttls
>>
>> As far as I can tell, OpenSSL does not support the general starttls
>> behaviour, so we cannot switch to that tls.el and starttls.el both
>> support gnutls+openssl.
>
> I'm not sure that I properly understood the problem (and I haven't read
> the whole thread), but OpenSSL supports StartTLS, like:
>
>   openssl s_client -starttls smtp -connect mail.example.com
>
> does this do what you need to support s_client in starttls.el?

Not entirely, OpenSSL only supports starttls for a few application
protocols:

 -starttls prot - use the STARTTLS command before starting TLS
                 for those protocols that support it, where
                 'prot' defines which one to assume.  Currently,
                 only "smtp", "pop3", "imap", and "ftp" are supported.

Right now, in Emacs, I think starttls support is used for IMAP, SMTP,
POP3 and ManageSieve.  There is no support for Managesieve in OpenSSL...

Further, the starttls elisp functions in Emacs are application protocol
agnostic, so we would have to add a parameter to indicate which
application protocol is used.  That seems like a API layer violation,
but if there were no other problem (like the managesieve issue), maybe
we could do that.

/Simon

Re: gnus/starttls.el and net/tls.el

[Sascha Wilde]

Simon Josefsson <simon@josefsson.org> wrote:
> Sascha Wilde <wilde@sha-bang.de> writes:
>> Simon Josefsson <simon@josefsson.org> wrote:
>>> The problem is the different set of external dependencies:
>>>
>>>  tls.el: use gnutls-cli (GnuTLS) or s_client (OpenSSL)
>>>  starttls.el: use gnutls-cli (GnuTLS) or starttls
[...]
>> I'm not sure that I properly understood the problem (and I haven't read
>> the whole thread), but OpenSSL supports StartTLS, like:
>>
>>   openssl s_client -starttls smtp -connect mail.example.com
>>
>> does this do what you need to support s_client in starttls.el?
>
> Not entirely, OpenSSL only supports starttls for a few application
> protocols:

True.  What a pity (well, not to much for replacing OpenSSL with GnuTLS
is a good thing anyway, IMO). 

> Right now, in Emacs, I think starttls support is used for IMAP, SMTP,
> POP3 and ManageSieve.  There is no support for Managesieve in OpenSSL...

I see.  I haven't thought of managesieve here.

cheers
sascha
-- 
Sascha Wilde
Nota bene: wenn Word für Längeres geeignet wäre, würde es schließlich
nicht Word, sondern Sentence, Page oder Article heißen
 	-- Matthias Mühlich in dctt