Skip to content

Validate CSR signatures and check signature type#386

Merged
jsha merged 2 commits intoletsencrypt:mainfrom
mcpherrinm:mattm-reject-sha1
Jun 27, 2022
Merged

Validate CSR signatures and check signature type#386
jsha merged 2 commits intoletsencrypt:mainfrom
mcpherrinm:mattm-reject-sha1

Conversation

@mcpherrinm
Copy link
Copy Markdown
Contributor

@mcpherrinm mcpherrinm commented Jun 7, 2022

With the deprecation of SHA1 signatures on CSRs, we should ensure Pebble rejects them as well. As well, ensure the signature itself is valid. Unlike Boulder, which currently allows SHA1 to be configurably accepted, Pebble will always reject SHA1.

There's no tests for the WFE code in this repository, so I didn't add a unit test ensuring SHA1 is rejected. However, I tested this by running an ACME client against Pebble that was patched to use SHA1 signatures and verifying they were successfully rejected, as well as ensuring SHA256 was still accepted

Fixes #384

@osirisinferi
Copy link
Copy Markdown
Contributor

Boulder rejects SHA1 hashes in its ca "module", not wfe. Could that matter regarding ACME client behavior differences between Pebble and Boulder?

@mcpherrinm mcpherrinm force-pushed the mattm-reject-sha1 branch from d5bfbd2 to f11eff4 Compare June 7, 2022 23:20
With the deprecation of SHA1 signatures on CSRs, we should ensure Pebble
rejects them as well.  As well, ensure the signature itself is valid.
@mcpherrinm mcpherrinm force-pushed the mattm-reject-sha1 branch from f11eff4 to 0dba3f8 Compare June 7, 2022 23:21
@mcpherrinm
Copy link
Copy Markdown
Contributor Author

I don't think where exactly the messages are rejected matters: Pebble is a much smaller codebase with less modules than boulder so it won't ever align the same exactly. Pebble only handles the CSRs within the WFE (web frontend) code here so it would require restructuring more code to have the check occur elsewhere.

Copy link
Copy Markdown
Contributor

@aarongable aarongable left a comment

Choose a reason for hiding this comment

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

Overall LGTM, just a few formatting comments

This removes all of the use of "msg"+err.Error() in this file.
In some cases I've added a variable to avoid over-long lines without
resorting to awkwardly line breaking in function calls
@mcpherrinm mcpherrinm requested a review from aarongable June 15, 2022 15:20
@mcpherrinm
Copy link
Copy Markdown
Contributor Author

Design question: Should either of these checks be gated on Pebble's "strict mode"?

Copy link
Copy Markdown
Contributor

@aarongable aarongable left a comment

Choose a reason for hiding this comment

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

LGTM. I wouldn't gate rejecting SHA1 behind "strict mode": half the reason we want to remove it is that Go itself is going to remove support, so Pebble needs to deprecate it just as much as Boulder does. Validating the signature could be behind the strict-mode flag but I don't feel strongly either way.

@mcpherrinm
Copy link
Copy Markdown
Contributor Author

I don't think it's likely to be helpful to anyone to allow invalid CSR signatures, especially since Let's Encrypt and presumably other CAs always require valid CSR signatures. So I think we can leave it as-is and merge this.

@jsha jsha merged commit b4b2ad3 into letsencrypt:main Jun 27, 2022
@mcpherrinm mcpherrinm deleted the mattm-reject-sha1 branch June 28, 2022 02:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Pebble should fail CSR requests signed using SHA-1

4 participants