Eucalyptus does not allow api connection over https

A clear issue here is that if Eucalyptus generates its own SSL certificate, the tools accessing it via https won't be able to automatically trust the connection because the cert will be unsigned.

I think a good option would be to have http on 8773 and https on another port if the user has specified a simple configuration option to use a legitimate SSL certificate. This would allow for easy setup on purely private clouds, but also not prevent people from slightly exposing their setup to the internet if they wish to use an external control tool such as Landscape or RightScale.

Is there any reason this should be private?

It is a security issue, but does not need to be private. Changing that now...

"As they carry QueryID/SecretKey in clear, anyone that can sniff the network can gain admin privileges on eucalyptus."

This assertion is incorrect. The secret is never sent in the clear. A replay attack is possible and its gravity will depend on the specific operation that is replayed.

Chris Jones is correct. There is a workaround for this however which involves explicitly trusting the cert, which depending on the client may or may not be a manual step.

Eucalyptus upstream will fix this in the next release.

thanks.

On Mon, Nov 16, 2009 at 05:27:37PM -0000, Neil Soman wrote:
> This assertion is incorrect. The secret is never sent in the clear. A
> replay attack is possible and its gravity will depend on the specific
> operation that is replayed.

The hash computed by the client includes a time stamp and a time of
expiry, so it's only vulnerable to a replay attack for a limited time.

Also, the hash is specific to the request (the contents of the request
is part of the hash calculation), so if someone were to intercept it and
try to use it, they would only be able to perform operations the user
already intended to perform. If Eucalyptus were to keep track of hashes
and reject an already seen hash (naturally expiring them as time
passes), this vulnerability should be entirely mitigated, as far as I
can see.

Support for SSL is already in the code as of 1.6.1. The blocker to including it in the original release was client support (as Neil mentioned). This is on the agenda and will be addressed shortly.

c

Soren: to me the privacy angle is just as important as the security angle. Being unable to replay attacks is great, but leaking information unnecessarily is still sub-optimal.
It sounds like the right things are happening upstream though, thanks!

------------------------------------------------------------
revno: 1070 [merge]
committer: decker <decker@personal-army>
branch nick: 1.6
timestamp: Tue 2009-11-17 08:45:59 -0800
message:
  enables the StartTLS-like SSL support on port 8773 and includes the trustStore needed by java clients in the euca2-credentials.zip
    ------------------------------------------------------------
    revno: 1069.1.2
    committer: decker <decker@personal-army>
    branch nick: 1.6
    timestamp: Tue 2009-11-17 06:45:45 -0800
    message:
      generate the jsse cacerts keystore needed for java clients w/ SSL.
    ------------------------------------------------------------
    revno: 1069.1.1
    committer: decker <decker@personal-army>
    branch nick: 1.6
    timestamp: Tue 2009-11-17 05:39:48 -0800
    message:
      enable starttls-like behaviour for the ssl handler

This bug was fixed in the package eucalyptus - 1.6.1~bzr1083-0ubuntu1

---------------
eucalyptus (1.6.1~bzr1083-0ubuntu1) lucid; urgency=low

  [ Dustin Kirkland ]
  * Merge upstream bzr revision 1082; the following bugs have been fixed
    upstream since the last merge:
    - LP: #378969 - private bug
    - LP: #404842 - init script fix
    - LP: #434283 - existing keys should be overwritten unconditionally
    - LP: #445990 - run instance will fail if no kernel or ramdisk specified
    - LP: #447457 - euca_conf --register-sc ... check the number of parameters
    - LP: #449874 - fix incorrect help text (--delete-nodes doesn't exist)
    - LP: #451795 - show registered images in elastic fox
    - LP: #454405 - return correct networkIndex values on describeInstances
    - LP: #456877 - init script fix
    - LP: #456878 - fix for libvirt xen driver
    - LP: #460085 - fix rampart memory leak
    - LP: #461156 - fix authentication problem w/ userdata
    - LP: #461394 - fix multiple concurrent snapshots on the same volume
    - LP: #461444 - fix memory leaks in NC getConsoleOutput and startup_thread
    - LP: #469984 - fix iptables rules issue
    - LP: #477776 - fix query string authentication
    - LP: #480783 - allow api connection over https
    - LP: #482249 - fix "Describe Regions"
    - LP: #484217 - create keypair should return an error if key exists
    - LP: #490623 - parse RFC 1123 formatted datetime
  * debian/control:
    - make all package lists one-per-line (makes changes henceforth more
      readable), sort lists
    - depend on rampart >= 1.3.0-0ubuntu6, which fixes some shared library
      installation issues
  * debian/patches/04-axis2c-1.6.0-rampart-1.3.0.patch: drop this patch,
    since Eucalyptus 1.6.1 natively supports axis2c 1.6.0 now
  * debian/eucalyptus-cloud.install,
    debian/eucalyptus-common.eucalyptus.upstart,
    debian/eucalyptus-java-common.install, debian/eucalyptus-sc.install,
    debian/eucalyptus-walrus.install: update static version number strings
    from "1.6-devel" to "1.6.1"; (we should really find a better way to do
    this)
  * debian/patches/03-DESTDIR.patch: ported forward for merge
 -- Dustin Kirkland <email address hidden> Tue, 01 Dec 2009 21:09:28 -0600