[
https://issues.apache.org/jira/browse/HDDS-7035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated HDDS-7035:
---------------------------------
Labels: pull-request-available (was: )
> Virtual style addressing does not work with AWSv4 signatures
> ------------------------------------------------------------
>
> Key: HDDS-7035
> URL: https://issues.apache.org/jira/browse/HDDS-7035
> Project: Apache Ozone
> Issue Type: Bug
> Components: S3, Security
> Affects Versions: 1.2.1
> Environment: Ozone 1.2.1 cluster, setup with Kerberos authentication
> and *ozone.s3g.domain.name* set to {*}ozone-host.com{*}.
> NGINX reverse proxy in front of it that accepts all
> *<subdomain>.ozone-host.com* virtual host server names and passes it forward
> as a host header as expected.
> DNS has been suitably setup to resolve all *<subdomain>.ozone-host.com* to
> {*}ozone-host.com{*}.
> A bucket created with name {*}bucket{*}.
> AWS CLI client configuration setup to force virtual addressing style via
> *addressing_style = virtual* s3 sub-property.
> Reporter: ASF Reporter
> Assignee: Saketa Chalamchala
> Priority: Major
> Labels: pull-request-available
>
> When using the Virtual Style Addressing feature, the changes made to the
> request URI by class *VirtualHostStyleFilter* cause the signature to be
> calculated incorrectly.
> The following is an example of the difference observed:
> From AWS CLI, the following is the canonical request string passed for
> signing when contacting a virtual addressed hostname. Observe the path here
> to be a simple slash */* when accessing a bucket named *bucket* (using a
> sub-domain, i.e. virtual addressing):
> {code:java}
> GET
> /
> delimiter=%2F&encoding-type=url&list-type=2&prefix=ls
> host:bucket.ozone-host.com
> x-amz-content-sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
> x-amz-date:20220722T062934Z
> host;x-amz-content-sha256;x-amz-date
> e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 {code}
> On the service end, the canonical request string is built after the
> aforementioned class alters the request, parsing the host header to extract
> the bucket name. The string passed to class *StringToSignProducer* instead
> becomes the following. Observe that the path is now different ({*}/bucket{*}
> instead of a simple slash {*}/{*}):
> {code:java}
> GET
> /bucket
> delimiter=%2F&encoding-type=url&list-type=2&prefix=ls
> host:bucket.ozone-host.com
> x-amz-content-sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
> x-amz-date:20220722T062934Z
> host;x-amz-content-sha256;x-amz-date
> e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 {code}
> This naturally leads to a signature validation failure because the server
> computes a different signature string, which then throws an invalid token
> error:
> {code:java}
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.token.SecretManager$InvalidToken):
> Invalid S3 identifier:OzoneToken owner=root@REALM, renewer=, realUser=,
> issueDate=1970-01-01T00:00:00Z, maxDate=1970-01-01T00:00:00Z,
> sequenceNumber=0, masterKeyId=0, strToSign=AWS4-HMAC-SHA256
> 20220722T062934Z
> 20220722/us-east-1/s3/aws4_request
> 822555a762057e491b1ff84ae130337b4a15d72ec89f780c618f57420418bc87,
> signature=bc01067b738d4195e494620ce9e6b3c05961321b20356a15465fd172dd7ba474,
> awsAccessKeyId=root@REALM, omServiceId=null{code}
> An HTTP 500 Internal Server Error is sent to clients as a result of this
> exception.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
