Juju still vulnerable to CVE-2013-2566, CVE-2015-2808

[Cheryl Jennings]

Originally reported by Bryan Quigley via github: https://github.com/juju/juju/issues/5167 (removed there, tracking here)

Trusty uses go <1.5. Can we fix Poodle/RC4 issues on trusty as well?

Specifically ports 38017 and 37017 are vulnerable to both attack vectors. You can test with
https://testssl.sh/ script like "./testssl.sh localhost:37017"

Key outputs:
SSLv3 offered (NOT ok)
Secure Client-Initiated Renegotiation VULNERABLE (NOT ok), DoS threat
POODLE, SSL (CVE-2014-3566) VULNERABLE (NOT ok), uses SSLv3+CBC (check TLS_FALLBACK_SCSV mitigation below)
RC4 (CVE-2013-2566, CVE-2015-2808) VULNERABLE (NOT ok): RC4-SHA RC4-MD5

I was incorrect. RC4 issue does still affect Xenial, but SSLv3 is fixed there.

[Cheryl Jennings (cherylj)]

We have just switched to using go 1.6 everywhere, so the next 1.25 release will be built entirely with 1.6. 2.0-beta4 was released with all tools built with go 1.6.

From the issue reported in GH, it sounds like the only outstanding issue we'll have is the RC4 CVEs listed.

Adding security folks for guidance.

[Nate Finch (natefinch)]

The long and the short of it is - we should make sure we don't use the RC4 ciphersuite when making tls clients and servers. crypto/tls has a Config struct that is used to create clients and servers, and has a Ciphersuites field that defaults to effectively "use whatever". We should be populating that field with crypto/tls's list of ciphersuites (sans RC4 versions).

[Haw Loeung (hloeung)]

First reported in LP:1536269

[Haw Loeung (hloeung)]

Any chance we could also get a fix targeted to the 1.25 series as well?

Thanks.

[Nate Finch (natefinch)]

Yeah, we can do the same thing for 1.25, it's not a huge change.

[Bryan Quigley (bryanquigley)]

SSLv3 is fixed in Juju 1.25.6, but RC4 is not. Any chance we can get RC4 disabled too?

[Bryan Quigley (bryanquigley)]

Actually it appears I'm wrong both issues are still present in 1.25.6. Can this be reopened?

[Nate Finch (natefinch)]

Working on the backport to 1.25 right now

[Nate Finch (natefinch)]

PR for 1.25 here: https://github.com/juju/juju/pull/6030

[Curtis Hovey (sinzui)]

This issue is fix committed in 1.25, thus preventing tcl 1.1 and 1.0 clients from working with juju. As trusty's python does not support tsl 1.2+, All trusty-python based clients are broken. Juju 1.25.76 is not compatible with trusty-quickstart. Backporting 1.25.7 to trusty means we either accept that juju-quickstart is broken, or someone divises a cleave way for ssl 1.2 though python in trusty.

[Bryan Quigley (bryanquigley)]

I'm going to do some testing later today/tomorrow, but that would also mean juju-deployer would be broken ~ which is critical for how we do some deployments.

Python in trusty can definitely act as a server for TLS1.2 (juju-gui does it). Will investigate further.

@sinzui are you doing straight from code or via some testing PPA somewhere?

[Bryan Quigley (bryanquigley)]

My testing appears to confirm that juju-deployer is broken by this which I don't think we can do.

I also couldn't confirm the fix with the command ./testssl.sh localhost:37017 - but juju-deployer broke with a ssl error. Should I be looking somewhere else, or is there some sort of problem doing this from localhost?

Because I can't test with testssl.sh I'm not sure how easy this would to workaround as I'm not 100% sure what it's actually offering TLS wise.

Fixes for python in trusty are being tracked:
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1348955
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1443704

[Bryan Quigley (bryanquigley)]

I'm qualifying with customer if upgrading just the bootstrap node to Xenial can be considered a workaround for them.

If we can't re-enable TLS1.0 (FWIU), I'm guessing this will have to be reverted in any case.

[Bryan Quigley (bryanquigley)]

Customer is OK with upgrading to Xenial as a workaround (and staying w/ 1.25) - as long as none of the rest of the environment needs to be upgraded to remove SSLv3. That appears to be correct, from my understanding.

[Bryan Quigley (bryanquigley)]

I've confirmed with Juju 1.25.7 in proposed that:
 * this breaks juju-deployer (python)
 * doesn't fully disable SSLv3

I think we need to revert.

[Nicholas Skaggs (nskaggs)]

Bryan, thanks for trying out 1.25.7. Can you paste a log of what you did to test this, and why you assert this fix doesn't disable sslv3? Want to make sure we understand and see why it fails for you.

[Bryan Quigley (bryanquigley)]

Sure, where it SSLv3 seems still be enabled
1. set agent-stream: proposed
2. Bootstrap
3. Juju ssh 0
4. wget https://raw.githubusercontent.com/drwetter/testssl.sh/master/testssl.sh
5. chmod u+x
6. ./testssl.sh localhost:37017

Note, how it says SSLv3 is enabled.

Where it breaks juju-deployer (but afaict this must indicate it disabled SSLv3):
1. apt-get install juju-deployer
2. Find something to deploy, say bzr checkout http://bazaar.launchpad.net/~ost-maintainers/openstack-charm-testing/trunk/
3. cd trunk
4. juju-deployer -c default.yaml -d trusty-icehouse
Err:
2016-11-04 18:02:05 [DEBUG] deployer.cli: Using runtime GoEnvironment on bq01
2016-11-04 18:02:05 [INFO] deployer.cli: Starting deployment of trusty-icehouse
2016-11-04 18:02:05 [DEBUG] deployer.import: Getting charms...
2016-11-04 18:02:06 [DEBUG] deployer.deploy: Resolving configuration
2016-11-04 18:02:06 [DEBUG] deployer.env: Connecting to environment...
Traceback (most recent call last):
  File "/usr/bin/juju-deployer", line 9, in <module>
    load_entry_point('juju-deployer==0.6.4', 'console_scripts', 'juju-deployer')()
  File "/usr/lib/python2.7/dist-packages/deployer/cli.py", line 135, in main
    run()
  File "/usr/lib/python2.7/dist-packages/deployer/cli.py", line 234, in run
    importer.Importer(env, deployment, options).run()
  File "/usr/lib/python2.7/dist-packages/deployer/action/importer.py", line 298, in run
    self.env.connect()
  File "/usr/lib/python2.7/dist-packages/deployer/env/go.py", line 65, in connect
    self.client = EnvironmentClient.connect(self.name)
  File "/usr/lib/python2.7/dist-packages/jujuclient.py", line 534, in connect
    return Connector().run(cls, env_name)
  File "/usr/lib/python2.7/dist-packages/jujuclient.py", line 142, in run
    cert_path, data.get('environ-uuid'))
  File "/usr/lib/python2.7/dist-packages/jujuclient.py", line 150, in connect_env
    env = cls(endpoint, name=name, ca_cert=cert_path, env_uuid=env_uuid)
  File "/usr/lib/python2.7/dist-packages/jujuclient.py", line 522, in __init__
    self.conn = Connector.connect_socket(endpoint, self._ca_cert)
  File "/usr/lib/python2.7/dist-packages/jujuclient.py", line 162, in connect_socket
    endpoint, origin=endpoint, sslopt=sslopt)
  File "/usr/lib/python2.7/dist-packages/websocket/_core.py", line 219, in create_connection
    websock.connect(url, **options)
  File "/usr/lib/python2.7/dist-packages/websocket/_core.py", line 463, in connect
    self.sock = ssl.wrap_socket(self.sock, **sslopt)
  File "/usr/lib/python2.7/ssl.py", line 487, in wrap_socket
    ciphers=ciphers)
  File "/usr/lib/python2.7/ssl.py", line 243, in __init__
    self.do_handshake()
  File "/usr/lib/python2.7/ssl.py", line 405, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [Errno 1] _ssl.c:510: error:1409442E:SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version

[Nate Finch (natefinch)]

Note that 37017 is the port for mongo, which is not open outside of localhost. If you run testssl on 17017 from outside the local machine, you'll see it gives you the correct results:

 SSLv2 not offered (OK)
 SSLv3 not offered (OK)
 TLS 1 not offered
 TLS 1.1 not offered
 TLS 1.2 offered (OK)

(etc)

[Nate Finch (natefinch)]

Note that the quickstart and deployer problems are due to the python version on the machine they're running on. Python 2.7.9 added support for TLS 1.2 (which is what we restricted Juju to), which was released in December 2014. Is there a way we can just install a newer version of python with deployer/quickstart?

[Adam Collard (adam-collard)]

bug 1644153 is also related

[Adam Collard (adam-collard)]

also bug 1488245