{add_acl, true} appears to break http_upload to s3

[echristiaans]

MongooseIM version: 3.7.0 Installed from: pkg Erlang/OTP version: 10.7.2.1

Describe the issue. We have the s3 upload feature enabled for htpp_upload. When setting the "add_acl" parameter to "true", the upload fails with The request signature we calculated does not match the signature you provided. Check your key and signing method.

Here is the full result of running the test as described on https://mongooseim.readthedocs.io/en/latest/modules/mod_http_upload/ "testing S3 configuration:

echo qwerty > tmp.txt

filesize="$(wc -c tmp.txt | awk '{print $1}')"
echo $filesize
content_type="text/plain"
urls="$(sudo mongooseimctl http_upload <REDACTED> test.txt "$filesize" "$content_type" 600)"
put_url="$(echo "$urls" | awk '/PutURL:/ {print $2}')"
get_url="$(echo "$urls" | awk '/GetURL:/ {print $2}')"
curl -v -T "./tmp.txt" -H "Content-Type: $content_type" $put_url

*   Trying <REDACTED>...
* TCP_NODELAY set
* Connected to s3-eu-west-1.amazonaws.com (52.218.96.90) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
  %%
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=US; ST=Washington; L=Seattle; O=Amazon.com, Inc.; CN=*.s3-eu-west-1.amazonaws.com
*  start date: Nov  9 00:00:00 2019 GMT
  %% {Host, Path, Method, Upstream}
*  expire date: Dec 10 12:00:00 2020 GMT
*  subjectAltName: host "s3-eu-west-1.amazonaws.com" matched cert's "s3-eu-west-1.amazonaws.com"
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert Baltimore CA-2 G2
*  SSL certificate verify ok.
> PUT /<REDACTED>/776ff087bf996d35d88e475224cad634c908c17de33e526de162d291dea1f2d2/test.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=<REDACTED>%2F20200803%2Feu-west-1%2Fs3%2Faws4_request&X-Amz-Date=20200803T112357Z&X-Amz-Expires=600&X-Amz-Signature=2fcae4f14d3e9b4db69c9d6cbecc39a68307cbaddd67ffe2c45120c473b20926&X-Amz-SignedHeaders=content-length%3Bcontent-type%3Bhost%3Bx-amz-acl HTTP/1.1
> Host: s3-eu-west-1.amazonaws.com
> User-Agent: curl/7.58.0
> Accept: */*
> Content-Type: text/plain
> Content-Length: 7
> Expect: 100-continue
>
< HTTP/1.1 403 Forbidden
< x-amz-request-id: BAA0C91ACCD60038
< x-amz-id-2: 78HyYs8WG0bbgqzxsOKJRcaAfY+kFoRPBWSjrdmpZgqYO1yA2Y3d4F1mcmVk2lJy9Bagr9mbNjU=
< Content-Type: application/xml
< Transfer-Encoding: chunked
< Date: Mon, 03 Aug 2020 11:24:48 GMT
< Connection: close
< Server: AmazonS3
<
<?xml version="1.0" encoding="UTF-8"?>
<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>AKIAW2725ZAYLV7PL75T</AWSAccessKeyId><StringToSign>AWS4-HMAC-SHA256
20200803T112357Z
20200803/eu-west-1/s3/aws4_request
68b63c11d49acf9257785ec1303fad461e8d712a810e7d854f46bd56d98131a8</StringToSign><SignatureProvided>2fcae4f14d3e9b4db69c9d6cbecc39a68307cbaddd67ffe2c45120c473b20926</SignatureProvided><StringToSignBytes>41 57 53 34 2d 48 4d 41 43 2d 53 48 41 32 35 36 0a 32 30 32 30 30 38 30 33 54 31 31 32 33 35 37 5a 0a 32 30 32 30 30 38 30 33 2f 65 75 2d 77 65 73 74 2d 31 2f 73 33 2f 61 77 73 34 5f 72 65 71 75 65 73 74 0a 36 38 62 36 33 63 31 31 64 34 39 61 63 66 39 32 35 37 37 38 35 65 63 31 33 30 33 66 61 64 34 36 31 65 38 64 37 31 32 61 38 31 30 65 37 64 38 35 34 66 34 36 62 64 35 36 64 39 38 31 33 31 61 38</StringToSignBytes><CanonicalRequest>PUT
/uploadssbxzivverchatcom/776ff087bf996d35d88e475224cad634c908c17de33e526de162d291dea1f2d2/test.txt
X-Amz-Algorithm=AWS4-HMAC-SHA256&amp;X-Amz-Credential=<REDACTED>%2F20200803%2Feu-west-1%2Fs3%2Faws4_request&amp;X-Amz-Date=20200803T112357Z&amp;X-Amz-Expires=600&amp;X-Amz-SignedHeaders=content-length%3Bcontent-type%3Bhost%3Bx-amz-acl
content-length:7
content-type:text/plain
host:s3-eu-west-1.amazonaws.com
x-amz-acl:

content-length;content-type;host;x-amz-acl
UNSIGNED-PAYLOAD</CanonicalRequest><CanonicalRequestBytes>50 55 54 0a 2f 75 70 6c 6f 61 64 73 73 62 78 7a 69 76 76 65 72 63 68 61 74 63 6f 6d 2f 37 37 36 66 66 30 38 37 62 66 39 39 36 64 33 35 64 38 38 65 34 37 35 32 32 34 63 61 64 36 33 34 63 39 30 38 63 31 37 64 65 33 33 65 35 32 36 64 65 31 36 32 64 32 39 31 64 65 61 31 66 32 64 32 2f 74 65 73 74 2e 74 78 74 0a 58 2d 41 6d 7a 2d 41 6c 67 6f 72 69 74 68 6d 3d 41 57 53 34 2d 48 4d 41 43 2d 53 48 41 32 35 36 26 58 2d 41 6d 7a 2d 43 72 65 64 65 6e 74 69 61 6c 3d 41 4b 49 41 57 32 37 32 35 5a 41 59 4c 56 37 50 4c 37 35 54 25 32 46 32 30 32 30 30 38 30 33 25 32 46 65 75 2d 77 65 73 74 2d 31 25 32 46 73 33 25 32 46 61 77 73 34 5f 72 65 71 75 65 73 74 26 58 2d 41 6d 7a 2d 44 61 74 65 3d 32 30 32 30 30 38 30 33 54 31 31 32 33 35 37 5a 26 58 2d 41 6d 7a 2d 45 78 70 69 72 65 73 3d 36 30 30 26 58 2d 41 6d 7a 2d 53 69 67 6e 65 64 48 65 61 64 65 72 73 3d 63 6f 6e 74 65 6e 74 2d 6c 65 6e 67 74 68 25 33 42 63 6f 6e 74 65 6e 74 2d 74 79 70 65 25 33 42 68 6f 73 74 25 33 42 78 2d 61 6d 7a 2d 61 63 6c 0a 63 6f 6e 74 65 6e 74 2d 6c 65 6e 67 74 68 3a 37 0a 63 6f 6e 74 65 6e 74 2d 74 79 70 65 3a 74 65 78 74 2f 70 6c 61 69 6e 0a 68 6f 73 74 3a 73 33 2d 65 75 2d 77 65 73 74 2d 31 2e 61 6d 61 7a 6f 6e 61 77 73 2e 63 6f 6d 0a 78 2d 61 6d 7a 2d 61 63 6c 3a 0a 0a 63 6f 6e 74 65 6e 74 2d 6c 65 6e 67 74 68 3b 63 6f 6e 74 65 6e 74 2d 74 79 70 65 3b 68 6f 73 74 3b 78 2d 61 6d 7a 2d 61 63 6c 0a 55 4e 53 49 47 4e 45 44 2d 50 41 59 4c 4f 41 44</CanonicalRequestBytes><RequestId>BAA0C91ACCD60038</RequestId><HostId>78HyYs8WG0bbgqzxsOKJRcaAfY+kFoRPBWSjrdmpZgqYO1yA2Y3d4F1* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1):
mcmVk2lJy9Bagr9mbNjU=</HostId></Error>

When examining the output, I noticed that the x-amz-acl: is empty, where I expected it to be x-amz-acl: public.

When removing {add_acl, true} from the config, uploading a file works:

curl -v -T "./tmp.txt" -H "Content-Type: $content_type" $put_url
*   Trying 52.218.110.19...
* TCP_NODELAY set
* Connected to s3-eu-west-1.amazonaws.com (52.218.110.19) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=US; ST=Washington; L=Seattle; O=Amazon.com, Inc.; CN=*.s3-eu-west-1.amazonaws.com
*  start date: Nov  9 00:00:00 2019 GMT
*  expire date: Dec 10 12:00:00 2020 GMT
*  subjectAltName: host "s3-eu-west-1.amazonaws.com" matched cert's "s3-eu-west-1.amazonaws.com"
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert Baltimore CA-2 G2
*  SSL certificate verify ok.
> PUT /uploadssbxzivverchatcom/47cedc24ee4d5ffdc5a377668ed4d7379d0dd65031a15ef7b43ab4d1f3e302df/test.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=<REDACTED>%2F20200803%2Feu-west-1%2Fs3%2Faws4_request&X-Amz-Date=20200803T114153Z&X-Amz-Expires=600&X-Amz-Signature=59bb83d070de6f27bc23f10e76156e3972ed27630a7a79c212a5a80e3a761378&X-Amz-SignedHeaders=content-length%3Bcontent-type%3Bhost HTTP/1.1
> Host: s3-eu-west-1.amazonaws.com
> User-Agent: curl/7.58.0
> Accept: */*
> Content-Type: text/plain
> Content-Length: 7
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
* We are completely uploaded and fine
< HTTP/1.1 200 OK
< x-amz-id-2: mW9WRQQZmr4NdqcxRVNKiWMVtixlPXY73Myl4zJfsTM54EWs64xZUahaPiguaoHhcowPg6H51do=
< x-amz-request-id: 1E9802F473ECC807
< Date: Mon, 03 Aug 2020 11:41:59 GMT
< ETag: "a86850deb2742ec3cb41518e26aa2d89"
< Content-Length: 0
< Server: AmazonS3
<
* Connection #0 to host s3-eu-west-1.amazonaws.com left intact

My relevant config looks like this:

{mod_http_upload, [
    %% Set max file size in bytes. Defaults to 10 MB.
    %% Disabled if value is `undefined`.
   {max_file_size, 104857600}, %% 100MB
    %% Use S3 storage backend
   {backend, s3},
    %% Set custom headers
   {custom_headers, [
      {<<"Access-Control-Allow-Origin">>, <<"*">>},
      {<<"Access-Control-Allow-Methods">>, <<"GET,HEAD,PUT,OPTIONS">>},
      {<<"Access-Control-Allow-Headers">>, <<"Content-Type">>},
      {<<"Content-Security-Policy">>, <<"default-src 'none'; frame-ancestors 'self' https://<REDACTED>:5285; ">>},
      {<<"X-Content-Type-Options">>, <<"nosniff">>}
   ]},
    %% Set options for S3 backend
   {s3, [
     {bucket_url, "https://s3-eu-west-1.amazonaws.com/<REDACTED>"},
     %%{add_acl, true},
     {region, "eu-west-1"},
     {access_key_id, "<REDACTED>"},
     {secret_access_key, "<REDACTED>"}
   ]}
 ]},

[sr1jan]

MongooseIM version: 3.7.0 Installed from: pkg Erlang/OTP version: 10.7.2.1

Describe the issue. We have the s3 upload feature enabled for htpp_upload. When setting the "add_acl" parameter to "true", the upload fails with The request signature we calculated does not match the signature you provided. Check your key and signing method.

When examining the output, I noticed that the `x-amz-acl:` is empty, where I expected it to be `x-amz-acl: public`.

When removing `{add_acl, true}` from the config, uploading a file works:

@michalslaski Even we encountered this bug in mongooseim v4 and had to remove the add-acl settings.

Also, in docs it says that the default max-file-size is not set and there is no size limit but when we tried to upload a png of size 76K it didn't work and threw SignatureDoesNotMatch but on uploading a small 5 bytes text file it was working properly.

We had to set the max-file-size property after which it was working properly.

[theowenyoung]

From https://xmpp.org/extensions/xep-0363.html#request,

If acl = true, we should respond header child in put, like:

<iq from='upload.montague.tld'
    id='step_03'
    to='[email protected]/garden'
    type='result'>
  <slot xmlns='urn:xmpp:http:upload:0'>
    <put url='https://upload.montague.tld/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/tr%C3%A8s%20cool.jpg'>
      <header name='x-amz-acl'>public-read</header>
    </put>
    <get url='https://download.montague.tld/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/tr%C3%A8s%20cool.jpg' />
  </slot>
</iq>

mongoose 5.0 not do the right response, we shouldn't use this option now.

[gustawlippa]

Hi! Thank you for reporting the issue and all the comments. I'll try to answer as much as I can, including the following comments, but I must admit I don't know much about http_upload so please correct me if I'm wrong anywhere.

1. Please try to update to a newer version of MongooseIM. I don't think this will solve your problems here, but it'll be easier for example to compare the config options when posting an issue.
2. Please note in https://esl.github.io/MongooseDocs/latest/modules/mod_http_upload/#testing-s3-configuration the comment: Note that if 'add_acl' option is enabled, then you must also add 'x-amz-acl' header: -H "x-amz-acl: public-read". I assume this is why your tests failed - in the first example x-amz-acl is added to X-Amz-SignedHeaders, which means that this header will be used to calculate the request signature. Since there is no such header in your PUT request, you see the error you described.
3. Regarding the max-file-size issue, could you please open a new GitHub issue if the problem is still relevant? From a quick look, not setting this option should indeed just not check against any size limit, but there may be an issue in calculating the signatures?
4. Regarding the IQ response and the PUT headers returned from MongooseIM: Yes, it seems that MongooseIM would not follow the XEP correctly in this case. Please note that, from what I see, the XEP has changed not so recently, and we may be compliant with an older version. If you'd like to notify us of what exactly is the issue, please feel free to open a new GitHub issue with the description. I must admit that I don't think updating this module to be compliant with the current XEP is in our roadmap for the foreseeable future. Please note that our open-source team is rather small. If you'd like it to shift its priorities, you could consider sponsoring an update of this module. Contact us at https://www.erlang-solutions.com/contact/ if this would be the case.

Hope I answered to your satisfaction, please comment if something is unclear and feel free to close the issue if the problem is resolved.

[chrzaszcz]

Closing due to no activity and nothing to fix at the moment.