Bernd,
If I understand you correctly, there is no negotiation at this level.
Once Digest is selected, it's up to the server to choose the algorithm
and then the client can either accept it or else reject it and the whole
request fails then.
It's true that with this change, if the server proposes MD5 by default,
then the request will fail. But, that's the point of the change, and the
compatibility impact is considered in the related CSR. In that case,
either the server needs to change or else the system property to
re-enable MD5 must be set.
I'd like to try out (for the next review round) the idea of establishing
the default "insecure" protocols as a fixed security property (including
MD5 and SHA-1) and then provide a settable system or networking property
to override that.
Thanks
Michael
On 04/03/2022 14:03, Bernd Eckenfels wrote:
Hello,
While I like the idea of the user having to explicitely specify the rexenabled
legacy algorithms (as opposed to removing the defaultsdisabled) it is not the
style the other algorithm policies in JCE work - so it might be confusing.
But, more critically I would separate the enabling/implementing of new
algorithms from disabling old ones. Especially since there needs to be changes
on the server side first. (And I wonder if this can be negotiated anyway?).
So why not start with a “provide new DIGEST Mechanisms” change? Having said
that, would it need to start out with disabled new mechanisms so the update
won’t change the behavior? (If there is no negotiation?)
Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: net-dev<net-dev-r...@openjdk.java.net> im Auftrag von Michael
McMahon<micha...@openjdk.java.net>
Gesendet: Friday, March 4, 2022 1:33:06 PM
An:net-dev@openjdk.java.net <net-dev@openjdk.java.net>
Betreff: Re: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default
On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon<micha...@openjdk.org> wrote:
Hi,
Could I get the following change reviewed please, which is to disable the MD5 message
digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm
can be opted into by setting a new system property
"http.auth.digest.reEnabledAlgs" to include the value MD5. The change also
updates the Digest authentication implementation to use some of the more secure features
defined in RFC7616, such as username hashing and additional digest algorithms like SHA256
and SHA512-256.
- Michael
I considered that and implemented it that way at the start, but what you would end up
with then is users running their code with something like: -DdisabledAlgNames=""
I find that style leads to a much less explicit "opting in" than by making the
user explicitly identify the deprecated algorithm by name.
Right - but it would also allow users to opt-in to disable more algorithms by
listing them in the property
In practical terms, the only other likely candidate there is SHA-1. If that
weren't the case, I'd disagree with your point.
So, maybe, we could have a 2nd net property with the default disabled
algorithms and in net.properties we identify MD5 only for now. Users could add
to that list if they want or even specify it on the command line. I think it's
potentially confusing, but maybe there is a case for adding to the disabled
list. I need to think about a way to do this without subvertng the point about
making the user explicitly opt in.
I considered that and implemented it that way at the start, but what you would end up
with then is users running their code with something like: -DdisabledAlgNames=""
I find that style leads to a much less explicit "opting in" than by making the
user explicitly identify the deprecated algorithm by name.
Right - but it would also allow users to opt-in to disable more algorithms by
listing them in the property
In practical terms, the only other likely candidate there is SHA-1. If that
weren't the case, I'd disagree with your point.
So, maybe, we could have a 2nd net property with the default disabled
algorithms and in net.properties we identify MD5 only for now. Users could add
to that list if they want or even specify it on the command line. I think it's
potentially confusing, but maybe there is a case for adding to the disabled
list. I need to think about a way to do this without subvertng the point about
making the user explicitly opt in.
Thinking about it again, I wonder if we should just deprecate SHA-1 at the same
time. I think there will be less compatibility impact than with MD5, and it's
basically broken as well. I don't see a reason to opt out of other algorithms
at this time.
-------------
PR:https://git.openjdk.java.net/jdk/pull/7688
