Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use MD5 to sign S3 SigV4 bodies #920

Merged
merged 3 commits into from
Jun 20, 2016

Conversation

JordonPhillips
Copy link
Contributor

@JordonPhillips JordonPhillips commented May 13, 2016

S3 now supports optional SHA256 body signing, so this switches from SHA256 to MD5 to boost speed while reducing CPU and Memory usage when using sigv4 with S3. SHA256 will still be used on systems which do not support using MD5.

cc @kyleknap @jamesls

# impact, we opt to not SHA256 sign the body. Instead, we MD5 it.
# We will fall back to SHA256 when MD5 is not available, such as with
# FIPS systems.
if MD5_AVAILABLE:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't we just check if there's a Content-MD5 value in the request headers? Seems more definitive.

@jamesls
Copy link
Member

jamesls commented May 16, 2016

I think we need to have a config option to enable/disable this. Especially given that users can reject requests without unsigned payloads via IAM policies (http://docs.aws.amazon.com/AmazonS3/latest/API/bucket-policy-s3-sigv4-conditions.html), we need to give them a way to enable this behavior if needed.

I think I still prefer only doing this for the streaming s3 requests (put_object/upload_part) but I'm interested to hear other's thoughts.

@jamesls jamesls added incorporating-feedback and removed pr/needs-review This PR needs a review from a member of the team. labels May 16, 2016
@JordonPhillips JordonPhillips force-pushed the md5-sigv4 branch 3 times, most recently from e052515 to 3cda647 Compare May 17, 2016 21:50
@JordonPhillips
Copy link
Contributor Author

I updated to check for the header and added a config flag. Still need to look into making this exclusive to UploadPart and PutObject

@JordonPhillips JordonPhillips added pr/needs-review This PR needs a review from a member of the team. and removed incorporating-feedback labels Jun 3, 2016
@JordonPhillips
Copy link
Contributor Author

Personally, I think we should go for unsigned payloads regardless. It keeps things simple on our side and provides the performance boost consistently. What do you think @kyleknap

@kyleknap
Copy link
Contributor

kyleknap commented Jun 3, 2016

I talked to you about this, but wanted to capture the conversation. Lets only do unsigned payload for PutObject and UploadPart for the following reasons:

  1. The behavior change will only be scoped to PutObject and UploadPart leaving a lot of the control plane operations of S3 untouched.
  2. We have knowledge upfront if the payload is streaming by looking at the operation model when we create the context so we won't be hard coding PutObject and UploadPart into auth signer if we pass that knowledge to the context and we would probably would want to disable body signing for any future S3 operation that has a streaming body for its input.

@jamesls
Copy link
Member

jamesls commented Jun 6, 2016

I'm going to switch this to incorporating-feedback. Seems like this is going to change based on @kyleknap 's feedback so I'll defer reviewing this until those changes are made.

@JordonPhillips
Copy link
Contributor Author

Rebased on top of #936 to take advantage of context plumbing.

@JordonPhillips JordonPhillips added pr/needs-review This PR needs a review from a member of the team. and removed incorporating-feedback labels Jun 10, 2016
@JordonPhillips
Copy link
Contributor Author

Squashed the commits. Only the top commit needs to be reviewed.

if s3_config is None:
s3_config = {}
use_sha256 = s3_config.get('sha256_sign_s3v4_payload', False)
if request_signer.signature_version == 's3v4' and \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Questions for everyone: if the users opt-in to sha256_sign_s3v4_payload, should we also do MD5 calculation? Based on the docstring you have it is not clear that you turn off MD5 signing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, we shouldn't disable MD5. Rather, we should enforce SHA256 if that config isn't explicitly set and MD5 isn't present.

@JordonPhillips
Copy link
Contributor Author

Moved the config value checking into auth so that MD5 is not impacted.

@jamesls jamesls removed the pr/needs-review This PR needs a review from a member of the team. label Jun 13, 2016
@JordonPhillips JordonPhillips added pr/needs-review This PR needs a review from a member of the team. and removed incorporating-feedback labels Jun 13, 2016
@JordonPhillips
Copy link
Contributor Author

Rebased against the latest redirector and tentatively changed the name to payload_signing_enabled

s3_config = {}

sign_payload = s3_config.get('payload_signing_enabled')
if sign_payload in [True, 'True', 'true']:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-1 to this. We shouldn't let the lack of typed parsing in the parser/config objects leak into dependent objects. I would prefer we try to normalize this as high up the stack as we can. Likely in the client creator for now.

@jamesls jamesls added incorporating-feedback and removed pr/needs-review This PR needs a review from a member of the team. labels Jun 14, 2016
@JordonPhillips JordonPhillips added pr/needs-review This PR needs a review from a member of the team. and removed incorporating-feedback labels Jun 14, 2016
@JordonPhillips
Copy link
Contributor Author

Updated

@jamesls
Copy link
Member

jamesls commented Jun 14, 2016

:shipit: Looks good to me. Thanks for incorporating the feedback.

@JordonPhillips JordonPhillips force-pushed the md5-sigv4 branch 2 times, most recently from 10cda43 to 70e16bf Compare June 17, 2016 23:11
@codecov-io
Copy link

codecov-io commented Jun 17, 2016

Current coverage is 97.31%

Merging #920 into develop will increase coverage by 0.04%

@@            develop       #920   diff @@
==========================================
  Files            43         43          
  Lines          6909       7014   +105   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits           6721       6826   +105   
  Misses          188        188          
  Partials          0          0          

Powered by Codecov. Last updated by 2db54af...d6d7f1e

@jamesls
Copy link
Member

jamesls commented Jun 17, 2016

da6f25fbf541885a243ad90a3ecee3604aefa444 looks good to me.

Knowing the headers can be useful, especially when the service
model does not add them to the actual response.
S3 generally provides enough information for us to redirect
requests, so this attempts to do so. To prevent a massive
number of additional requests, bucket regions are cached.

When a redirect occurs, a warning is printed that tells the
customer they should use a client configured to the proper
region to avoid additional requests.
@JordonPhillips JordonPhillips added pr/ready-to-merge This PR is ready to be merged. and removed pr/needs-review This PR needs a review from a member of the team. labels Jun 20, 2016
@jamesls
Copy link
Member

jamesls commented Jun 20, 2016

@JordonPhillips failing build?

@kyleknap
Copy link
Contributor

🚢 Thanks for all the work you put into it.

@JordonPhillips
Copy link
Contributor Author

@jamesls it's codecov. What is our official target percent?

S3 now supports optional SHA256 body signing, so this switches from
SHA256 to MD5 to boost speed while reducing CPU and Memory usage when
using sigv4 with S3. SHA256 will still be used on systems which do
not support using MD5.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr/ready-to-merge This PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants