* Bug#499774: starttls is a joke @ 2008-09-22 8:52 Arnaud Ebalard 2008-09-22 9:13 ` RISKO Gergely 0 siblings, 1 reply; 23+ messages in thread From: Arnaud Ebalard @ 2008-09-22 8:52 UTC (permalink / raw) To: submit; +Cc: security, ding, emacs-mime-en 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?). ^ permalink raw reply [flat|nested] 23+ messages in thread
* Bug#499774: starttls is a joke 2008-09-22 8:52 Bug#499774: starttls is a joke Arnaud Ebalard @ 2008-09-22 9:13 ` RISKO Gergely 2008-09-22 9:49 ` Arnaud Ebalard ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: RISKO Gergely @ 2008-09-22 9:13 UTC (permalink / raw) To: Arnaud Ebalard; +Cc: 499774, submit, security, ding, emacs-mime-en 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?). ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug#499774: starttls is a joke 2008-09-22 9:13 ` RISKO Gergely @ 2008-09-22 9:49 ` Arnaud Ebalard 2008-09-22 10:43 ` Arnaud Ebalard 2008-09-23 14:43 ` Uwe Brauer 2 siblings, 0 replies; 23+ messages in thread From: Arnaud Ebalard @ 2008-09-22 9:49 UTC (permalink / raw) To: ding 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+ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Bug#499774: starttls is a joke 2008-09-22 9:13 ` RISKO Gergely 2008-09-22 9:49 ` Arnaud Ebalard @ 2008-09-22 10:43 ` Arnaud Ebalard 2008-09-22 16:15 ` Reiner Steib 2008-09-23 17:18 ` Riskó Gergely 2008-09-23 14:43 ` Uwe Brauer 2 siblings, 2 replies; 23+ messages in thread From: Arnaud Ebalard @ 2008-09-22 10:43 UTC (permalink / raw) To: RISKO Gergely; +Cc: 499774, submit, security, ding, emacs-mime-en 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+ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug#499774: starttls is a joke 2008-09-22 10:43 ` Arnaud Ebalard @ 2008-09-22 16:15 ` Reiner Steib 2008-09-22 16:38 ` Simon Josefsson 2008-10-07 20:41 ` Matthias Andree 2008-09-23 17:18 ` Riskó Gergely 1 sibling, 2 replies; 23+ messages in thread From: Reiner Steib @ 2008-09-22 16:15 UTC (permalink / raw) To: Arnaud Ebalard, Daiki Ueno, Simon Josefsson; +Cc: 499774, RISKO Gergely, ding [ 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/ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Bug#499774: starttls is a joke 2008-09-22 16:15 ` Reiner Steib @ 2008-09-22 16:38 ` Simon Josefsson 2008-09-22 17:48 ` Arnaud Ebalard 2008-10-07 20:41 ` Matthias Andree 1 sibling, 1 reply; 23+ messages in thread From: Simon Josefsson @ 2008-09-22 16:38 UTC (permalink / raw) To: Arnaud Ebalard; +Cc: Daiki Ueno, 499774, RISKO Gergely, ding 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug#499774: starttls is a joke 2008-09-22 16:38 ` Simon Josefsson @ 2008-09-22 17:48 ` Arnaud Ebalard 2008-10-02 10:04 ` Simon Josefsson 0 siblings, 1 reply; 23+ messages in thread From: Arnaud Ebalard @ 2008-09-22 17:48 UTC (permalink / raw) To: Simon Josefsson; +Cc: Daiki Ueno, 499774, RISKO Gergely, ding 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+ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug#499774: starttls is a joke 2008-09-22 17:48 ` Arnaud Ebalard @ 2008-10-02 10:04 ` Simon Josefsson 2008-10-07 20:43 ` Matthias Andree 0 siblings, 1 reply; 23+ messages in thread From: Simon Josefsson @ 2008-10-02 10:04 UTC (permalink / raw) To: Arnaud Ebalard; +Cc: Daiki Ueno, 499774, RISKO Gergely, ding 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug#499774: starttls is a joke 2008-10-02 10:04 ` Simon Josefsson @ 2008-10-07 20:43 ` Matthias Andree 2008-10-07 22:41 ` Simon Josefsson 0 siblings, 1 reply; 23+ messages in thread From: Matthias Andree @ 2008-10-07 20:43 UTC (permalink / raw) To: simon; +Cc: Daiki Ueno, RISKO Gergely, ding [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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug#499774: starttls is a joke 2008-10-07 20:43 ` Matthias Andree @ 2008-10-07 22:41 ` Simon Josefsson 2008-10-08 10:45 ` Matthias Andree 0 siblings, 1 reply; 23+ messages in thread From: Simon Josefsson @ 2008-10-07 22:41 UTC (permalink / raw) To: Matthias Andree; +Cc: Daiki Ueno, RISKO Gergely, ding 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug#499774: starttls is a joke 2008-10-07 22:41 ` Simon Josefsson @ 2008-10-08 10:45 ` Matthias Andree 2008-10-08 11:55 ` Arnaud Ebalard 0 siblings, 1 reply; 23+ messages in thread From: Matthias Andree @ 2008-10-08 10:45 UTC (permalink / raw) To: Simon Josefsson; +Cc: Daiki Ueno, RISKO Gergely, ding, Arnaud Ebalard 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug#499774: starttls is a joke 2008-10-08 10:45 ` Matthias Andree @ 2008-10-08 11:55 ` Arnaud Ebalard 0 siblings, 0 replies; 23+ messages in thread From: Arnaud Ebalard @ 2008-10-08 11:55 UTC (permalink / raw) To: Matthias Andree; +Cc: Simon Josefsson, Daiki Ueno, RISKO Gergely, ding 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+ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug#499774: starttls is a joke 2008-09-22 16:15 ` Reiner Steib 2008-09-22 16:38 ` Simon Josefsson @ 2008-10-07 20:41 ` Matthias Andree 2008-10-08 5:54 ` Arnaud Ebalard 1 sibling, 1 reply; 23+ messages in thread From: Matthias Andree @ 2008-10-07 20:41 UTC (permalink / raw) To: Arnaud Ebalard; +Cc: Daiki Ueno, Simon Josefsson, 499774, RISKO Gergely, ding 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug#499774: starttls is a joke 2008-10-07 20:41 ` Matthias Andree @ 2008-10-08 5:54 ` Arnaud Ebalard 0 siblings, 0 replies; 23+ messages in thread From: Arnaud Ebalard @ 2008-10-08 5:54 UTC (permalink / raw) To: Matthias Andree; +Cc: Daiki Ueno, Simon Josefsson, 499774, RISKO Gergely, ding 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+ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Bug#499774: starttls is a joke 2008-09-22 10:43 ` Arnaud Ebalard 2008-09-22 16:15 ` Reiner Steib @ 2008-09-23 17:18 ` Riskó Gergely 1 sibling, 0 replies; 23+ messages in thread From: Riskó Gergely @ 2008-09-23 17:18 UTC (permalink / raw) To: Arnaud Ebalard; +Cc: 499774, security, ding, emacs-mime-en > 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug#499774: starttls is a joke 2008-09-22 9:13 ` RISKO Gergely 2008-09-22 9:49 ` Arnaud Ebalard 2008-09-22 10:43 ` Arnaud Ebalard @ 2008-09-23 14:43 ` Uwe Brauer 2008-09-24 3:39 ` Sebastian Krause 2 siblings, 1 reply; 23+ messages in thread From: Uwe Brauer @ 2008-09-23 14:43 UTC (permalink / raw) To: ding >>>>> "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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug#499774: starttls is a joke 2008-09-23 14:43 ` Uwe Brauer @ 2008-09-24 3:39 ` Sebastian Krause 2008-09-26 13:19 ` Uwe Brauer 0 siblings, 1 reply; 23+ messages in thread From: Sebastian Krause @ 2008-09-24 3:39 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug#499774: starttls is a joke 2008-09-24 3:39 ` Sebastian Krause @ 2008-09-26 13:19 ` Uwe Brauer 2008-09-26 13:25 ` Sebastian Krause 2008-09-26 15:09 ` Magnus Henoch 0 siblings, 2 replies; 23+ messages in thread From: Uwe Brauer @ 2008-09-26 13:19 UTC (permalink / raw) To: ding >>>>> "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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug#499774: starttls is a joke 2008-09-26 13:19 ` Uwe Brauer @ 2008-09-26 13:25 ` Sebastian Krause 2008-09-26 21:16 ` Uwe Brauer 2008-09-26 15:09 ` Magnus Henoch 1 sibling, 1 reply; 23+ messages in thread From: Sebastian Krause @ 2008-09-26 13:25 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug#499774: starttls is a joke 2008-09-26 13:25 ` Sebastian Krause @ 2008-09-26 21:16 ` Uwe Brauer 2008-09-26 23:27 ` Sebastian Krause 0 siblings, 1 reply; 23+ messages in thread From: Uwe Brauer @ 2008-09-26 21:16 UTC (permalink / raw) To: ding >>>>> "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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug#499774: starttls is a joke 2008-09-26 21:16 ` Uwe Brauer @ 2008-09-26 23:27 ` Sebastian Krause 0 siblings, 0 replies; 23+ messages in thread From: Sebastian Krause @ 2008-09-26 23:27 UTC (permalink / raw) To: ding 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug#499774: starttls is a joke 2008-09-26 13:19 ` Uwe Brauer 2008-09-26 13:25 ` Sebastian Krause @ 2008-09-26 15:09 ` Magnus Henoch 2008-09-26 21:14 ` Uwe Brauer 1 sibling, 1 reply; 23+ messages in thread From: Magnus Henoch @ 2008-09-26 15:09 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bug#499774: starttls is a joke 2008-09-26 15:09 ` Magnus Henoch @ 2008-09-26 21:14 ` Uwe Brauer 0 siblings, 0 replies; 23+ messages in thread From: Uwe Brauer @ 2008-09-26 21:14 UTC (permalink / raw) To: ding >>>>> "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. ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2008-10-08 11:55 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-09-22 8:52 Bug#499774: starttls is a joke Arnaud Ebalard 2008-09-22 9:13 ` RISKO Gergely 2008-09-22 9:49 ` Arnaud Ebalard 2008-09-22 10:43 ` Arnaud Ebalard 2008-09-22 16:15 ` Reiner Steib 2008-09-22 16:38 ` Simon Josefsson 2008-09-22 17:48 ` Arnaud Ebalard 2008-10-02 10:04 ` Simon Josefsson 2008-10-07 20:43 ` Matthias Andree 2008-10-07 22:41 ` Simon Josefsson 2008-10-08 10:45 ` Matthias Andree 2008-10-08 11:55 ` Arnaud Ebalard 2008-10-07 20:41 ` Matthias Andree 2008-10-08 5:54 ` Arnaud Ebalard 2008-09-23 17:18 ` Riskó Gergely 2008-09-23 14:43 ` Uwe Brauer 2008-09-24 3:39 ` Sebastian Krause 2008-09-26 13:19 ` Uwe Brauer 2008-09-26 13:25 ` Sebastian Krause 2008-09-26 21:16 ` Uwe Brauer 2008-09-26 23:27 ` Sebastian Krause 2008-09-26 15:09 ` Magnus Henoch 2008-09-26 21:14 ` Uwe Brauer
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).