Do not ask for username when using Negotiate/SPNEGO
Categories
(Core :: Networking, defect)
Tracking
()
People
(Reporter: dpa-mozilla, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0 Safari/605.1.15 Epiphany/605.1.15
Steps to reproduce:
As discussed at https://bugzilla.mozilla.org/show_bug.cgi?id=1583145 under Windows I set network.auth.use-sspi to false and network.negotiate-auth.trusted-uris to aegee.org . With MIT Kerberos for Windows I obtain a ticket for user(principal) aaa@AEGEE.ORG with password abc. Then I visit
https://mail.aegee.org/dav/calendars/user/aaa
Firefox asks for username/passwort, but if the dialog is closed with Cancel, the authentication completes with Negotiate/SPNEGO . On subsequent requests the username/password dialog is not shown.
Firefox likely tries to use Basic authentication, when first visiting the site, as the server returns then
401 Unauthenticated
WWW-Authenticate: Basic
WWW-Authenticate: Negotate
but if Firefox can do Negtiate/SPNEGO and does it, then Firefox shall not ask for user name.
Expected results:
Compare to
echo abc|kinit aaa@AEGEE.ORG
curl -v --negotiate -u: https://mail.aegee.org/dav/calendars/user/aaa
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 144.76.142.78:443...
- TCP_NODELAY set
- Connected to mail.aegee.org (144.76.142.78) port 443 (#0)
- ALPN, offering h2
- ALPN, offering http/1.1
- successfully set certificate verify locations:
- CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: none
} [5 bytes data] - TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data] - TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data] - TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [19 bytes data] - TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [3028 bytes data] - TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [520 bytes data] - TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data] - TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data] - TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data] - SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
- ALPN, server accepted to use h2
- Server certificate:
- subject: CN=lists.aegee.org
- start date: Aug 18 16:57:03 2019 GMT
- expire date: Nov 16 16:57:03 2019 GMT
- subjectAltName: host "mail.aegee.org" matched cert's "mail.aegee.org"
- issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
- SSL certificate verify ok.
- Using HTTP2, server supports multi-use
- Connection state changed (HTTP/2 confirmed)
- Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
} [5 bytes data] - Server auth using Negotiate with user ''
- Using Stream ID: 1 (easy handle 0x11b9c10)
} [5 bytes data]
GET /dav/calendars/user/aaa HTTP/2
Host: mail.aegee.org
Authorization: Negotiate YIICcwYGKwYBBQUCoIICZzCCAmOgDTALBgkqhkiG9xIBAgKiggJQBIICTGCCAkgGCSqGSIb3EgECAgEAboICNzCCAjOgAwIBBaEDAgEOogcDBQAgAAAAo4IBT2GCAUswggFHoAMCAQWhCxsJQUVHRUUuT1JHoiEwH6ADAgEDoRgwFhsESFRUUBsObWFpbC5hZWdlZS5vcmejggEOMIIBCqADAgESoQMCAQWigf0Egfovwzw1X21UPq3RwrEh57heachzN1K4/n9O6YjjUasyV844uofJAsyyDbd2eCGLdKL/cUASLqFWbZMEd/kPvO8Xezdk1u0s/7AMKx72ex3EyePozHF6GwP1TeYKC0bYrVQHztnH+cEz36N5Ue9vrxgx/UW5qolOF+9SGmFmHu4T2px7LDPgVkktnZoFNiY/p0b4Vw0ZJd/KcnnUiTCCgywu+3Qrj/CgHrxX4tDPKXWMtbBFBPks2Zve+tLVfTfeTMMlbBtu8zCbI3gfWikB9G+m2aoy7xjC76hEapxKqdfo3aYhXVSpttEvLnZBFXR4e8p06d9gk5CjhRL0pIHKMIHHoAMCARKigb8EgbwrfeyXKmo5xDC6l/TRGppFFcdyhyVwWZy+4QeAjJ1kKuP1+bvE1iXz5NfxRaR+H2tubivJgMdKKqGEf9z4b02GshRbOG/rVviake7j0smBZ50keJKFajXdoyZ252MZYxieG1pLhRYsWIgrW8y7uhefx+ZxQ2D470f0jDYorIO8idVjLdjjAOEZMaQ1XTi45EegioHvVZQ/Wt2SOwvL4fnTOw1RsxPaEZvyDPosNhTpb917Vy7UB0xBERDrBQ==
User-Agent: curl/7.66.0
Accept: /
{ [5 bytes data]
- TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [265 bytes data] - TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [265 bytes data] - old SSL session ID is stale, removing
{ [5 bytes data] - Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
} [5 bytes data]
< HTTP/2 200
< server: nginx
< date: Mon, 23 Sep 2019 14:59:41 GMT
< content-type: text/html; charset=utf-8
< cache-control: must-revalidate
< vary: Accept-Encoding
< www-authenticate: Negotiate oYG3MIG0oAMKAQChCwYJKoZIhvcSAQICooGfBIGcYIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKicQRveyJBk0DAb+wOBfRAETVC1JanTyhObXkEIRGGMBraekcNKEGTxsrlhCIxN6DHFL2LeuTBxemNn+b5drsdsdj+h70OzQrgAjt5CvduaZwDxPs0SGb/ASCt8GVyfdZ+xnfZRtPKrtTjUSicpM2Dzys1
< accept-ranges: none
< etag: "1569229098-1569227119-229664-1555082957-578"
< last-modified: Mon, 23 Sep 2019 08:58:18 GMT
<
{ [15951 bytes data]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html><head><title>Available
-HTML output cut for simplicity-
|
||
Comment 1•6 years ago
|
||
I'm guessing that Core::Networking is the better component.
|
||
Comment 2•6 years ago
|
||
Looks like it's an expected behavior. Isn't it?
|
Reporter | |
Comment 3•6 years ago
|
||
When WWW-Authenticate: Basic is sent, the expected behaviour is to ask the user for credentials.
When WWW-Authenticate: Negotiate is sent the expected behaviour is not to ask the user for credentials, but to obtain these using the ticket granting ticket.
When both WWW-Authenticate: Basic and WWW-Authenticate: Negotiate are sent, asking the user questions (e.g. about credentials), whose answers Firefox can find itself only bothers the user unnecessary.
|
|
||
Comment 4•6 years ago
|
||
Note that we process the challenges in the order the servers sends them.
|
|
Reporter | |
Comment 5•6 years ago
|
||
I will change the order of advertized schemas and let you know, if this does not help.
https://tools.ietf.org/html/rfc7235#section-4.1 premits advertizing Digest and Basic at the same time. How does Firefor try Basic, if Digest fails? Does it ask again for username/password?
https://github.com/ifad/spnego-http-auth-nginx-module/blob/master/README.md says about implementing SPNEGO in Nginx:
“Basic authentication fallback
The module falls back to basic authentication by default if no negotiation is attempted by the client. ”
My reading of that text is, that that module returns “WWW-Authenticate: Basic”, if the client does not do unsolicit “Authorize: Negotiate”.
At https://bugzilla.mozilla.org/show_bug.cgi?id=1581321 I asked to permit for TB-Addons to tell the http-engine whether it must or must not authenticate to the server, before receiving 401 Unauthorized and which authentication schemas the http server supports.
|
|
Reporter | |
Comment 6•6 years ago
|
||
Just for the record, per https://www.chromium.org/developers/design-documents/http-authentication, Chromium prefers Negotiate over Basic, the advertizing order is irrelevant.
|
|
||
Comment 7•6 years ago
|
||
(In reply to Дилян Палаузов from comment #5)
I will change the order of advertized schemas and let you know, if this does not help.
https://tools.ietf.org/html/rfc7235#section-4.1 premits advertizing Digest and Basic at the same time.
Sure and we handle that.
How does Firefor try Basic, if Digest fails? Does it ask again for username/password?
Yes.
https://github.com/ifad/spnego-http-auth-nginx-module/blob/master/README.md says about implementing SPNEGO in Nginx:
“Basic authentication fallback
The module falls back to basic authentication by default if no negotiation is attempted by the client. ”My reading of that text is, that that module returns “WWW-Authenticate: Basic”, if the client does not do unsolicit “Authorize: Negotiate”.
The server can send WWW-Authenticate at will and we will (try to our best) handle them.
At https://bugzilla.mozilla.org/show_bug.cgi?id=1581321 I asked to permit for TB-Addons to tell the http-engine whether it must or must not authenticate to the server, before receiving 401 Unauthorized and which authentication schemas the http server supports.
I'll look at that bug sometimes later.
(In reply to Дилян Палаузов from comment #6)
Just for the record, per https://www.chromium.org/developers/design-documents/http-authentication, Chromium prefers Negotiate over Basic, the advertizing order is irrelevant.
Thanks for referencing this!
keeping ni?me to look at this more in depth.
|
|
Reporter | |
Comment 8•6 years ago
|
||
https://www.anciens.org/dav/calendars/user/aaa offers Digest and Basic authentication. Digest always fails and Basic works with username aaa and password abc. I cannot login with Firefox 68.1.1 on Android, after entering the password several times, so Firefox does not fall back to Basic, if Digest fails, as suggested above. Moreover, if I chose Cancel (for Digest and realm mail.aegee.org), Firefox does not ask for realm AEGEE.ORG (coming from Basic).
curl --digest -uaaa:abc -D- https://www.anciens.org/dav/calendars/user/aaa FAILS
curl --basic -uaaa:abc -D- https://www.anciens.org/dav/calendars/user/aaa WORKS
Note that the former command returns:
www-authenticate: Digest nonce="EGQcjnqiUtzd7+myLugmzmpHnwgyI15yTHWsKPrDs1A=",realm="mail.aegee.org",qop="auth",charset=utf-8,algorithm=md5-sess
www-authenticate: Basic realm="AEGEE.ORG"
and when prompting for password, Firefox asks for mail.aegee.org and not for AEGEE.ORG
https://www.chromium.org/developers/design-documents/http-authentication says also “Note: In IE7 or later, WinInet chooses the first non-Basic method it recognizes.”.
|
|
Reporter | |
Comment 9•6 years ago
|
||
When the server sends
WWW-Authenticate: Negotiate
WWW-Authenticate: Basic
in this order, FIrefox indeed does not ask the user for password and goes with SPNEGO.
But when the server offers:
WWW-Authenticate: Digest
WWW-Authenticate: Basic
and Digest is not implemented properly by the server, Firefox does not switch to Basic.
So when does Firefox fall back and when not? In particular, if Negotiate is not performed (or fails), will it switch to Basic, but why it does not switch to Basic, when Digest fails?
|
|
||
Comment 10•6 years ago
|
||
OK, then this is a duplicate of bug 650091 which I believe can resolve now based on your comment 8! We should follow what chrome does (maybe add a preference to drop back to respect server given order).
Thanks!
Description
•