201232 - SSL fragment size workaround

Status: RESOLVED WONTFIX

(NSS :: Libraries, enhancement, P3)

Description

[Ian McGreer]

This was reported on a newsgroup:

Date: Wed, 26 Mar 2003 12:32:00 -0800 (PST)
From: Mark Crispin <[e-mail]>
To: bill hunter <[e-mail]>
Newsgroups: comp.mail.pine
Subject: Re: incomplete SecBuffer exceeds maximum buffer size

On Wed, 26 Mar 2003, bill hunter wrote:

> I get this message when connecting to a Sun server running iPlanet
> Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003).


Sounds like you need to file a bug report on the iPlanet Messaging server.
It is not safe to use full-sized (16K) SSL payloads when talking to a
Microsoft SSL implementation.  This is due to a longstanding bug in
Microsoft SSL which limits the maximum payload to 16K - 5 bytes.

Microsoft has known about this bug for years.  Much to my extreme
annoyance, it was not fixed in WinXP SP1, although some Win2K systems now
have the fix.

Many implementations use 8K payloads in order to keep the payload size a
power of 2.  That may not necessarily matter.

> I am using PCPine 4.53 on WindowsXP Home, and have selected the pinerc
> option that says it will quell this issue.


It doesn't quell the problem completely.  It just causes PC Pine to avoid
doing things that are likely to provoke the server into causing the
problem.  That doesn't mean that the server won't do it anyway for some
other reason.

> I am aware of the faq (http://www.washington.edu/imap/IMAP-FAQs/#7.43),
> but do not see any obvious way of solving this on the imap server side.


Get whomever maintains the iPlanet Messaging server to limit the SSL
payloads to a smaller value.  It's not their bug, but until Microsoft
fixes its bug we all have to work around it.

Microsoft should be embarassed that this has gone on for so long.  This
bug doesn't just break client software such as PC Pine, but it also breaks
their own Exchange server!

-- Mark --
-----

Comment 1

[Ian McGreer]

I verified that our code can send up to 16K fragments (see MAX_FRAGMENT_LENGTH).
 I haven't verified the MS bug, for now I'm assuming the report is reliable.

Do we want to implement some kind of workaround for this in NSS?

Comment 2

[Ian McGreer]

OK, I seem to have the relevant MS bug.  See URL field above.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

I, for one, advocate defending the standard.  
Let's keep the pressure on non-conformant implementations to get them fixed.
Let's not let them redefine the standard, and remove from them any motivation
to fix their bugs.  That's my vote.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

taking bug

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

According to http://www.washington.edu/imap/IMAP-FAQs/#7.43 Pine uses 
Microsoft's SChannel DLL to do SSL, and it reportedly causes Pine to crash.  
Most users have a choice of email client but do not have a choice of IMAPS
server.  Mozilla has an IMAPS client that works well with standards compliant
servers. Is this seen as hurting sales of any IMAPS server?
In any case, this is not a bug in NSS.  

I guess we could "enhance" libSSL to give it another settable SSL socket 
"option" which is the maximum outgoing SSL3/TLS "fragment" size.  It would 
default to 16K.  That way, a server product that wants to accomodate 
non-compliant clients could choose to do so.  
Is that what should be done?  

Comment 6

[Ian McGreer]

Looking back at the email thread I filed the bug from, it seems a workaround was
developed in the server, and having a workaround at the NSS level was deemed not
to be an urgent matter.  I think it is appropriate to mark this bug as WONTFIX,
and if someone comes along and asks for the NSS workaround you suggest (which I
agree would be the right approach), we can reopen it.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

What workaround was implemented?  

The only workaround I can imagine is one that limits the size of each PR_Write 
and PR_Send to less than 16K.  I think that would also necessitate eliminating 
use or PR_SendFile and PR_TransmitFile, at least on some platforms.