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: perdition-us...@vergenet.net
 
 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
Description: Digital signature

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

[Daniel Kahn Gillmor]

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:
87zjpfwqft@alice.fifthhorseman.net

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

Nov  7 21:57:50 che postfix/smtp[32630]: 7E90AF984: 
to=perdition-us...@vergenet.net, 
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


pgpMRqlycgWOX.pgp
Description: PGP signature

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:
 87zjpfwqft@alice.fifthhorseman.net
 
 The handoff to the vergenet MX looked like this from my side:
 
 Nov  7 21:57:50 che postfix/smtp[32630]: 7E90AF984: 
 to=perdition-us...@vergenet.net, 
 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 debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Daniel Kahn Gillmor]

Perdition, the IMAP and POP proxy server, fails to apply the
administrator's specified ciphersuite preferences when making outbound
connections to IMAP and POP servers using STARTTLS.  For these outbound
connections, it applies the administrator's listening ciphersuite
preferences, which in many cases may be significantly weaker.

This was first noted publicly on the debian BTS:

  http://bugs.debian.org/729028

All versions of perdition up to 2.0 appear to be affected, and the fix
is a one-line patch.

This is not a critical vulnerability (it can be mitigated, for example,
by enforcing a strict minimalist ciphersuite on the backend server), but
in the absence of any such mitigation, it may cause the connections
between the proxy server and the backend server to negotiate a weaker
ciphersuite than the administrator's stated intent.

Could a CVE be issued for this issue?

Thanks,

--dkg



signature.asc
Description: OpenPGP digital signature

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

[Daniel Kahn Gillmor]

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: perdition-us...@vergenet.net

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


pgp3dQwsU640e.pgp
Description: PGP signature