143541 - SMTP via SSL via SOCKS fails to connect to server.

Status: VERIFIED FIXED

(MailNews Core :: Networking: SMTP, defect, P2)

Description

[Paul Bryan]

When "Outgoing Server (SMTP) Settings" has "Use secure connection (SSL)" set to
"When available" or "Always", and the browser is configured to use a SOCKS
proxy, Mozilla cannot connect to the SMTP server.

When the SOCKS proxy is disabled in Mozilla, or when "Use secure connection
(SSL)" is set to "Never", Mozilla can successfully connect to the SMTP server.
In the former case, it successfully negotiates STARTTLS and sends the message
via SSL.

This issue occurs regardless of whether a valid CA-signed certificate is
installed, or if a self-signed certificate is used. In case this information is
useful, I also have "Use name and password" enabled, therefore using ESMTP AUTH. 

This behavior is consistently reproducable with Mozilla 1.0RC1, with Postfix
1.1.4 with SASL and TLS enabled (Debian packages: postfix-1.1.4-2,
postfix-tls-1.1.4+tls0.7.15-2).

Feel free to contact me if you would like me to assist in reproducing the
problem, or to test any proposed patches.

Comment 1

[Bradley Baetz (:bbaetz)]

Dupe of bug 133434, should be fixed in rc2.

*** This bug has been marked as a duplicate of 133434 ***

Comment 2

[John G. Myers]

Not a duplicate. Reopening.

This would appear to be an interaction between the SOCKS layer and the TLS
layer.  Perhaps they've been inserted in the wrong order?

Reporter, does "When available" work with SOCKS and an SMTP server that doesn't
support STARTTLS?

Comment 3

[Paul Bryan]

"When available" exhibits the same behavior as "Always" regardless of whether or
not the SMTP server supports STARTTLS -- I have tried with both an SMTP server
that does and one that doesn't.

I ran a packet sniffer on the SOCKS proxy, and it appears that Mozilla is
attempting to negotiate SSL immediately, rather than sending a STARTTLS message
in cleartext beforehand.

I'm asking this because the sniffer shows the following outgoing byte stream,
immediately when the connection is made to the SMTP server on port 25 ...

0000000 0316 0001 015d 0000 0359 0001 a331 a2ee
0000010 c63c f73d 3e17 dbec 9b79 d8c8 69cb 63cc
0000020 bbc7 5d35 2bd0 6845 2c48 2000 4d92 e771
0000030 a5a8 80be 4b6b f36b 059d 8f8e 2993 f149
0000040 9a82 bbd1 16a2 ddc1 1f84 8a8c 1200 0400
0000050 fffe 0a00 fefe 0900 6400 6200 0300 0600
0000060 0001                                   

... while the incoming byte stream is the same everytime ...

220 [servername] ESMTP [message]
502 Error: command not implemented

Is it possible SSL is being inserted in the wrong place in the stack when SOCKS
happens to be enabled?

Anything more I can do to help reproduce and track this, please don't hesitate
to ask.

Comment 4

[Paul Bryan]

Apologies, the hex dump I gave you was in little endian, which can be misleading
while interpreting a stream. Allow me to repost the output stream in a more
appropriate format:

00000000  16 03 01 00 5d 01 00 00  59 03 01 00 31 a3 ee a2  |....]...Y...1...|
00000010  3c c6 3d f7 17 3e ec db  79 9b c8 d8 cb 69 cc 63  |<.=..>..y....i.c|
00000020  c7 bb 35 5d d0 2b 45 68  48 2c 00 20 92 4d 71 e7  |..5].+EhH,. .Mq.|
00000030  a8 a5 be 80 6b 4b 6b f3  9d 05 8e 8f 93 29 49 f1  |....kKk......)I.|
00000040  82 9a d1 bb a2 16 c1 dd  84 1f 8c 8a 00 12 00 04  |................|
00000050  fe ff 00 0a fe fe 00 09  00 64 00 62 00 03 00 06  |.........d.b....|
00000060  01 00                                             |..|

Comment 5

[Bradley Baetz (:bbaetz)]

*** Bug 144246 has been marked as a duplicate of this bug. ***

Comment 6

[John G. Myers]

I suspect the code in netwerk/base/src/nsSocketTrancport.cpp around line 971
where it steps up SSL on a SOCKS connect is doing so (incorrectly) in the case
of tlsstepup.  It is checking for a nonzero mSecurityInfo when it should instead
be checking for some socket layer of type "ssl".

This code was last touched by darin, assigning to him.  This is a netwerk bug,
not mailnews specific (except only SMTP currently uses tlsstepup sockets).

Comment 7

[Darin Fisher]

benc: do we have a way to exercise this bug in house?

Comment 8

[Darin Fisher]

-> 1.2alpha

Comment 9

[Darin Fisher]

mSecurityInfo is only assigned a non-null value if we are doing "ssl" or
"starttls" ... and proxyTransparent is only set to TRUE if doing "socks" or
"socks4" ... is the problem therefore that we should only call ProxyStartSSL if
"starttls" is the socket type and not when the socket type is actually "ssl"?

if only i had a way to actually test this myself.

Comment 10

[John G. Myers]

It's the other way around.  We should call ProxyStartSSL only in the case where
the type is "ssl".

Comment 11

[Darin Fisher]

oh ic, because in the starttls case, the application layer above
nsSocketTransport has said that it will call ProxyStartSSL.  so, NSS doesn't
automatically start SSL when an SSL socket is layered on top of a SOCKS socket?
 it seems wierd to me to make consumers do this manually.  or, am i missing
something??

Comment 12

[Darin Fisher]

nevermind, after reading through some more of the code, i think ic how it is
supposed to work.  patch coming up.. hopefully, someone cc'd on this bug will be
able to test it out and let me know if it does the trick.

Comment 13

[Darin Fisher]

Attachment: v1 patch

ok, here's the patch according to how i understand the problem.  of course,
since i'm unable to test this myself, i'm going to need someone to verify this
solution.  thx!!

Comment 14

[Darin Fisher]

Comment on attachment 97458 [details] [diff] [review]
v1 patch

[e-mail] emailed me to tell me that this patch doesn't work :(

Comment 15

[Darin Fisher]

whoops.. i meant: [e-mail] emailed me with results indicating that the
patch didn't help.  sorry for the mixup! ;-)

Comment 16

[Darin Fisher]

i'm not going to have time to investigate this further before moz 1.2 alpha it
seems :(

Comment 17

[Darin Fisher]

Attachment: v2 patch

jgmyers was right about the problem.  my first attempt at writing up the patch
was simply flawed.  this patch gets it right.  (such a trivial bug... the
hardest part was just locating a SOCKS proxy!)

Comment 18

[Doug Turner (:dougt)]

Comment on attachment 98202 [details] [diff] [review]
v2 patch

r=dougt

Comment 19

[rpotts (gone)]

Comment on attachment 98202 [details] [diff] [review]
v2 patch

sr=[e-mail]

Comment 20

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 98202 [details] [diff] [review]
v2 patch

a=[e-mail] for trunk and 1.0 branch.  Please change mozilla1.0.2+ to
fixed1.0.2 when checked into 1.0 branch.

Comment 21

[Darin Fisher]

fixed-on-trunk

waiting for 1.0 branch to open before landing there.

Comment 22

[Darin Fisher]

fixed1.0.2

Comment 23

[[e-mail] (gone - use [e-mail] instead)]

I've tested with Netscape Messaging Server 4.15 Patch 4 as my SMTP server, with
SSL running on port 993, and Ben Chuang's SOCKS Proxy V5 test server enabled for
my proxy.

Builds:

Mac OS X 10.1.5 / Mac OS 9.2 - 2002-09-10-08
Windows 2000 - 2002-09-10-08
RedHat Linux 7.3 - 2002-09-10-08

Paul Bryan, I'm verifying this based on my own test experience, but if you have
confirmation or there is a particular configuration not working on your end,
please do re-open the bug and let us know, thanks.

Verified FIXED

Comment 24

[I-Gene Leong]

Verified using 2002-09-10-08 on Win2K connecting to Exim 3.35. No idea what
proxy I'm running through since it's my company's proxy.

Comment 25

[Paul Bryan]

Verified using Mozilla 1.2a on a Linux x86 system, connecting to Postfix 1.1.11
via TLS (SSL) over SOCKS4 provided by OpenSSH 3.4p1. Great work guys! Thanks!

Comment 26

[[e-mail] (gone - use [e-mail] instead)]

This is VERIFIED FIXED with the branch 2002-09-19 builds on:

Mac OS X 10.1.5 / Mac OS 9.2.2
Windows 2000
RedHat Linux 7.3