181292 - SSL Session Reuse Negotiation Is Single-Threaded

Status: VERIFIED DUPLICATE of bug 163605

(Core Graveyard :: Security: UI, defect)

Description

[Doug Dillon]

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.

    BUT THEN I WAS STUNNED TO DISCOVER:
    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
link.


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

[Olivier Cahagne]

Marking NEW because of the analysis and willing to help. Darin will know for sure.

Comment 2

[Doug Dillon]

Attachment: .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

[Darin Fisher]

-> PSM

Comment 4

[John Unruh]

Bug 164258 may be related - SSL Session reuse does not work with smart cards.

Comment 5

[Doug Dillon]

Kai Engbert and Nelson Bolyard indicate that this could be a duplicate of:
http://bugzilla.mozilla.org/show_bug.cgi?id=163605

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

[Doug Dillon]

Ok, I downloaded a recent build(Mozilla 1.2 20021121) and 
tried out my favorite test secure web page
"https://hnsacs2.direcpc.com/xpage/fullpage.htm". 

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. 

Doug.........

Comment 7

[Doug Dillon]

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?

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

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 ***

Comment 9

[John Unruh]

Verified dupe.