Bug#729028: perdition: ssl_outgoing_ciphers not applied to STARTTLS connections

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#729028: perdition: ssl_outgoing_ciphers not applied to STARTTLS connections

Daniel Kahn Gillmor-3
Package: perdition
Version: 1.19~rc4-2
Control: found -1 1.19~rc5-1
Control: found -1 2.0-1
Tags: patch security upstream
Forwarded: [hidden email]

Perdition(8) says:

        --ssl_outgoing_ciphers STRING:

              Cipher list when making outgoing SSL or TLS connections as
              per ciphers(1). If empty ("") then openssl's default will
              be used.  (default "")

However, this is only the case for outgoing connections that do not use
STARTTLS (the perdition terminology is confusing here, since what it
calls "TLS" actually means "start as cleartext, negotiate to encrypted
via STARTTLS" and what it calls "SSL" actually means "start SSL or TLS
session, run service inside that").

Here's the fix:

diff -r 046a7b19cd5b perdition/perdition.c
--- a/perdition/perdition.c Thu Nov 07 21:23:31 2013 -0500
+++ b/perdition/perdition.c Thu Nov 07 21:49:39 2013 -0500
@@ -985,7 +985,7 @@
     else if((opt.ssl_mode & SSL_MODE_TLS_OUTGOING) &&
           (status & PROTOCOL_S_STARTTLS)) {
       server_io=perdition_ssl_client_connection(server_io, opt.ssl_ca_file,
-      opt.ssl_ca_path, opt.ssl_listen_ciphers, servername);
+      opt.ssl_ca_path, opt.ssl_outgoing_ciphers, servername);
       if(!server_io) {
         VANESSA_LOGGER_DEBUG("perdition_ssl_connection outgoing");
         VANESSA_LOGGER_ERR("Fatal error establishing SSL connection");


This is a security concern because it means that perdition is not
obeying the specifications of the administrator, and may accept weaker
ciphersuites than instructed on its backhaul connections.

Consider the case where an administrator wants to offer relatively
promiscuous IMAP connections to their end users -- if the user's MUA
only has some weak cipher suite or cleartext IMAP, we want to accept the
weak ciphersuite as better than nothing.  However, the admin's backend
IMAP servers are all under her control, and she knows that they are
capable of stronger ciphersuites.  in this case, ssl_listen_ciphers will
allow weak ciphers, and ssl_outgoing_ciphers will be strict and require
high security, to at least protect the link between perdition and the
backend IMAP server.

However, if this outgoing connection happens to use IMAP+STARTTLS
instead of IMAPS, the bug described here will offer weak ciphersuites to
the backend IMAP server.

All versions of perdition in debian currently have this flaw.  I've
reported it to the upstream mailing list, but for whatever reason the
message hasn't cleared that mailing list yet.

Regards,

         --dkg

attachment0 (983 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#729028: perdition: ssl_outgoing_ciphers not applied to STARTTLS connections

Simon Horman
On Thu, Nov 07, 2013 at 11:31:16PM -0500, Daniel Kahn Gillmor wrote:

> Package: perdition
> Version: 1.19~rc4-2
> Control: found -1 1.19~rc5-1
> Control: found -1 2.0-1
> Tags: patch security upstream
> Forwarded: [hidden email]
>
> Perdition(8) says:
>
>         --ssl_outgoing_ciphers STRING:
>
>               Cipher list when making outgoing SSL or TLS connections as
>               per ciphers(1). If empty ("") then openssl's default will
>               be used.  (default "")
>
> However, this is only the case for outgoing connections that do not use
> STARTTLS (the perdition terminology is confusing here, since what it
> calls "TLS" actually means "start as cleartext, negotiate to encrypted
> via STARTTLS" and what it calls "SSL" actually means "start SSL or TLS
> session, run service inside that").
>
> Here's the fix:
>
> diff -r 046a7b19cd5b perdition/perdition.c
> --- a/perdition/perdition.c Thu Nov 07 21:23:31 2013 -0500
> +++ b/perdition/perdition.c Thu Nov 07 21:49:39 2013 -0500
> @@ -985,7 +985,7 @@
>      else if((opt.ssl_mode & SSL_MODE_TLS_OUTGOING) &&
>            (status & PROTOCOL_S_STARTTLS)) {
>        server_io=perdition_ssl_client_connection(server_io, opt.ssl_ca_file,
> -      opt.ssl_ca_path, opt.ssl_listen_ciphers, servername);
> +      opt.ssl_ca_path, opt.ssl_outgoing_ciphers, servername);
>        if(!server_io) {
>          VANESSA_LOGGER_DEBUG("perdition_ssl_connection outgoing");
>          VANESSA_LOGGER_ERR("Fatal error establishing SSL connection");
>
>
> This is a security concern because it means that perdition is not
> obeying the specifications of the administrator, and may accept weaker
> ciphersuites than instructed on its backhaul connections.
>
> Consider the case where an administrator wants to offer relatively
> promiscuous IMAP connections to their end users -- if the user's MUA
> only has some weak cipher suite or cleartext IMAP, we want to accept the
> weak ciphersuite as better than nothing.  However, the admin's backend
> IMAP servers are all under her control, and she knows that they are
> capable of stronger ciphersuites.  in this case, ssl_listen_ciphers will
> allow weak ciphers, and ssl_outgoing_ciphers will be strict and require
> high security, to at least protect the link between perdition and the
> backend IMAP server.
>
> However, if this outgoing connection happens to use IMAP+STARTTLS
> instead of IMAPS, the bug described here will offer weak ciphersuites to
> the backend IMAP server.
>
> All versions of perdition in debian currently have this flaw.  I've
> reported it to the upstream mailing list, but for whatever reason the
> message hasn't cleared that mailing list yet.

Hi Daniel,

thanks for bringing this to my attention and sorry
for not noticing the mailing list post: I'm not suer what happened there.

I think that the best thing to do is both:
* Update the Debian packages with this fix and;
* Release a fresh upstream version of perdition with this fix.


signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#729028: perdition: ssl_outgoing_ciphers not applied to STARTTLS connections

Daniel Kahn Gillmor-3
Hi Simon--

Re: http://bugs.debian.org/729028:

On Tue 2013-11-12 23:04:07 -0500, Simon Horman wrote:
> Thanks for bringing this to my attention and sorry
> for not noticing the mailing list post: I'm not suer what happened there.

dunno if you care to investigate the mailing list situation further.  if
you do, the post to the mailing list was Message-ID:
<[hidden email]>

The handoff to the vergenet MX looked like this from my side:

Nov  7 21:57:50 che postfix/smtp[32630]: 7E90AF984: to=<[hidden email]>, relay=mail.au.vergenet.net[202.4.237.240]:25, delay=5.2, delays=0.55/0.01/3.6/1, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as B4DE9266CEF)

The message doesn't seem to have made it through to the pipermail
archives, which see no messages for November 2013 at all:

 http://lists.vergenet.net/pipermail/perdition-users/

> I think that the best thing to do is both:
> * Update the Debian packages with this fix and;
> * Release a fresh upstream version of perdition with this fix.

This sounds like a reasonable approach to me.  I'm cc'ing the security
team so that they're aware of the problem and the potential security-fix
upload(s).  Would you like me to request a CVE for tracking this issue,
or do you intend to request one yourself?

Regards,

        --dkg

PS While i've got your ear, can i get you to look at and reply to my
earlier post to perdition-users about DHE?

  http://lists.vergenet.net/pipermail/perdition-users/2013-October/002669.html

attachment0 (983 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#729028: perdition: ssl_outgoing_ciphers not applied to STARTTLS connections

Simon Horman
On Tue, Nov 12, 2013 at 11:59:15PM -0500, Daniel Kahn Gillmor wrote:

> Hi Simon--
>
> Re: http://bugs.debian.org/729028:
>
> On Tue 2013-11-12 23:04:07 -0500, Simon Horman wrote:
> > Thanks for bringing this to my attention and sorry
> > for not noticing the mailing list post: I'm not suer what happened there.
>
> dunno if you care to investigate the mailing list situation further.  if
> you do, the post to the mailing list was Message-ID:
> <[hidden email]>
>
> The handoff to the vergenet MX looked like this from my side:
>
> Nov  7 21:57:50 che postfix/smtp[32630]: 7E90AF984: to=<[hidden email]>, relay=mail.au.vergenet.net[202.4.237.240]:25, delay=5.2, delays=0.55/0.01/3.6/1, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as B4DE9266CEF)
>
> The message doesn't seem to have made it through to the pipermail
> archives, which see no messages for November 2013 at all:
>
>  http://lists.vergenet.net/pipermail/perdition-users/
>
> > I think that the best thing to do is both:
> > * Update the Debian packages with this fix and;
> > * Release a fresh upstream version of perdition with this fix.
>
> This sounds like a reasonable approach to me.  I'm cc'ing the security
> team so that they're aware of the problem and the potential security-fix
> upload(s).  Would you like me to request a CVE for tracking this issue,
> or do you intend to request one yourself?

If you could request one that would be great.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]