New issue
Advanced search Search tips

Issue 820753 link

Starred by 2 users
Status: Unconfirmed
Owner: ----
Cc:
mef@chromium.org
asanka@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Semi-broken MD5-sess implementation

Reported by zhenyu....@gmail.com, Mar 10 2018 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Visit a Website that uses MD5-sess digest authentication
2. Upon successful authentication, open developer tool - network - preserve log
3. Continuously visit several pages in short interval
4. Inspect the Authorization header of each request, the "cnonce" field

What is the expected behavior?
The cnonce values of all requests should be the same.

According to RFC2617: "If the "algorithm" directive's value is "MD5-sess", then A1 is calculated only once - on the first request by the client following receipt of a WWW-Authenticate challenge from the server..."

What went wrong?
Each request uses a different cnonce value.

This behavior is not compliant with RFC, and may cause different symptons depending on server implementation.

In the best scenario, the server checks and discovers cnonce change and recalculates the A1, which leads to varying performance penalty depending on authentication architecture;

In the worst case, the server would keep failing the authentication every other request, make the site practically not usable.

Did this work before? N/A 

Chrome version: 64.0.3282.186  Channel: n/a
OS Version: 10.0
Flash Version:

Comment 1 by zhenyu....@gmail.com, Mar 11 2018 

Another interpretation of RFC2617 is that:
- the cnonce may change per request, however,
- A1 must only be calculated once using the very first cnonce of the session

Which means that, for example when qop=auth:
- A1 = H(username:real:passwd):nonce:cnonce#1
- Digest = KD(H(A1),nonce:nc:cnonce#x:qop:H(A2))
Both cnonce#1 and cnonce#x contribute to the final digest

But current implementation is not doing this either. Reading the code, it seems always do the following:
- A1` = H(username:real:passwd):nonce:cnonce#x
- Digest = KD(H(A1`),nonce:nc:cnonce#x:qop:H(A2))

Neither very first cnonce#1, nor A1 was remembered for the auth session.

Comment 2 by krajshree@chromium.org, Mar 11 2018

Labels: Needs-Triage-M64

Comment 3 by krajshree@chromium.org, Mar 12 2018

Labels: Triaged-ET TE-NeedsTriageHelp
The issue seems to be out of TE-scope as it is related to MD5-sess implementation and algorithm. Hence, adding label TE-NeedsTriageHelp for further investigation from dev team.

Thanks...!!

Comment 4 by mattm@chromium.org, Mar 12 2018

Components: -Internals>Network Internals>Network>Auth

Comment 5 by mmenke@chromium.org, Mar 12 2018

Cc: mef@chromium.org
[+mef]:  Misha, who owns auth now?

Comment 6 by mef@chromium.org, Mar 12 2018 

It seems like we are going to own the auth going forward.

I've chatted with Asanka, and he gracefully agreed to comment on this issue, but general danger is that current behavior may be expected and relied upon.

Comment 7 by zhenyu....@gmail.com, Mar 12 2018 

I did additional tests on other browsers, here are my findings:

1. Internet Explorer / Edge: the same cnonce is used for all requests in a single auth session. It kind of defeating the purpose of having cnonce, but the behavior is compliant with RFC;

2. Mozilla firefox behaves similar to Chrome. And they are aware of this  bug 14 (!) years ago, see: https://bugzilla.mozilla.org/show_bug.cgi?id=270447

From the general discussion of that thread, I get the feeling that backward compatibility is probably not a problem -- maybe nobody is actually using it anyway. This part of the protocol basically got no love and no attention from people... :(

Comment 8 by mmenke@chromium.org, Mar 14 2018

Labels: Network-Triaged
►

Sign in to add a comment