RFR: 8281561: Disable http DIGEST mechanism with MD5 by default

[Michael McMahon]

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-retn at openjdk.java.net>  im Auftrag von Michael McMahon<michaelm at openjdk.java.net>
> Gesendet: Friday, March 4, 2022 1:33:06 PM
> An:net-dev at openjdk.java.net  <net-dev at 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<michaelm at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20220304/0defc7e3/attachment-0001.htm>