EC2 signature verification does not take port into account
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Opinion
|
Low
|
Unassigned | ||
ec2-api |
Confirmed
|
Low
|
Unassigned |
Bug Description
Nova Version: master (and probably previous)
Tested with euca2ools 3.0.2-1 on Debian
Line numbers based on commit 48e8f992f46862c
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:/
Verification is done by Kestone's check_signature functon define: https:/
The root of the problem:
- euca2ools use port in host field ("hostname.
- 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/
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/
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).
It also seems that "ec2_port" configuration option can be used for that purpose as it already has this meaning to hold port visible by the user, not the one that EC2 API is listening on.
description: | updated |
Changed in nova: | |
status: | New → In Progress |
assignee: | nobody → Daniel Speichert (dasp) |
Changed in nova: | |
status: | Incomplete → Opinion |
Changed in ec2-api: | |
status: | New → Confirmed |
importance: | Undecided → Low |
Some things seem to have moved around, can you provide a link to any fixes you were proposing here?