If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

SPNEGO uses an extra round trip on every connection compared to IE9

UNCONFIRMED
Unassigned

Status

()

Core
Networking
P5
normal
UNCONFIRMED
6 years ago
8 days ago

People

(Reporter: Daniel Holth, Unassigned)

Tracking

8 Branch
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-would-take][ntlm])

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Created attachment 599588 [details]
spnego.py

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0
Build ID: 20111104165243

Steps to reproduce:

The attached Python program runs on a Kerberized (linux) machine, takes a realm name EXAMPLE.ORG and a port number and does SPNEGO authentication on incoming connections.


Actual results:

Firefox (and Chrome) re-negotiate SPNEGO every single time, so there is a 401 and then a 200 on every page load. Internet Explorer remembers the Authenticate header for the session and sends a different, updated one on every request, saving one round trip per page load.


Expected results:

Firefox should remember the SPNEGO Authenticate header for the duration of the session.

I wonder if the strange NTLM per-connection authentication has been incorrectly re-implemented for SPNEGO?

Updated

4 years ago
Component: Untriaged → Networking
Product: Firefox → Core

Comment 1

3 years ago
We are experiencing the same behavior, each request gets a 401 response first. Can anybody confirm that this is the right behavior? It's mainly relevant for Intranets where SPNEGO is generally the first choice for SSO.

Comment 2

2 years ago
It is not the client which has to remember but the server has to store the GSS name of the client in the HTTP connection (persistent authentication). The server may do this.

Updated

2 years ago
Duplicate of this bug: 1179246

Comment 4

2 years ago
(In reply to Michael Osipov from comment #2)
> It is not the client which has to remember but the server has to store the
> GSS name of the client in the HTTP connection (persistent authentication).
> The server may do this.

You seem to be saying that the problem is the server, not the client.   However, if this is true why does the desired behavior of only one round-trip instead of two happen with IE, but not with Firefox?  Seems the client behavior matters.

Comment 5

2 years ago
(In reply to Ryan Slominski from comment #4)
> (In reply to Michael Osipov from comment #2)
> > It is not the client which has to remember but the server has to store the
> > GSS name of the client in the HTTP connection (persistent authentication).
> > The server may do this.
> 
> You seem to be saying that the problem is the server, not the client.  
> However, if this is true why does the desired behavior of only one
> round-trip instead of two happen with IE, but not with Firefox?  Seems the
> client behavior matters.

I did not say that there is a problem at all. It is solely the server's decision to persist the authentication information or not. The client simply reacts on a 401, no more no less. I have several authentication modules (in Java and C) which are either connection-legged or request-legged and both of them work fine with Firefox, Chrome, IE, curl.

As far as the Python script is concerned, it does request-legged authentication. Perfectly fine with Kerberos.

Unless I haven't seen a Fiddler capture or Wireshark pcap of the problem, I cannot confirm any erractic behavior here.

Btw, the IE will always authenticate when the server requests it to. I have used this for years from IE6 to IE11.
Whiteboard: [necko-would-take][ntlm]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.