On 02/09/2025 18:19, Rémy Maucherat wrote:
On Tue, Sep 2, 2025 at 6:04 PM Mark Thomas <[email protected]> wrote:
On 02/09/2025 17:00, [email protected] wrote:
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new 9126de9274 Switch strong ETag generation from SHA-1 to SHA-256
9126de9274 is described below
commit 9126de92742cb5eeaef5fa6b902eaec4291cd7de
Author: Mark Thomas <[email protected]>
AuthorDate: Tue Sep 2 17:00:43 2025 +0100
Switch strong ETag generation from SHA-1 to SHA-256
Given the RFC 9110 recommendation, I'm minded to back-port this all the
way to 9.0.x. Thoughts?
It's beyond overkill given the use ;)
Probably.
My thinking went something like:
- Coverity is complaining. What does the HTTP RFC say?
- The RFC recommends a collision resistant hash (i.e. not SHA-1) if you
are going to use hashes to generate strong ETags.
- Is the RFC recommendation for correctness or security (or both)?
- Don't know.
- Can I see a way to exploit a collision?
- No.
- Might there be a way to exploit this that I haven't seen? Maybe.
- Do I spend more time thinking about the security or do I just update
the hash to SHA-256.
- Updating the hash is quick, simple, aligns us with the RFC and
mitigates any security risks that may or may not be present.
- Performance wise I took a quick look at the Wikipedia article [1]
and the performance difference looked marginal given that the ETag
will be cached with the static resource
Given the above, I'm still minded to back-port these changes but I will
check the relative performance of the Java implementations of SHA-1 and
SHA-256 and report back first.
Mark
[1] https://en.wikipedia.org/wiki/Secure_Hash_Algorithms
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
