Bug#499774: starttls is a joke

Bug#499774: starttls is a joke

[Arnaud Ebalard]

Package: starttls
Version: 0.10-3
Severity: critical

starttls package should IMHO be removed from Debian repositories, as it
looks like a security joke:

- it does not allow passing trust anchors to be used to verify the
  remote peer: are users expected to see the issue by themselves and not
  use it?
- usage advertises a --verify option to set the verificaion level (no
  details on accepted values): in all cases, it is not considered in the
  code and SSL_VERIFY_NONE is used instead.
- The man page does not describe the options the program accept and does
  not warn the user about the lack of checks.

AFAICT, starttls provides a good example of how OpenSSL API should *not*
be used! Its use should only be limited to testing purposes and a *huge*
disclaimer on its limitations should be put somewhere.

Comments welcome.

Cheers,

a+

ps: emacs-mime-en@m17n.org is in CC, because previous list of issues is
    still valid against CVS version of starttls.
pps: Gnus ML is in CC as some people might be using it (for years?).

Bug#499774: starttls is a joke

[RISKO Gergely]

Sorry, I haven't noticed that you have cc'd mailing lists.  Please
find below my first response to Arnaud.

You surely knows about the gnus usage of this, since you CC'd the
mailing list, sorry.

So my option is that a disclaimer should be placed, but SSL with
SSL_VERIFY_NONE is MUCH, MUCH, MUCH better than not using SSL at all.
And the joke is SSL's security model - where you are considered secure
if you pay $500/year -, not starttls.

-=- my original response here: -=-

severity 499774 wishlist
thanks

Dear Arno,

Thanks for your suggestions and reasoning.  Probably you haven't
noticed that starttls is mainly an integration utility for mainly
GNU/Emacs.  And yeah, it is also good for testing StartTLS based
services as a system administrator.

I'm against the removal, since it will break imaps/pop3s connections
from emacs based muas (I'm at least sure in gnus, I use it hourly).
And I'm also against the removal, because this is a very good tool for
testing.

You are right, it's package description should be changed and a
disclaimer should be placed.  Probably an 'are you sure?' question
shouldn't be implemented (or if implemented, it shouldn't be the
default), because it would block integrations like with emacs.

As this is a documentation or a new feature request issue, I
changed severity to wishlist.

Thanks again for your contribution to Debian, if you write the
disclaimer in a few world that should be appended to the package
description in your opinion, it would be a big help.

Gergely

On Mon, 22 Sep 2008 10:52:06 +0200, arno@natisbad.org (Arnaud Ebalard) writes:

> Package: starttls
> Version: 0.10-3
> Severity: critical
>
> starttls package should IMHO be removed from Debian repositories, as it
> looks like a security joke:
>
> - it does not allow passing trust anchors to be used to verify the
>   remote peer: are users expected to see the issue by themselves and not
>   use it?
> - usage advertises a --verify option to set the verificaion level (no
>   details on accepted values): in all cases, it is not considered in the
>   code and SSL_VERIFY_NONE is used instead.
> - The man page does not describe the options the program accept and does
>   not warn the user about the lack of checks.
>
> AFAICT, starttls provides a good example of how OpenSSL API should *not*
> be used! Its use should only be limited to testing purposes and a *huge*
> disclaimer on its limitations should be put somewhere.
>
> Comments welcome.
>
> Cheers,
>
> a+
>
> ps: emacs-mime-en@m17n.org is in CC, because previous list of issues is
>     still valid against CVS version of starttls.
> pps: Gnus ML is in CC as some people might be using it (for years?).

Re: Bug#499774: starttls is a joke

[Arnaud Ebalard]

Hi,

RISKO Gergely <risko@debian.org> writes:

> Sorry, I haven't noticed that you have cc'd mailing lists.  Please
> find below my first response to Arnaud.

At least, thanks for the quick reply.

> You surely knows about the gnus usage of this, since you CC'd the
> mailing list, sorry.

yes.

> So my option is that a disclaimer should be placed, but SSL with
> SSL_VERIFY_NONE is MUCH, MUCH, MUCH better than not using SSL at all.

No, it is not. It is worse. It provides a feeling of security to the
people that use it. It is like driving with deactivated airbags.

> And the joke is SSL's security model - where you are considered secure
> if you pay $500/year -, not starttls.

1) I use my own PKI for some of my services, which costs me nothing.
2) As a client, you do not pay for the server certificates (cf gmail)
   and trust anchors.
3) It is a lame excuse.

> -=- my original response here: -=-
>
> severity 499774 wishlist
> thanks
>
> Dear Arno,
>
> Thanks for your suggestions and reasoning.  Probably you haven't
> noticed that starttls is mainly an integration utility for mainly
> GNU/Emacs.  And yeah, it is also good for testing StartTLS based
> services as a system administrator.
>
> I'm against the removal, since it will break imaps/pop3s connections
> from emacs based muas (I'm at least sure in gnus, I use it hourly).

Then, someone should correct the code to support passing trust anchors,
allow passing the verify value, and document capabilities and
limitations. 

> And I'm also against the removal, because this is a very good tool for
> testing.

I will also send a copy of this reply to security@debian.org.

> You are right, it's package description should be changed and a
> disclaimer should be placed.  Probably an 'are you sure?' question
> shouldn't be implemented (or if implemented, it shouldn't be the
> default), because it would block integrations like with emacs.
>
> As this is a documentation or a new feature request issue, I
> changed severity to wishlist.

It is not a "wishlist" feature, it is a security issue.

> Thanks again for your contribution to Debian, if you write the
> disclaimer in a few world that should be appended to the package
> description in your opinion, it would be a big help.

"This software does not have any authentication capabilities: it does
not allow you to authenticate your peer, which is a basic requirement
for TLS/SSL to be used securely. You should only use it for testing
purposes and not relaying important information. Be aware that you are
vulnerable to MITM when using it"

Cheers,

a+

Bug#499774: starttls is a joke

[Arnaud Ebalard]

Hi,                                     [resending, forgot some CC]

RISKO Gergely <risko@debian.org> writes:

> Sorry, I haven't noticed that you have cc'd mailing lists.  Please
> find below my first response to Arnaud.

At least, thanks for the quick reply.

> You surely knows about the gnus usage of this, since you CC'd the
> mailing list, sorry.

yes.

> So my option is that a disclaimer should be placed, but SSL with
> SSL_VERIFY_NONE is MUCH, MUCH, MUCH better than not using SSL at all.

No, it is not. It is worse. It provides a feeling of security to the
people that use it. It is like driving with deactivated airbags.

> And the joke is SSL's security model - where you are considered secure
> if you pay $500/year -, not starttls.

1) I use my own PKI for some of my services, which costs me nothing.
2) As a client, you do not pay for the server certificates (cf gmail)
   and trust anchors.
3) It is a lame excuse.

> -=- my original response here: -=-
>
> severity 499774 wishlist
> thanks
>
> Dear Arno,
>
> Thanks for your suggestions and reasoning.  Probably you haven't
> noticed that starttls is mainly an integration utility for mainly
> GNU/Emacs.  And yeah, it is also good for testing StartTLS based
> services as a system administrator.
>
> I'm against the removal, since it will break imaps/pop3s connections
> from emacs based muas (I'm at least sure in gnus, I use it hourly).

Then, someone should correct the code to support passing trust anchors,
allow passing the verify value, and document capabilities and
limitations. 

> And I'm also against the removal, because this is a very good tool for
> testing.

I will also send a copy of this reply to security@debian.org.

> You are right, it's package description should be changed and a
> disclaimer should be placed.  Probably an 'are you sure?' question
> shouldn't be implemented (or if implemented, it shouldn't be the
> default), because it would block integrations like with emacs.
>
> As this is a documentation or a new feature request issue, I
> changed severity to wishlist.

It is not a "wishlist" feature, it is a security issue.

> Thanks again for your contribution to Debian, if you write the
> disclaimer in a few world that should be appended to the package
> description in your opinion, it would be a big help.

"This software does not have any authentication capabilities: it does
not allow you to authenticate your peer, which is a basic requirement
for TLS/SSL to be used securely. You should only use it for testing
purposes and not relaying important information. Be aware that you are
vulnerable to MITM when using it"

Cheers,

a+

Re: Bug#499774: starttls is a joke

[Reiner Steib]

[ Stripping some cc-ed lists because I only comment on the Gnus side
  of the issue.  Adding starttls.el authors. ]

On Mon, Sep 22 2008, Arnaud Ebalard wrote:
> RISKO Gergely <risko@debian.org> writes:
[...]
>> You surely knows about the gnus usage of this, since you CC'd the
>> mailing list, sorry.
>
> yes.
>
>> So my option is that a disclaimer should be placed, but SSL with
>> SSL_VERIFY_NONE is MUCH, MUCH, MUCH better than not using SSL at all.
>
> No, it is not. It is worse. It provides a feeling of security to the
> people that use it. It is like driving with deactivated airbags.
>
>> And the joke is SSL's security model - where you are considered secure
>> if you pay $500/year -, not starttls.
>
> 1) I use my own PKI for some of my services, which costs me nothing.
> 2) As a client, you do not pay for the server certificates (cf gmail)
>    and trust anchors.
> 3) It is a lame excuse.

[...]
>> I'm against the removal, since it will break imaps/pop3s connections
>> from emacs based muas (I'm at least sure in gnus, I use it hourly).
>
> Then, someone should correct the code to support passing trust anchors,
> allow passing the verify value, and document capabilities and
> limitations. 

Gnus currently uses starttls if starttls and gnutls-cli are available
for backward compatibility.  

Would it make sense to prefer gnutls-cli and warn when using starttls
(if gnutls-cli is not installed)?

,----[ starttls.el ]
| ;;; Commentary:
| 
| ;; This module defines some utility functions for STARTTLS profiles.
| 
| ;; [RFC 2595] "Using TLS with IMAP, POP3 and ACAP"
| ;;	by Chris Newman <chris.newman@innosoft.com> (1999/06)
| 
| ;; This file now contains a combination of the two previous
| ;; implementations both called "starttls.el".  The first one is Daiki
| ;; Ueno's starttls.el which uses his own "starttls" command line tool,
| ;; and the second one is Simon Josefsson's starttls.el which uses
| ;; "gnutls-cli" from GNUTLS.
| ;;
| ;; If "starttls" is available, it is prefered by the code over
| ;; "gnutls-cli", for backwards compatibility.  Use
| ;; `starttls-use-gnutls' to toggle between implementations if you have
| ;; both tools installed.  It is recommended to use GNUTLS, though, as
| ;; it performs more verification of the certificates.
`----

[...]
>> Thanks again for your contribution to Debian, if you write the
>> disclaimer in a few world that should be appended to the package
>> description in your opinion, it would be a big help.
>
> "This software does not have any authentication capabilities: it does
> not allow you to authenticate your peer, which is a basic requirement
> for TLS/SSL to be used securely. You should only use it for testing
> purposes and not relaying important information. Be aware that you are
> vulnerable to MITM when using it"

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Bug#499774: starttls is a joke

[Simon Josefsson]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> Would it make sense to prefer gnutls-cli and warn when using starttls
> (if gnutls-cli is not installed)?

Possibly, yes.

Note that emacs22 (the version in debian testing) supports both starttls
and gnutls-cli, so the comment made earlier that removing the starttls
package will break imaps/pop3s connections from emacs based muas is
false.

>> "This software does not have any authentication capabilities: it does
>> not allow you to authenticate your peer, which is a basic requirement
>> for TLS/SSL to be used securely. You should only use it for testing
>> purposes and not relaying important information. Be aware that you are
>> vulnerable to MITM when using it"

That seems correct to me.

Note that even if you use gnutls-cli, you need to configure it to use
appropriate trust anchors to get full security.  If you don't, I believe
gnutls-cli is still superior to starttls though, since gnutls-cli verify
that the server hostname match the hostname in the certificate.

/Simon

Re: Bug#499774: starttls is a joke

[Arnaud Ebalard]

Hi,

Simon Josefsson <simon@josefsson.org> writes:

> Reiner Steib <reinersteib+gmane@imap.cc> writes:
>
>> Would it make sense to prefer gnutls-cli and warn when using starttls
>> (if gnutls-cli is not installed)?
>
> Possibly, yes.

I use stunnel w/ Gnus. Some friends of mine use socat.

> Note that emacs22 (the version in debian testing) supports both starttls
> and gnutls-cli, so the comment made earlier that removing the starttls
> package will break imaps/pop3s connections from emacs based muas is
> false.

+1

>>> "This software does not have any authentication capabilities: it does
>>> not allow you to authenticate your peer, which is a basic requirement
>>> for TLS/SSL to be used securely. You should only use it for testing
>>> purposes and not relaying important information. Be aware that you are
>>> vulnerable to MITM when using it"
>
> That seems correct to me.
>
> Note that even if you use gnutls-cli, you need to configure it to use
> appropriate trust anchors to get full security.
                                   ^^^^^^^^^^^^^

I hope you mean "a working setup". If you do not provide it any (set of)
trust anchor, it should not be able to verify server's certificate and
should fail, shouldn't it?

> If you don't, I believe gnutls-cli is still superior to starttls
> though, since gnutls-cli verify that the server hostname match the
> hostname in the certificate.

IMHO, this is not superior. It is just as broken.

Cheers,

a+

Re: Bug#499774: starttls is a joke

[Uwe Brauer]

>>>>> "RISKO" == RISKO Gergely <risko@debian.org> writes:


   > I'm against the removal, since it will break imaps/pop3s connections
   > from emacs based muas (I'm at least sure in gnus, I use it hourly).
   > And I'm also against the removal, because this is a very good tool for
   > testing.

I just want to support the attitude of *not* removing this packages. For
me this is the only possibility of sending mail (using gmail smtp
server) when I am not at work. Yes it might be broken, but right now I
don't know of _any_ alternatives.

Uwe Brauer 

Bug#499774: starttls is a joke

[Riskó Gergely]

> Then, someone should correct the code to support passing trust anchors,
> allow passing the verify value, and document capabilities and
> limitations.  (*)

I certainly don't have time to do it, and since I can't agree with the
politics behind the whole SSL model, I don't think that I will have
time to implement this in the (near) future.

Someone else?

If not, then do the interested parties agree with this text to be the
warning in the package's description field?

> "This software does not have any authentication capabilities: it does
> not allow you to authenticate your peer, which is a basic requirement
> for TLS/SSL to be used securely. You should only use it for testing
> purposes and not relaying important information. Be aware that you are
> vulnerable to MITM when using it"

Security team: is this doc change enough to close the security issue,
and handle the modification requests (see (*)) as a wishlist?

Thanks for your help and your contribution,
Gergely

Re: Bug#499774: starttls is a joke

[Sebastian Krause]

Uwe Brauer <oub@mat.ucm.es> wrote:
> I just want to support the attitude of *not* removing this
> packages. For me this is the only possibility of sending mail
> (using gmail smtp server) when I am not at work. Yes it might be
> broken, but right now I don't know of _any_ alternatives.

I send my Gnus mail through smtp.gmail.com using msmtp
(http://msmtp.sourceforge.net/), it simply can't be easier. Other
alternatives like esmtp exist. I see no need for something like
starttls on my system.

Sebastian

Re: Bug#499774: starttls is a joke

[Uwe Brauer]

>>>>> "Sebastian" == Sebastian Krause <sebastian@realpath.org> writes:

   > Uwe Brauer <oub@mat.ucm.es> wrote:
   >> I just want to support the attitude of *not* removing this
   >> packages. For me this is the only possibility of sending mail
   >> (using gmail smtp server) when I am not at work. Yes it might be
   >> broken, but right now I don't know of _any_ alternatives.

   > I send my Gnus mail through smtp.gmail.com using msmtp
   > (http://msmtp.sourceforge.net/), it simply can't be easier. Other
   > alternatives like esmtp exist. I see no need for something like
   > starttls on my system.

That is very interesting I have vaguely heard about it. Could you send
me please your config?

The other thing however is jabber (for gmail chat). It seems to be that
it is using tls.

(setq jabber-connection-type (quote ssl))

I don't know any other way.

Uwe Brauer 

Re: Bug#499774: starttls is a joke

[Sebastian Krause]

Uwe Brauer <oub@mat.ucm.es> wrote:
>> I send my Gnus mail through smtp.gmail.com using msmtp
>> (http://msmtp.sourceforge.net/), it simply can't be easier. Other
>> alternatives like esmtp exist. I see no need for something like
>> starttls on my system.
>
> That is very interesting I have vaguely heard about it. Could you send
> me please your config?

# gmail
account gmail
host smtp.gmail.com
port 587
from username@gmail.com
auth plain
user username@gmail.com
password yourpass
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt

Re: Bug#499774: starttls is a joke

[Magnus Henoch]

Uwe Brauer <oub@mat.ucm.es> writes:

> The other thing however is jabber (for gmail chat). It seems to be that
> it is using tls.
>
> (setq jabber-connection-type (quote ssl))

In this configuration, it uses either openssl or gnutls-cli, and would
thus not be affected by the removal of the starttls utility.

By default jabber.el uses STARTTLS, using starttls.el.  In theory it
should work with the starttls program (see the variable
starttls-use-gnutls), but I've never tested it; I'm quite happy with
gnutls-cli.

Magnus

Re: Bug#499774: starttls is a joke

[Uwe Brauer]

>>>>> "Magnus" == Magnus Henoch <mange@freemail.hu> writes:

   > Uwe Brauer <oub@mat.ucm.es> writes:
   >> The other thing however is jabber (for gmail chat). It seems to be that
   >> it is using tls.
   >> 
   >> (setq jabber-connection-type (quote ssl))

   > In this configuration, it uses either openssl or gnutls-cli, and would
   > thus not be affected by the removal of the starttls utility.

   > By default jabber.el uses STARTTLS, using starttls.el.  In theory
   > it should work with the starttls program (see the variable
   > starttls-use-gnutls), but I've never tested it; I'm quite happy
   > with gnutls-cli.


Well I have 
,----
| `starttls-use-gnutls' is a variable declared in Lisp.
|   -- loaded from "starttls"
| 
| Value: nil
| 
| Documentation:
| *Whether to use GNUTLS instead of the `starttls' command.
`----
so I use starttls.

Re: Bug#499774: starttls is a joke

[Uwe Brauer]

>>>>> "Sebastian" == Sebastian Krause <sebastian@realpath.org> writes:

   > Uwe Brauer <oub@mat.ucm.es> wrote:
   >>> I send my Gnus mail through smtp.gmail.com using msmtp
   >>> (http://msmtp.sourceforge.net/), it simply can't be easier. Other
   >>> alternatives like esmtp exist. I see no need for something like
   >>> starttls on my system.
   >> 
   >> That is very interesting I have vaguely heard about it. Could you send
   >> me please your config?

   > # gmail
   > account gmail
   > host smtp.gmail.com
   > port 587
   > from username@gmail.com
   > auth plain
   > user username@gmail.com
   > password yourpass
   > tls on
   > tls_trust_file /etc/ssl/certs/ca-certificates.crt

Thanks but I don't understand that is wrapped by a 
(setq )

Or is this configuration written in some conf file?

Uwe 

Re: Bug#499774: starttls is a joke

[Sebastian Krause]

Uwe Brauer <oub@mat.ucm.es> wrote:
> Thanks but I don't understand that is wrapped by a 
> (setq )
>
> Or is this configuration written in some conf file?

Yes, in ~/.msmtprc. This program has nothing to do with Gnus, it is
just installed as /usr/sbin/sendmail on my system and no
configuration at all is done in Gnus.

Re: Bug#499774: starttls is a joke

[Simon Josefsson]

arno@natisbad.org (Arnaud Ebalard) writes:

>>>> "This software does not have any authentication capabilities: it does
>>>> not allow you to authenticate your peer, which is a basic requirement
>>>> for TLS/SSL to be used securely. You should only use it for testing
>>>> purposes and not relaying important information. Be aware that you are
>>>> vulnerable to MITM when using it"
>>
>> That seems correct to me.
>>
>> Note that even if you use gnutls-cli, you need to configure it to use
>> appropriate trust anchors to get full security.
>                                    ^^^^^^^^^^^^^
>
> I hope you mean "a working setup". If you do not provide it any (set of)
> trust anchor, it should not be able to verify server's certificate and
> should fail, shouldn't it?

Right, and that's what I meant with "you need to configure it to use
appropriate trust anchors".  If you do that, you should get full
security (whatever that means).

/Simon

Re: Bug#499774: starttls is a joke

[Matthias Andree]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

>> Then, someone should correct the code to support passing trust anchors,
>> allow passing the verify value, and document capabilities and
>> limitations. 
>
> Gnus currently uses starttls if starttls and gnutls-cli are available
> for backward compatibility.  
>
> Would it make sense to prefer gnutls-cli and warn when using starttls
> (if gnutls-cli is not installed)?

It would make sense to fix the tools first, and stop using them in
unsafe ways.

I recently found on Cygwin, when setting up Emacs+Gnus, that gnutls-cli
(2.4.2 IIRC) has some subtle "accept b0rked cert chain" behaviour: it
would happily accept any garbage^Wuntrusted certificate chain without
notice -- when I'm not using "--x509cafile FOO" on the command line.
This isn't documented anywhere (manual, manpage, --help), I found this
out through systematic testing.

I find this most disturbing, since if I don't provide a set of trusted
X.509 CA certs, I trust nobody (rather than everybody as gnutls-cli
does)... gnutls-cli should bail out if it has no trusted root
certificates, rather than silently trust everyone. Go figure - there's a
difference between giving "--x509cafile /dev/null" and not giving this
option at all. :-(

While I'm at it, from the end user's perspective, I find it very hard to
figure what options I need for a proper configuration that doesn't use
b0rked protocols such as SSLv2, that uses proper X.509 certificate
validation to detect MITM attacks. Few applications except Firefox 3 get
that right, and I couldn't tell one off-hand.

I think that EVERY tool that has a remotely security-related context
should default to bulletproof mode and require that the user relaxes
every test explicitly.

Yes, I need to do homework here, fetchmail doesn't get this right
either... compatibility and all that.

So I'd say make Gnus default to gnutls-cli and change the sample
configuration to include --x509cafile and add instructions to the
defcustom blah self-documentation telling the user to cat(1) his trusted
ROOT certificates (in PEM format) together to form this file.

-- 
Matthias Andree

Re: Bug#499774: starttls is a joke

[Matthias Andree]

[Stripping Debian BTS bug from Cc: list]

Simon Josefsson <simon@josefsson.org> writes:

> arno@natisbad.org (Arnaud Ebalard) writes:
>
>>>>> "This software does not have any authentication capabilities: it does
>>>>> not allow you to authenticate your peer, which is a basic requirement
>>>>> for TLS/SSL to be used securely. You should only use it for testing
>>>>> purposes and not relaying important information. Be aware that you are
>>>>> vulnerable to MITM when using it"
>>>
>>> That seems correct to me.
>>>
>>> Note that even if you use gnutls-cli, you need to configure it to use
>>> appropriate trust anchors to get full security.
>>                                    ^^^^^^^^^^^^^
>>
>> I hope you mean "a working setup". If you do not provide it any (set of)
>> trust anchor, it should not be able to verify server's certificate and
>> should fail, shouldn't it?
>
> Right, and that's what I meant with "you need to configure it to use
> appropriate trust anchors".  If you do that, you should get full
> security (whatever that means).

Please change that for gnutls-cli 2.8.0 - preferably, the tool should
get a new name then to make the change of paradigm obvious to consumers
such as Gnus.

-- 
Matthias Andree

Re: Bug#499774: starttls is a joke

[Simon Josefsson]

Matthias Andree <matthias.andree@gmx.de> writes:

> [Stripping Debian BTS bug from Cc: list]
>
> Simon Josefsson <simon@josefsson.org> writes:
>
>> arno@natisbad.org (Arnaud Ebalard) writes:
>>
>>>>>> "This software does not have any authentication capabilities: it does
>>>>>> not allow you to authenticate your peer, which is a basic requirement
>>>>>> for TLS/SSL to be used securely. You should only use it for testing
>>>>>> purposes and not relaying important information. Be aware that you are
>>>>>> vulnerable to MITM when using it"
>>>>
>>>> That seems correct to me.
>>>>
>>>> Note that even if you use gnutls-cli, you need to configure it to use
>>>> appropriate trust anchors to get full security.
>>>                                    ^^^^^^^^^^^^^
>>>
>>> I hope you mean "a working setup". If you do not provide it any (set of)
>>> trust anchor, it should not be able to verify server's certificate and
>>> should fail, shouldn't it?
>>
>> Right, and that's what I meant with "you need to configure it to use
>> appropriate trust anchors".  If you do that, you should get full
>> security (whatever that means).
>
> Please change that for gnutls-cli 2.8.0 - preferably, the tool should
> get a new name then to make the change of paradigm obvious to consumers
> such as Gnus.

You've lost me, exactly what change are you talking about?  And what is
wrong today?

/Simon

Re: Bug#499774: starttls is a joke

[Arnaud Ebalard]

Hi,

Matthias Andree <matthias.andree@gmx.de> writes:

> Reiner Steib <reinersteib+gmane@imap.cc> writes:
>
>>> Then, someone should correct the code to support passing trust anchors,
>>> allow passing the verify value, and document capabilities and
>>> limitations. 
>>
>> Gnus currently uses starttls if starttls and gnutls-cli are available
>> for backward compatibility.  
>>
>> Would it make sense to prefer gnutls-cli and warn when using starttls
>> (if gnutls-cli is not installed)?
>
> It would make sense to fix the tools first, and stop using them in
> unsafe ways.
>
> I recently found on Cygwin, when setting up Emacs+Gnus, that gnutls-cli
> (2.4.2 IIRC) has some subtle "accept b0rked cert chain" behaviour: it
> would happily accept any garbage^Wuntrusted certificate chain without
> notice -- when I'm not using "--x509cafile FOO" on the command line.
> This isn't documented anywhere (manual, manpage, --help), I found this
> out through systematic testing.
>
> I find this most disturbing, since if I don't provide a set of trusted
> X.509 CA certs, I trust nobody (rather than everybody as gnutls-cli
> does)... gnutls-cli should bail out if it has no trusted root
> certificates, rather than silently trust everyone. Go figure - there's a
> difference between giving "--x509cafile /dev/null" and not giving this
> option at all. :-(

Maybe I missed the point in Simon's response below because if you are
correct (I just don't have gnutls-cli on my laptop to test) that
deserves a bug report (and a clarification from Simon): 

http://article.gmane.org/gmane.linux.debian.devel.bugs.general/493201

> While I'm at it, from the end user's perspective, I find it very hard to
> figure what options I need for a proper configuration that doesn't use
> b0rked protocols such as SSLv2, that uses proper X.509 certificate
> validation to detect MITM attacks. Few applications except Firefox 3 get
> that right, and I couldn't tell one off-hand.
>
> I think that EVERY tool that has a remotely security-related context
> should default to bulletproof mode and require that the user relaxes
> every test explicitly.
>
> Yes, I need to do homework here, fetchmail doesn't get this right
> either... compatibility and all that.
>
> So I'd say make Gnus default to gnutls-cli and change the sample
> configuration to include --x509cafile and add instructions to the
> defcustom blah self-documentation telling the user to cat(1) his trusted
> ROOT certificates (in PEM format) together to form this file.

+1 (a big one).

Cheers,

a+

Re: Bug#499774: starttls is a joke

[Matthias Andree]

Simon Josefsson schrieb:
> Matthias Andree <matthias.andree@gmx.de> writes:
> 
>> [Stripping Debian BTS bug from Cc: list]
>>
>> Simon Josefsson <simon@josefsson.org> writes:
>>
>>> arno@natisbad.org (Arnaud Ebalard) writes:
>>>
>>>>>>> "This software does not have any authentication capabilities: it does
>>>>>>> not allow you to authenticate your peer, which is a basic requirement
>>>>>>> for TLS/SSL to be used securely. You should only use it for testing
>>>>>>> purposes and not relaying important information. Be aware that you are
>>>>>>> vulnerable to MITM when using it"
>>>>> That seems correct to me.
>>>>>
>>>>> Note that even if you use gnutls-cli, you need to configure it to use
>>>>> appropriate trust anchors to get full security.
>>>>                                    ^^^^^^^^^^^^^
>>>>
>>>> I hope you mean "a working setup". If you do not provide it any (set of)
>>>> trust anchor, it should not be able to verify server's certificate and
>>>> should fail, shouldn't it?
>>> Right, and that's what I meant with "you need to configure it to use
>>> appropriate trust anchors".  If you do that, you should get full
>>> security (whatever that means).
>> Please change that for gnutls-cli 2.8.0 - preferably, the tool should
>> get a new name then to make the change of paradigm obvious to consumers
>> such as Gnus.
> 
> You've lost me, exactly what change are you talking about?  And what is
> wrong today?
> 
> /Simon

Sorry for not wording carefully enough.

Two issues:
1. gnutls-cli
2. gnus's use of starttls, gnutls-cli, and thereabouts.


1. GNUTLS-CLI
-------------
Problem: gnutls-cli will happily establish a connection without any "trust
anchors", even though it knows the connection is untrusted.
This behaviour is NOT clearly documented. See below (Goals).

Example: (below, I masked hostname and IP, and I numbered lines, but the
rest is verbatim from a connection to a production machine somewhere in
Germany.) This is Cygwin BTW. Comments below the transcript.

     1  $ gnutls-cli -v
     2  gnutls-cli (GnuTLS) 2.4.1
     3  $ gnutls-cli -p 993 host.example.org
     4  Resolving 'host.example.org'...
     5  Connecting to '10.9.8.7:993'...
     6  - Certificate type: X.509
     7   - Got a certificate list of 4 certificates.
        [certificate info snipped]
     8  - Peer's certificate issuer is unknown
     9  - Peer's certificate is NOT trusted
    10  - Version: TLS1.0
    11  - Key Exchange: RSA
    12  - Cipher: AES-128-CBC
    13  - MAC: SHA1
    14  - Compression: NULL
    15  - Handshake was completed

    16  - Simple Client Mode:

    17  * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID AUTH=GSSAPI AUTH=LOGIN
AUTH=PLAIN SASL-IR] host.example.org Cyrus IMAP4 v2.3.11-Debian-2.3.11-3
server ready

Comments:
- the command line (l. 3) does not define trust anchors.
  Particularly, there is no "--x509cafile /path/to/file.pem" option.
- gnutls-cli v2.4.1 figures that it doesn't trust the issuer, ll. 8 & 9.
- at that point in time, gnutls-cli should drop the connection. Instead, it
continues.

Desired behaviour/Goals:
- gnutls-cli should drop the connect somewhen between lines 9 and 16, and
should NOT enter forwarding/simple client state.
- if clients want unsafe behaviour, they should be made to specify that in
some way, and the program defaults should be "safest possible" mode
- it may make sense that gnutls-cli doesn't even try to connect/handshake
if it has
  * neither "trust anchors" such as the --x509cafile
  * nor some --unsafely-skip-cert-validation command line option.
- man page, help output and manual should be consistent, example (2.4.1
manpage of gnutls-cli):

       --x509cafile FILE
              Certificate file to use.

       --x509certfile FILE
              X.509 Certificate file to use.

       --x509fmtder
              Use DER format for certificates

       --x509keyfile FILE
              X.509 key file to use.

This is pure crap^W^Wutterly unintelligible. What's the difference between
--x509cafile and --x509certfile? It should read something like
"--x509cafile: file that lists all Certification Authority (CA)
certificates that gnutls-cli is allowed to trust. If this option is
omitted, gnutls-cli will accept unsafe connections and trust any CA
certificate. For secure operation, be sure to specify this option."

If the observed behaviour is deliberate, there should be notes in the man
page, in the --help output, in the manual, just about everywhere that
clearly states two things:
1. not specifying --x509cafile disables certificate verification and allows
undetected man-in-the-middle attacks - see above
2. for safe operation, you must specify --x509cafile foo, which see. (and
possibly other options)

Further consideration:
- if the defaults are changed to "safe" mode, it may be sensible to rename
the tool to gnutls-safe-client or something better.


2. GNUS
-------

I suggest that the example configuration uses trust anchors in gnutls-cli
along with step-by-step how-to instructions so that end users easily see
what needs to be done to use gnutls-cli in a secure way - because
gnutls-cli defaults to unsafe operation, at least 2.2.2 and 2.4.1 did, and
starttls apparently is the acronym for Standard Tool Aiming aT Totally
Lying about Security (in that it creates a false sense of "security").

-- 
Matthias Andree

Re: Bug#499774: starttls is a joke

[Arnaud Ebalard]

Hi,

Matthias Andree <matthias.andree@gmx.de> writes:

> Comments:
> - the command line (l. 3) does not define trust anchors.
>   Particularly, there is no "--x509cafile /path/to/file.pem" option.
> - gnutls-cli v2.4.1 figures that it doesn't trust the issuer, ll. 8 & 9.
> - at that point in time, gnutls-cli should drop the connection. Instead, it
> continues.
>
> Desired behaviour/Goals:
> - gnutls-cli should drop the connect somewhen between lines 9 and 16, and
> should NOT enter forwarding/simple client state.
> - if clients want unsafe behaviour, they should be made to specify that in
> some way, and the program defaults should be "safest possible" mode
> - it may make sense that gnutls-cli doesn't even try to connect/handshake
> if it has
>   * neither "trust anchors" such as the --x509cafile
>   * nor some --unsafely-skip-cert-validation command line option.
> - man page, help output and manual should be consistent, example (2.4.1
> manpage of gnutls-cli):
>
>        --x509cafile FILE
>               Certificate file to use.
>
>        --x509certfile FILE
>               X.509 Certificate file to use.
>
>        --x509fmtder
>               Use DER format for certificates
>
>        --x509keyfile FILE
>               X.509 key file to use.
>
> This is pure crap^W^Wutterly unintelligible. What's the difference between
> --x509cafile and --x509certfile? It should read something like
> "--x509cafile: file that lists all Certification Authority (CA)
> certificates that gnutls-cli is allowed to trust. If this option is
> omitted, gnutls-cli will accept unsafe connections and trust any CA
> certificate. For secure operation, be sure to specify this option."

It would be better to have it fail when someone does not provide a
set of trust anchors. Then adding something --verify-peer (is there
something like that already?) with a default to "yes" that can be set to
"no" or something else when someone _*explicitly*_ asks for an insecure
behavior. I know for sure that GnuTLS internally support such a knob.

> Further consideration:
> - if the defaults are changed to "safe" mode, it may be sensible to rename
> the tool to gnutls-safe-client or something better.

Worst case scenario would that things would be safer.

Cheers,

a+