Re: Bug#499774: starttls is a joke

[Matthias Andree <matthias.andree@gmx.de>]

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