tls-program

tls-program

[Lars Magne Ingebrigtsen]

The default value of tls-program is:

(defcustom tls-program '("gnutls-cli -p %p %h"
			 "gnutls-cli -p %p %h --protocols ssl3"
                         "openssl s_client -connect %h:%p -no_ssl2 -ign_eof")

With my five imaps test servers, the first two commands fail on four of
them, while the last command is successful on all five.

So moving the openssl command to the beginning of the list seems to give
me much shorter start-up time, so I'm assuming that might be the case
for most users.  (Isn't that how you do proof by induction?  "It's right
in one case, so it must be right in infinite number of cases."  Yeah, my
math education is coming back to me now...)

Would it be awful if I changed the default to use openssl first in the
list?
                         
-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: tls-program

[Ludovic Courtès]

Hi,

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> The default value of tls-program is:
>
> (defcustom tls-program '("gnutls-cli -p %p %h"
> 			 "gnutls-cli -p %p %h --protocols ssl3"
>                          "openssl s_client -connect %h:%p -no_ssl2 -ign_eof")
>
> With my five imaps test servers, the first two commands fail on four of
> them,

How does it fail?  Which version of GnuTLS is it?

GnuTLS 2.8.5 works like a charm here.

Thanks,
Ludo’.

Re: tls-program

[Sebastian Krause]

Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> The default value of tls-program is:
>
> (defcustom tls-program '("gnutls-cli -p %p %h"
> 			 "gnutls-cli -p %p %h --protocols ssl3"
>                          "openssl s_client -connect %h:%p -no_ssl2 -ign_eof")
>
> With my five imaps test servers, the first two commands fail on four of
> them, while the last command is successful on all five.

Are you sure you have the Debian package "gnutls-bin" (which
contains /usr/bin/gnutls-cli) installed? The first two used to fail
for me as well, but a simple "apt-get install gnutls-bin" fixed
it. Now the Gmail IMAP server works with gnutls-cli just fine.

I think it might be preferred by some to first try using GNU
software and only fall back to OpenSSL if that doesn't work.

Re: tls-program

[Sebastian Krause]

Sebastian Krause <sebastian@realpath.org> wrote:
> Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
>> The default value of tls-program is:
>>
>> (defcustom tls-program '("gnutls-cli -p %p %h"
>> 			 "gnutls-cli -p %p %h --protocols ssl3"
>>                          "openssl s_client -connect %h:%p -no_ssl2 -ign_eof")
>>
>> With my five imaps test servers, the first two commands fail on four of
>> them, while the last command is successful on all five.
>
> Are you sure you have the Debian package "gnutls-bin" (which
> contains /usr/bin/gnutls-cli) installed? The first two used to fail
> for me as well, but a simple "apt-get install gnutls-bin" fixed
> it. Now the Gmail IMAP server works with gnutls-cli just fine.

Uhh, nevermind. If it succeeds on one, it must be installed. :) I
somehow missed that. However, I can confirm that it works with Gmail
here. Is that the one that didn't fail for you?

Re: tls-program

[Lars Magne Ingebrigtsen]

Sebastian Krause <sebastian@realpath.org> writes:

> Are you sure you have the Debian package "gnutls-bin" (which
> contains /usr/bin/gnutls-cli) installed?

Looks like it:

[larsi@quimbies ~/pgnus]$ type gnutls-cli
gnutls-cli is /usr/bin/gnutls-cli

> The first two used to fail for me as well, but a simple "apt-get
> install gnutls-bin" fixed it. Now the Gmail IMAP server works with
> gnutls-cli just fine.

Yes, the Gmail IMAP server is the only one of the five servers that
gnutls-cli works with.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: tls-program

[Sebastian Krause]

Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> Sebastian Krause <sebastian@realpath.org> writes:
>> The first two used to fail for me as well, but a simple "apt-get
>> install gnutls-bin" fixed it. Now the Gmail IMAP server works with
>> gnutls-cli just fine.
>
> Yes, the Gmail IMAP server is the only one of the five servers that
> gnutls-cli works with.  :-)

Since I can imagine that the native TLS in Emacs 24 will probably be
based on GnuTLS as well (just guessing), it might be worth trying to
find out what's going wrong here. What happens when you try to
directly connect to the servers from the shell, e.g. with "gnutls-cli
-p 993 imap.example.com"?

Re: tls-program

[Lars Magne Ingebrigtsen]

Sebastian Krause <sebastian@realpath.org> writes:

> Since I can imagine that the native TLS in Emacs 24 will probably be
> based on GnuTLS as well (just guessing), it might be worth trying to
> find out what's going wrong here. What happens when you try to
> directly connect to the servers from the shell, e.g. with "gnutls-cli
> -p 993 imap.example.com"?

Excellent point.

It turns out that gnutls-cli terminates with:

- The hostname in the certificate does NOT match '<host name>'

So the IMAP servers have certificates that don't match their names.  I'm
guessing that that's common?  Adding --insecure fixes this.

So...  what would be the nicest behaviour here?  Adding --insecure would
probably not be nice.  But not nice to not work, either.

Hang on.  Why does the openssh thing work if the certificate isn't
valid?

Ah.  It says

    Verify return code: 10 (certificate has expired)

and then continues merrily on.  So gnutls-cli defaults to secure, while
openssl defaults to insecure?  That seems inconsistent.  So perhaps
adding --insecure is the right thing, after all?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: tls-program

[Daniel Pittman]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Sebastian Krause <sebastian@realpath.org> writes:
>
>> Since I can imagine that the native TLS in Emacs 24 will probably be based
>> on GnuTLS as well (just guessing), it might be worth trying to find out
>> what's going wrong here. What happens when you try to directly connect to
>> the servers from the shell, e.g. with "gnutls-cli -p 993 imap.example.com"?
>
> Excellent point.
>
> It turns out that gnutls-cli terminates with:
>
> - The hostname in the certificate does NOT match '<host name>'
>
> So the IMAP servers have certificates that don't match their names.  I'm
> guessing that that's common?  Adding --insecure fixes this.

Probably reasonably, outside the nicer parts of the world.

> So...  what would be the nicest behaviour here?  Adding --insecure would
> probably not be nice.  But not nice to not work, either.
>
> Hang on.  Why does the openssh thing work if the certificate isn't
> valid?
>
> Ah.  It says
>
>     Verify return code: 10 (certificate has expired)
>
> and then continues merrily on.  So gnutls-cli defaults to secure, while
> openssl defaults to insecure?  That seems inconsistent.  So perhaps
> adding --insecure is the right thing, after all?

I would be inclined to do that, from a UI point of view, but it is rather
nasty.  A better approach might be to force them explicitly to secure[1],
detect the appropriate warnings, and either prompt the user, or educate them
about what has to happen?

        Daniel

Footnotes: 
[1]  Against gnutls getting a global config file and the admin changing it,
     for example.

-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons

Re: tls-program

[Tibor Simko]

On Sun, 19 Sep 2010, Lars Magne Ingebrigtsen wrote:
> So perhaps adding --insecure is the right thing, after all?

What about detecting this case and advising people to customize-variable
`starttls-extra-arguments' to include `--insecure' if they want to?
Seems safer just to advise it rather than making it default.

Best regards
-- 
Tibor Simko

Re: tls-program

[Lars Magne Ingebrigtsen]

Daniel Pittman <daniel@rimspace.net> writes:

> I would be inclined to do that, from a UI point of view, but it is rather
> nasty.  A better approach might be to force them explicitly to secure[1],
> detect the appropriate warnings, and either prompt the user, or educate them
> about what has to happen?

Well, if having invalid certificates is really common on IMAP servers,
then annoying them with this would be...  annoying.

Does anybody know what (say) Thunderbird does in these instances?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: tls-program

[Lars Magne Ingebrigtsen]

Tibor Simko <tibor.simko@cern.ch> writes:

> What about detecting this case and advising people to customize-variable
> `starttls-extra-arguments' to include `--insecure' if they want to?
> Seems safer just to advise it rather than making it default.

Well, this is tls.el, not starttls.el.  :-)

The default of tls-checktrust is nil, so I think the missing --insecure
might be a bug...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: tls-program

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> The default of tls-checktrust is nil, so I think the missing --insecure
> might be a bug...

Oh, I misunderstood that variable.  It's about root certs and chains and
stuff, and not the server cert directly.  I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: tls-program

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Well, if having invalid certificates is really common on IMAP servers,
> then annoying them with this would be...  annoying.

They aren't neccessarily invalid.  In many cases they are self signed,
and can't be verified because they aren't signed by a CA in the client's
certificate store.

So they are the typical case for someone with a private dovecot imap
server, running on a debian box somewhere.

Re: tls-program

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> So they are the typical case for someone with a private dovecot imap
> server, running on a debian box somewhere.

Yes, that's what I would have imagined.

And adding --insecure to the gnutls-cli entries doesn't really change
the behaviour for most people.  tsl.el (at present) falls back on using
openssl, which is insecure by default, so the only effect for people
would be that tls.el would be faster.

(The only ones who would see an actual switch from secure to insecure
would be those that don't have openssl installed at all.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: tls-program

[Frank Schmitt]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Daniel Pittman <daniel@rimspace.net> writes:
>
>> I would be inclined to do that, from a UI point of view, but it is rather
>> nasty.  A better approach might be to force them explicitly to secure[1],
>> detect the appropriate warnings, and either prompt the user, or educate them
>> about what has to happen?
>
> Well, if having invalid certificates is really common on IMAP servers,
> then annoying them with this would be...  annoying.
>
> Does anybody know what (say) Thunderbird does in these instances?

It gives a warning message where one can inspect the certificate and has
buttons accept temporarily, accept forever, cancel.

-- 
Have you ever considered how much text can fit in eighty columns?  Given that a
signature typically contains up to four lines of text, this space allows you to
attach a tremendous amount of valuable information to your messages.  Seize the
opportunity and don't waste your signature on bullshit that nobody cares about.

Re: tls-program

[Lars Magne Ingebrigtsen]

Frank Schmitt <ich@frank-schmitt.net> writes:

> It gives a warning message where one can inspect the certificate and has
> buttons accept temporarily, accept forever, cancel.

That seems reasonable.  Perhaps tls.el should do the same?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: tls-program

[David Engster]

Lars Magne Ingebrigtsen writes:
> Steinar Bang <sb@dod.no> writes:
>
>> So they are the typical case for someone with a private dovecot imap
>> server, running on a debian box somewhere.
>
> Yes, that's what I would have imagined.

gnutls-cli accepts self-signed certificates by default:

- The hostname in the certificate matches 'mydomain.foobar'.
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted

but it continues anyway. I think it only balks when you explicitly
specify your trusted CAs through --x509cafile or something similar. If
you specify your trusted CAs, it seems you can set tls-checktrust to
'ask and get a similar behavior like Thunderbird's et al.

However, a hostname mismatch is not tolerated, and can only be
overridden with --insecure. This shouldn't be the default,
though. Openssl indeed always continues by default, but I think a
hostname mismatch should at least be warned about.

-David

Re: tls-program

[Lars Magne Ingebrigtsen]

David Engster <deng@randomsample.de> writes:

> gnutls-cli accepts self-signed certificates by default:
>
> - The hostname in the certificate matches 'mydomain.foobar'.
> - Peer's certificate issuer is unknown
> - Peer's certificate is NOT trusted

One of the servers had a self-signed expired certificate, which made
gnutls-cli abort...

> However, a hostname mismatch is not tolerated, and can only be
> overridden with --insecure. This shouldn't be the default,
> though. Openssl indeed always continues by default, but I think a
> hostname mismatch should at least be warned about.

Querying the user, and then saving the result of the query would be the
best compromise between usability and security here, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: tls-program

[James Cloos]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

LMI> Yes, the Gmail IMAP server is the only one of the five servers that
LMI> gnutls-cli works with.  :-)

I just tried gnutls-cli manually with freeshell.org's server, pointing
at port imaps, and that worked fine to login, but gave this when I
logged out:

1 OK LOGOUT completed
*** Fatal error: A TLS packet with unexpected length was received.
*** Server has terminated the connection abnormally.

Openssl also worked, and did not give an error on close.

Since none of those commands work for a STARTTLS server, one must
assume that all of your servers use the imaps port, yes?

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: tls-program

[James Cloos]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

LMI> So gnutls-cli defaults to secure, while openssl defaults to
LMI> insecure?  That seems inconsistent.  So perhaps adding --insecure
LMI> is the right thing, after all?

OpenSSL's s_client is a testing app.  AFAIU, gnutls-cli is intended to
be a production app.

That would explain the difference.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: tls-program

[Lars Magne Ingebrigtsen]

James Cloos <cloos@jhcloos.com> writes:

> Since none of those commands work for a STARTTLS server, one must
> assume that all of your servers use the imaps port, yes?

Yes, I have not tested with starttls -- I don't have access to any such
servers...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: tls-program

[Ted Zlatanov]

On Sun, 19 Sep 2010 19:47:23 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Querying the user, and then saving the result of the query would be the
LMI> best compromise between usability and security here, I think.

We could save it in authinfo, e.g.

machine x user y certificate [encoded string]

where the encoded string contains the certificate plus info on how it
got accepted and when.  But auth-source.el needs work to achieve this.

Ted

Re: tls-program

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> LMI> Querying the user, and then saving the result of the query would be the
> LMI> best compromise between usability and security here, I think.
>
> We could save it in authinfo, e.g.
>
> machine x user y certificate [encoded string]

Or in the .authinfo.gpg file?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen