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

v0.101.4 prep #153

Merged
merged 2 commits into from Aug 22, 2023
Merged

v0.101.4 prep #153

merged 2 commits into from Aug 22, 2023

Conversation

cpu
Copy link
Member

@cpu cpu commented Aug 21, 2023

0.101.4 release prep

This branch targets a base of rel-0.101 to prepare a point release in the v0.101.x series.

Proposed release notes

  • certificate path building and verification is now capped at 100 signature validation operations to avoid the risk of CPU usage denial-of-service attack when validating crafted certificate chains producing quadratic runtime. This risk affected both clients, as well as servers that verified client certificates.

verify_cert: enforce maximum number of signatures.

Pathbuilding complexity can be quadratic, particularly when the set of intermediates all have subjects matching a trust anchor. In these cases we need to bound the number of expensive signature validation operations that are performed to avoid a DoS on CPU usage.

This commit implements a simple maximum signature check limit inspired by the approach taken in the Golang x509 package. No more than 100 signatures will be evaluated while pathbuilding. This limit works in practice for Go when processing real world certificate chains and so should be appropriate for our use case as well.

Cargo: version 0.101.3 -> 0.101.4

Bumps the Cargo version.

Pathbuilding complexity can be quadratic, particularly when the set of
intermediates all have subjects matching a trust anchor. In these cases
we need to bound the number of expensive signature validation operations
that are performed to avoid a DoS on CPU usage.

This commit implements a simple maximum signature check limit inspired
by the approach taken in the Golang x509 package. No more than 100
signatures will be evaluated while pathbuilding. This limit works in
practice for Go when processing real world certificate chains and so
should be appropriate for our use case as well.
@cpu cpu self-assigned this Aug 21, 2023
@codecov
Copy link

codecov bot commented Aug 21, 2023

Codecov Report

Merging #153 (b5f09de) into rel-0.101 (989ef02) will increase coverage by 0.13%.
The diff coverage is 100.00%.

@@              Coverage Diff              @@
##           rel-0.101     #153      +/-   ##
=============================================
+ Coverage      94.75%   94.89%   +0.13%     
=============================================
  Files             15       15              
  Lines           3432     3504      +72     
=============================================
+ Hits            3252     3325      +73     
+ Misses           180      179       -1     
Files Changed Coverage Δ
src/error.rs 52.17% <100.00%> (+1.06%) ⬆️
src/verify_cert.rs 96.48% <100.00%> (+1.29%) ⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@ctz ctz added this pull request to the merge queue Aug 22, 2023
Merged via the queue into rustls:rel-0.101 with commit d7f6aa4 Aug 22, 2023
22 checks passed
@stanal
Copy link

stanal commented Aug 24, 2023

can give some suggestion whether should i update in my C-S system:

  1. client -- kong --- server
  2. client connect to kong with tls, kong will send its certification to client, and client will verify this certification
  3. kong do not need to verify client,
  4. kong only do tcp proxy to server , kong do tcp connect to server

@djc
Copy link
Member

djc commented Aug 24, 2023

You should just update both. Updating them should be trivial, since this change in semver-compatible.

@stanal
Copy link

stanal commented Aug 24, 2023

You should just update both. Updating them should be trivial, since this change in semver-compatible.

our client is an large online application, we want to evaluate the influence on client, I check rustsec https://rustsec.org/advisories/RUSTSEC-2023-0052.html describe that only has influence when tls client/server that accept client certificate, but in our scenes, client does not supply certificate to server.

@djc
Copy link
Member

djc commented Aug 24, 2023

If your server doesn't accept client certificates it should not be affected.

@cpu cpu deleted the cpu-v0.101.4 branch August 24, 2023 13:14
@stanal
Copy link

stanal commented Aug 25, 2023

If your server doesn't accept client certificates it should not be affected.

is the same for client ? should client be affected ?

@djc
Copy link
Member

djc commented Aug 25, 2023

Clients always accept server certificates, so they are definitely affected.

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.

None yet

4 participants