aws/aws-sdk-java

s3: resource object-lock should be in string to sign when use v2 signer, otherwise will be 403 signature not match

joke-lee opened this issue · 4 comments

joke-lee commented

Describe the bug

when use v2 signer in bucket object-lock, the aws s3 server output say in the server side ,the string to signed with object-lock is used, but in the aws java sdk debug info says in client side, string to signed not contained object-lock

aws java sdk side log

DEBUG Sending Request: GET http://s3.amazonaws.com /ylywormtest/ Parameters: ({"object-lock":[null]}Headers: (amz-sdk-invocation-id: f45a7c6e-b194-e1ad-732c-3df03b957b5f, Content-Type: application/octet-stream, User-Agent: aws-sdk-java/1.11.820 Windows_10/10.0 Java_HotSpot(TM)_64-Bit_Server_VM/11.0.2+9-LTS java/11.0.2 vendor/Oracle_Corporation, ) 
2023-11-21 17:30:38 DEBUG Calculated string to sign:
"GET

application/octet-stream
Tue, 21 Nov 2023 09:30:38 GMT
/ylywormtest/"
 DEBUG CookieSpec selected: default
 DEBUG Auth cache not set in the context
 DEBUG Connection request: [route: {}->http://s3.amazonaws.com:80][total kept alive: 1; route allocated: 1 of 50; total allocated: 1 of 50]

error detail log

 DEBUG http-outgoing-0 << "<?xml version="1.0" encoding="UTF-8"?>[\n]"
 DEBUG http-outgoing-0 << "<Error><Code>SignatureDoesNotMatch</Code><Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message><AWSAccessKeyId>AKIARPFX22UE3RB33VIC</AWSAccessKeyId><StringToSign>GET[\n]"
 DEBUG http-outgoing-0 << "[\n]"
 DEBUG http-outgoing-0 << "application/octet-stream[\n]"
 DEBUG http-outgoing-0 << "Tue, 21 Nov 2023 09:30:38 GMT[\n]"
 DEBUG http-outgoing-0 << "/ylywormtest/?object-lock</StringToSign><SignatureProvided>5bJsijdrivBVZPSQXNLi29n9bQg=</SignatureProvided><StringToSignBytes>47 45 54 0a 0a 61 70 70 6c 69 63 61 74 69 6f 6e 2f 6f 63 74 65 74 2d 73 74 72 65 61 6d 0a 54 75 65 2c 20 32 31 20 4e 6f 76 20 32 30 32 33 20 30 39 3a 33 30 3a 33 38 20 47 4d 54 0a 2f 79 6c 79 77 6f 72 6d 74 65 73 74 2f 3f 6f 62 6a 65 63 74 2d 6c 6f 63 6b</StringToSignBytes><RequestId>G5F3K9JXCV611DE5</RequestId><HostId>Wh4VE4N2swGQUcT5ALmNPrnYH1Sfj8v9pd1sJpB4Z0HrQ9LjVooHsczBTHnz9yYahTjHeHbSsbA=</HostId></Error>[\r][\n]"
 DEBUG http-outgoing-0 << "0[\r][\n]"

#3058 fix this

Expected Behavior

in v2 signer, object-lock resource should be contained in string to sign

Current Behavior

in v2 signer, current object-lock resource is not contained in string to sign, that make not same with aws s3 server side, which occur 403 signature not match

Reproduction Steps

use aws java sdk v2 signer to get bucket lock configuration

    public static void main(String[] args) {
        AWSCredentials credentials = new BasicAWSCredentials("", "");
        ClientConfiguration opts = new ClientConfiguration();
        opts.setSignerOverride("S3SignerType");
//        opts.setSignerOverride("AWSS3V4SignerType");
        opts.setProtocol(Protocol.HTTP);
        opts.setRetryPolicy(PredefinedRetryPolicies.NO_RETRY_POLICY);
        AmazonS3 conn = new AmazonS3Client(credentials, opts);
        conn.setEndpoint("s3.amazonaws.com");
        conn.setS3ClientOptions(new S3ClientOptions().withPathStyleAccess(true));
        GetObjectLockConfigurationRequest request = new GetObjectLockConfigurationRequest();
        request.setBucketName("ylywormtest");
        conn.getObjectLockConfiguration(request);
    }

Possible Solution

#3058 fix this

Additional Information/Context

No response

AWS Java SDK version used

master

JDK version used

java 11

Operating System and version

win10

debora-ito commented

@joke-lee you don't need to set a signerOverride, I believe this is causing the signature error.

By default, the SDK will choose the right signature algorithm for the client and region you're using.
Does it work if you don't set the signerOverride in the ClientConfiguration?

Here's a version of the code you provided, using non-deprecated methods:

        ClientConfiguration clientConfig = new ClientConfiguration()
                .withProtocol(Protocol.HTTP)
                .withRetryPolicy(PredefinedRetryPolicies.NO_RETRY_POLICY);

        AmazonS3 s3Client = AmazonS3ClientBuilder.standard()
                .withCredentials(new AWSStaticCredentialsProvider(credentials))
                .withClientConfiguration(clientConfig)
                .withPathStyleAccessEnabled(Boolean.TRUE)
                .build();

        GetObjectLockConfigurationRequest request = new GetObjectLockConfigurationRequest()
                        .withBucketName(BUCKET_NAME);

        GetObjectLockConfigurationResult result = s3Client.getObjectLockConfiguration(request);
joke-lee commented

v4 signature is ok, v2 is not work right, i think the aws java sdk client should do the same with aws server, where the aws server says in it's message:

<StringToSign>GET[\n]"
"[\n]"
"application/octet-stream[\n]"
"Tue, 21 Nov 2023 09:30:38 GMT[\n]"
 "/ylywormtest/?object-lock</StringToSign>

but in client side debug message

2023-11-21 17:30:38 DEBUG Calculated string to sign:
"GET

application/octet-stream
Tue, 21 Nov 2023 09:30:38 GMT
/ylywormtest/"

, i know i can use v4 signer to pass signature error, but i still think to fix v2 signer is right thing

debora-ito commented

SigV2 is on deprecation path, it's not recommended (it's less secure than SigV4) and we don't intend to change it at this point - see the banner in the S3 documentation page for more info - https://docs.aws.amazon.com/AmazonS3/latest/userguide/auth-request-sig-v2.html

@joke-lee Is there any particular reason you need to use SigV2? Can you use SigV4 instead?

github-actions commented

It looks like this issue has not been active for more than five days. In the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please add a comment to prevent automatic closure, or if the issue is already closed please feel free to reopen it.