SSL Session Reuse Negotiation Is Single-Threaded



Core Graveyard
Security: UI
15 years ago
a year ago


(Reporter: Doug Dillon, Assigned: kaie)


Other Branch
Windows XP

Firefox Tracking Flags

(Not tracked)




(1 attachment)



15 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Build Identifier: Mozilla 1.2b

    I'm hoping to optimize Mozilla so that it has
faster secure web page response time over broadband satellite
connections than IE.

    Today I analyzed some ethernet traces of Mozilla retrieving
a simple web page with multiple embedded images.

    The trace started out as I expected:
    1 - after an SSL connection is established and the
HTML is retrieved Mozilla opens additional TCP connections to
retrieve the embedded images.
    2 - The TCP connection establishment completes as expected.

    3 - Mozilla would only perform a single SSL session reuse
negotiation with the server at a time!
    4 - As a result, the image retrieval proceeded one image at
a time!!!

    This is obviously really bad for web page response time
when you are on a long-latency link such as a geosynchronous satellite

Reproducible: Always

Steps to Reproduce:
0. Configure your browser for multiple simultaneous connections and keep
alive connections (e.g. 16).
1. Setup a sniffer to monitor the HTTPS TCP secure packets.
2. Go to a secure web page with multiple embedded images.
3. Observe that multiple TCP connections for the embedded images are
immediately established in parallel, but that the SSL Session Reuse negotiation
takes place one TCP connection at a time. 

Actual Results:  
The web page response time was twice as long as with Internet Explorer. 

Expected Results:  
It should have performed the SSL Session Reuse negotiation for each of the
sessions in parallel. 

I'm willing to fix this bug myself if someone can give me some pointers.

Comment 1

15 years ago
Marking NEW because of the analysis and willing to help. Darin will know for sure.
Ever confirmed: true

Comment 2

15 years ago
Created attachment 107029 [details]
.CSV format etherpeek trace of the problem with comments

Here's an etherpeek trace which I have imported into Excel and
have commented upon. This is probably the easiest way to see this problem.

Email me if you want the trace in sniffer or some other format.

Comment 3

15 years ago
-> PSM
Assignee: darin → ssaux
Component: Networking: HTTP → Client Library
Product: Browser → PSM
QA Contact: httpqa → junruh
Version: Trunk → unspecified

Comment 4

15 years ago
Bug 164258 may be related - SSL Session reuse does not work with smart cards.
Assignee: ssaux → kaie

Comment 5

15 years ago
Kai Engbert and Nelson Bolyard indicate that this could be a duplicate of:

which has been recently fixed in a build after the 1.2beta 2002101612 that
I was running when I found this. I'm trying to learn how to get and install
the latest build to confirm/disprove their hypothesis, but am a newbie and
am stuck. Will let you know if I make any progress. 

Comment 6

15 years ago
Ok, I downloaded a recent build(Mozilla 1.2 20021121) and 
tried out my favorite test secure web page

This page has three small javascripts,
followed by 17 small (e.g. 4KB) images. 

It did allow the multiple SSL connections to proceed in parallel.
That's good, I guess you should close this bug. 

BUT... one of the 17 images didn't paint. Looking at the trace I see Mozilla
resetting the TCP connection as soon as it gets a SYN ACK from the server.

This is occurring while max-persistent-connections is set to 32 and
max-persistent-connections-per-server is set to 7 or higher. When
max-persistent-connections-per-server is 6 or lower all the images paint. 
A reload does paint the image. 

It appears to only occur when my satellite hookup is used.
It doesn't happen when accessing the page via T3 from my desktop. 

Think I should turn in a new bug on this thing? I'm guessing
you'll want more proof it is a real problem prior to doing anything
about it since it only happens via satellite. 


Comment 7

15 years ago
One more thing about this "new" problem I see.
Its always the "last" connection which is being established which
is reset. So, if max-persistent-connections-per-server is set to 16, then
the connection that is reset is the 16th connection whose appears on the
sniffer trace. 

Does that clue ring a bell?
I'm marking this bug as a duplicate of 163605 since the fix for that bug
apparently also fixed this one.

Dillon, please submit another bug about the other issue.  Please test to
see if it also occurs on ordinary http pages.  If so, then it's not 
related to PSM.  

*** This bug has been marked as a duplicate of 163605 ***
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE

Comment 9

15 years ago
Verified dupe.


13 years ago
Component: Security: UI → Security: UI
Product: PSM → Core
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.