yahoo-eng-team team mailing list archive

[Daniel Speichert <1278526@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Nova Version: master (and probably previous)
Tested with euca2ools 3.0.2-1 on Debian
Line numbers based on commit 48e8f992f46862cb4f50fe0cc9b77a3017e7bb23 in master for nova, commit 8557e4756e8a326579df826076478d98ca634345 in master for keystone.

EC2 protocol requires "Signature" calculated for every request. The signature is calculated from:  access_key, signature, host, verb, path and params.
These values together with the signature are passed to Keystone for verification as seen in: https://github.com/openstack/nova/blob/master/nova/api/ec2/__init__.py#L201-L232

Verification is done by Kestone's check_signature functon define:
https://github.com/openstack/keystone/blob/master/keystone/contrib/ec2/controllers.py#L53-L67

The root of the problem:
- euca2ools use port in host field ("hostname.of.endpoint:8773" for signing signature
- keystone takes into account that client signing the request may append the port into the "host" field and does the signature verification twice: with the port and without
- nova never passes the port along with the host to keystone (line 205 of nova/api/ec2/__init__.py)

This results in always incorrect signature rendering EC2 protocol
useless for clients that append port to the host. It is not an issue if
the port is not used to calculate signature if such clients exist.

Simple fix: append the port in /nova/api/ec2/__init__.py line 204.

Actual problem: for deployments that use SSL termination proxy and/or rewrite URLs, the port visible to the client is not necessarily the standard port used by Nova for EC2 (8773) nor the one specified in the configuration for nova to listen on.
Therefore, I suggest to create a new configuration option for this purpose, which dynamically defaults to ec2_listen_port (usually 8773).

** Affects: nova
     Importance: Undecided
         Status: New


** Tags: nova

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1278526

Title:
  EC2 signature verification does not take port into account

Status in OpenStack Compute (Nova):
  New

Bug description:
  Nova Version: master (and probably previous)
  Tested with euca2ools 3.0.2-1 on Debian
  Line numbers based on commit 48e8f992f46862cb4f50fe0cc9b77a3017e7bb23 in master for nova, commit 8557e4756e8a326579df826076478d98ca634345 in master for keystone.

  EC2 protocol requires "Signature" calculated for every request. The signature is calculated from:  access_key, signature, host, verb, path and params.
  These values together with the signature are passed to Keystone for verification as seen in: https://github.com/openstack/nova/blob/master/nova/api/ec2/__init__.py#L201-L232

  Verification is done by Kestone's check_signature functon define:
  https://github.com/openstack/keystone/blob/master/keystone/contrib/ec2/controllers.py#L53-L67

  The root of the problem:
  - euca2ools use port in host field ("hostname.of.endpoint:8773" for signing signature
  - keystone takes into account that client signing the request may append the port into the "host" field and does the signature verification twice: with the port and without
  - nova never passes the port along with the host to keystone (line 205 of nova/api/ec2/__init__.py)

  This results in always incorrect signature rendering EC2 protocol
  useless for clients that append port to the host. It is not an issue
  if the port is not used to calculate signature if such clients exist.

  Simple fix: append the port in /nova/api/ec2/__init__.py line 204.

  Actual problem: for deployments that use SSL termination proxy and/or rewrite URLs, the port visible to the client is not necessarily the standard port used by Nova for EC2 (8773) nor the one specified in the configuration for nova to listen on.
  Therefore, I suggest to create a new configuration option for this purpose, which dynamically defaults to ec2_listen_port (usually 8773).

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1278526/+subscriptions