Closed Bug 85304 Opened 23 years ago Closed 23 years ago

TLS support broken in mozilla

Categories

(Core Graveyard :: Security: UI, defect, P1)

1.0 Branch
x86
Windows 2000
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: mscott, Assigned: javi)

References

Details

Attachments

(2 files)

Sometime within the last week or so the TSL socket provided by PSM broke. This
prevents users from sending mail using SSL (which is currently the default in
mailnews so we are getting tons of complaints about this because people can't
send their email). 

Necko is properly invoking the TSL socket. However, we never receive an
OnStartRequest from the tsl socket. 

Also, it appears that mozilla is incapable of any networking activity after we
create a TLS socket. Something is causing everything to get blocked. Seems
strange that psm could cause the necko threads to block.
Adding appropriate keywords
Severity: normal → blocker
Keywords: nsbeta1
Priority: -- → P1
Is this happening on the branch or trunk builds?
trunk only. 
Adding Javi to cc-list.

Javi,

Is there any chance that your TLS fix may be causing this problem on the trunk?
Someone remind me how to modify my SMTP SSL settings.  I can't find it in the
UI.
Edit / Mail And News Settings.

Then click on Outgoing Server. 
Check the radio button for "Try SSL when available"

thanks for looking into this javi. 
Here's what I'm seeing:

nsSSLIOLayerNewSocket gets called with the argument to set up a TLS socket. 
After I return from that function, neither nsSSLIOLayerWrite nor
nsNSSSocketInfo::TLSStepUp get called.  

These are supposed to get called, right?
Keywords: mailtrack
I'm not sure whose supposed to call nsNSSSocketInfo::TLSStepUp
but from the smtp protocol's point of view, we never try to right anything to
the socket until necko proxies a OnStartRequest to us. This lets us know that
the connection has been established. 
This is caused by my patch to dumb down SSL connections if the handshake fails
after a connect when SSL v3.1 is enabled.  Some thread blocks on a read because
I left the socket in blocking mode after a connect.

I'm working on a patch to not leave the socket in blocking mode after a connect.
Assignee: ddrinan → javi
good catch Javi! I was just about to say that it looks like the regression
happended the same day 64888 was fixed (June 7th). 

Let me know if you still need me to call you to work this out. I can also test
any patches you've got for us. 
mscott: The patch worked for me.  Could you guys beat on it a little more to
make sure it works for you guys as well.

Thanks.
it works like a champ for me!
Attached patch Updated patch.Splinter Review
wtc, please review my latest patch.  Thanks.
*** Bug 85584 has been marked as a duplicate of this bug. ***
*** Bug 85598 has been marked as a duplicate of this bug. ***
sr=blizzard
*** Bug 85618 has been marked as a duplicate of this bug. ***
*** Bug 85607 has been marked as a duplicate of this bug. ***
*** Bug 82970 has been marked as a duplicate of this bug. ***
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)
Blocks: 83989
Fix checked in.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 85816 has been marked as a duplicate of this bug. ***
*** Bug 85892 has been marked as a duplicate of this bug. ***
Verified on WinNT and Linux.
Status: RESOLVED → VERIFIED
*** Bug 85970 has been marked as a duplicate of this bug. ***
Fixed for me on Win 98 - you guys are good!
*** Bug 86648 has been marked as a duplicate of this bug. ***
*** Bug 85338 has been marked as a duplicate of this bug. ***
*** Bug 86675 has been marked as a duplicate of this bug. ***
Product: PSM → Core
Version: psm1.01 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: