Cannot reach TLS intolerant servers through SSL proxy.

VERIFIED FIXED in psm2.2

Status

Core Graveyard
Security: UI
P1
major
VERIFIED FIXED
17 years ago
a year ago

People

(Reporter: John Unruh, Assigned: kaie)

Tracking

({relnote})

1.0 Branch
psm2.2
x86
Windows NT
relnote
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt2 RTM] [ETA 06/26], URL)

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

17 years ago
1.) Set SSL proxy to junruh.mcom.com:8080 (AOL in-house)
2.) Visit a TLS intolerant site like https://comhome.comdirect.de/ or 
https://www.gwla.com or https://www.macys.com/

What is expected: A successful connection.
What I get: <html><body></body></html>

Comment 1

17 years ago
setting:
Target -> 2.0
-> javi
P2
Assignee: ssaux → javi
Severity: normal → major
Priority: -- → P2
Target Milestone: --- → 2.0

Comment 2

17 years ago
-> nsbranch

Many users surf via a proxy.  It's important to fix this bug. 

Keywords: nsBranch

Updated

17 years ago
Whiteboard: PDT; want plus

Comment 3

17 years ago
-> ddrinan
Assignee: javi → ddrinan

Updated

17 years ago
Whiteboard: PDT; want plus → PDT+ want plus

Comment 4

17 years ago
Created attachment 40372 [details] [diff] [review]
Patch to work around TLS/proxy issue.

Comment 5

17 years ago
At the PSM layer we cannot re-establish a proxied connection because we do not
know how to build up a proxied connection from scratch (which is what the
fallback method tries to do).  What we really need is to set some error code,
then have necko recognize that error and re-try the connection from scratch
telling us to not use TLS.

Since that would require major surgery, the proposed patch would be preferable
IMO.  When creating an SSL socket, it will check to see if we are going to
connect through a proxy, and if so it will turn off TLS for that connection. 
This is much lower risk and allows us to ship TLS as the default for non-proxied
users.

Comment 6

17 years ago
marek moved this from PDT to PDT+
Whiteboard: PDT+ want plus → PDT+

Comment 7

17 years ago
adding relnote keyword in case we need to release note it (likely I think).
Keywords: relnote

Comment 8

17 years ago
The release notes should say something like this, though someone should feel
free to re-write it.  Maybe it should be joined with the "TLS intolerant server"
section.

When you have selected the "Enable TLS" option from the SSL preferences panel,
the browser will attempt to use the TLS protocol when making secure connections
with a server. If that connection fails because the server is "TLS intolerent",
 the client will fall back to using SSL3.   There is an important exception:  If
you have selected to use a proxy for secure connections, the browser will not
attempt to use TLS.  It will attempt to use SSL3. 

Comment 9

17 years ago
r=ddrinan.

Comment 10

17 years ago
Adding blizzard to cc-list.

Chris,
Please super-review.
sr=brendan@mozilla.org, but please file a sequel bug (or leave this bug open and
retarget-milestone it) for the fix javi described: propagate a distinct result
code to necko and redo the proxied connection without TLS.

/be

Comment 12

17 years ago
New bug filed.

Updated

17 years ago
Whiteboard: PDT+ → PDT+, need a=

Comment 14

17 years ago
a= asa@mozilla.org for checkin to 0.9.2 branch.
(on behalf of drivers)

Comment 15

17 years ago
Checked into branch and trunk. Marking FIXED.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Updated

17 years ago
Whiteboard: PDT+, need a= → PDT+
(Reporter)

Comment 16

17 years ago
Verified.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 17

16 years ago
Reopening. 11/30 trunk Win2000 build. Use in-house proxy server 
lab212sun.mcom.com:8080.
I cannot reach TLS intolerant server https://www.delphion.com at all.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

Comment 18

16 years ago
->rangnasen for investigation.
Assignee: ddrinan → rangansen
Status: REOPENED → NEW
Priority: P2 → P1
Target Milestone: 2.0 → 2.2

Comment 19

16 years ago
For me, both https://www.delphion.com and https://comhome.comdirect.de/ seems to
work ok - Trunk Build, Dec 1, evening, WinNT. One of the cases when this
infamous blank page shows up is when the server times out and disconects, which,
in my openion, might be the reason why it showed up in this case.
John - do you still see this problem?
(Reporter)

Comment 20

16 years ago
I cannot reach the TLS intolerant server https://www.delphion.com through a 
proxy with Win2000, Win98 or Mac OSX. https://comhome.comdirect.de/ does not 
appear to be TLS intolerant, and thus can be reached through a proxy.
(Reporter)

Comment 21

16 years ago
Relnote: When you have selected the "Enable TLS" option from the SSL preferences 
panel, the browser will attempt to use the TLS protocol when making secure 
connections with a server. If that connection fails because the server is "TLS 
intolerent", the client will fall back to using SSL3.   There is an important 
exception:  If you have selected to use a proxy for secure connections, the 
browser will not be able to reach a "TLS intolerent" web site.
(Reporter)

Comment 22

16 years ago
*** Bug 146270 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

16 years ago
Depends on: 149868
(Assignee)

Comment 23

16 years ago
The patch in bug 149868 seems to fix this bug.
(Assignee)

Comment 24

16 years ago
*** Bug 96024 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 25

16 years ago
Resolving as a duplicate, because I believe this is now fixed.
If you still can reproduce, please reopen.

*** This bug has been marked as a duplicate of 149868 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago16 years ago
No longer depends on: 149868
Resolution: --- → DUPLICATE

Comment 26

16 years ago
Using 2002061303-trunk/Mac OS 9.2 via Squid 2.3 STABLE5-NT,
I cannot reach https://raytheon.benefitcenter.com in Bug 146270,
and https://www.bank128.anser.or.jp/cgi/balance.aic?CCT0080=1559.

If I turn off "Enable TLS", these sites work.
It seems to me the patch is not enough.
Is this another problem ?
(Reporter)

Comment 27

16 years ago
Reopening, and confirming HARUNAGA's comment right above. Tested on 6/13 trunk 
Win2000 and Mac OSX. Something has improved here, the 3 sites mentioned 
originally now work, and the sites still appear to be TLS intolerant.
FYI: Raytheon is using this server - 
Axent_Technologies/WebDefender_SecureLink_Bridge/WebDefender_SecureLink_Bridge-2
.0
Bank128 is using this server - iTP Secure WebServer/2.1
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Assignee)

Comment 28

16 years ago
Taking bug.
Assignee: rangansen → kaie
Status: REOPENED → NEW
(Assignee)

Updated

16 years ago
Attachment #40372 - Attachment is obsolete: true
(Assignee)

Comment 29

16 years ago
Created attachment 88937 [details] [diff] [review]
Patch v2

I traced this phenomenon, using the servers described in the previous comment.
They both behave identically.

PSM layers itself into the network communication. When going over an proxy, SSL
is not immediately turned on. It gets turned on, as soon as the plaintext
protocol to the proxy is finished, and connection to the real server is
starting.

The TLS intolerant detection uses special logic for the first data write only.
Whether we have seen a data write yet is stored in flag mFirstWrite.

When the network code is about to ask PSM to turn on crypto, it calls a StepUp
function. Within that function, the socket options for encryption are switched
on, and the "mFirstWrite" flag is reset to true, with the intention to
indicate, that no data has been transfered yet.

However, this method also contains an additional action. It "writes zero bytes"
to the network connection. This is described as being a workaround for bug
56924. My understanding is, the intention is to trigger the start of the SSL
handshake immediately.

The problem is: The "write zero bytes" call is done before the mFirstWrite flag
is reset to true.

So what happens is:
- the SSL handshake gets triggered
- the network connection to the remote server is starting
- the first bytes get written, but PSM is not currently aware that it is seeing
the first write, because the flag is not set. Therefore the error code gets
handled incorrectly.
- next the flag gets that, but it is too late

I changed the code to change that order. I moved setting the mFirstWrite flag
before triggering the handshake by executing the zero bytes write.

Using that combination, I can successfully connect to all sites, with or
without proxy.

I was even able to connect to any site by removing that zero bytes write call
completely.

I think we were unable to see this solution earlier, because of bug 149868.
But now, this fix seems obvious to me.

I'm attaching a patch that reorders the code as I described. I think we should
start with that code now, and if it works on the trunk, we should also land it
on the trunk.

(In a future step, we should also remove that zero bytes write call completely
on the trunk - because the comment in the code says, the only reason for that
call was to work around a known problem in NSS, and to my understanding, that
problem has been fixed.)
(Assignee)

Comment 30

16 years ago
(One should reread comments before submitting, not after).

Typos:
 next the flag gets that, but it is too late
                     ^^^^
                         => set

I'm attaching a patch that reorders the code as I described. I think we should
start with that code now, and if it works on the trunk,
we should also land it on the trunk.
                              ^^^^^
                                   => 1.0 branch.
Status: NEW → ASSIGNED

Comment 31

16 years ago
Comment on attachment 88937 [details] [diff] [review]
Patch v2

r=javi
Attachment #88937 - Flags: review+

Comment 32

16 years ago
Comment on attachment 88937 [details] [diff] [review]
Patch v2

sr=darin (how did TLS intolerant server detection ever work before?  or was
this only a recent regression?)
Attachment #88937 - Flags: superreview+
(Assignee)

Comment 33

16 years ago
> how did TLS intolerant server detection ever work before?
> or was this only a recent regression?)

- what we are patching here is only the tls-intolerant-over-proxy code

- tls-intolerant without proxy has been already working

- tls-intolerant-over-proxy did not really work, as it could be seen in 96024,
for example. But in the end, the general case https-over-proxy did not work well
at all (as recently fixed with bug 149868). Before that, we weren't really able
to successfully understand and solve the special case tls-intolerant-over-proxy.

Short answer: tls-inteloerant-over-proxy probably never has been working reliably.

I hope this patch fixes our problems. I will now check it in to the trunk, and
we should do testing with many sites (only testing using proxy required).

(If for some reason, this simple patch is not the whole part of the solution, we
might again look at the attempt I started in the patches in bug 96024. Darin, we
already attempted to work on that in the past, but all are our attempts were
guaranteed to fail because of 149868.)
(Assignee)

Comment 34

16 years ago
Checked in to trunk.
Marking fixed, third attempt.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
(Reporter)

Comment 35

16 years ago
Verified on 6/25 Win2000 trunk. I tested the TLS intolerant sites listed in
tracking bug 59321 with the 6/24 trunk build, but all of the sites have
apparently upgraded their servers in the last year, and work with the 6/24 trunk
build through a proxy. I did find one server which is still TLS intolerant -
https://webmail.wittenberg.edu/. I cannot reach it with the 6/24 build, but can
with the 6/25 trunk build.
www.netcraft.com/sslwhats identifies the server as "unknown", and it is using
the cipher RC4 with MD5 (export version restricted to 40-bit key).

Comment 36

16 years ago
Marking this one as verified per Comment #35 From junruh@netscape.com.
Blocks: 143047
Keywords: adt1.0.1, nsbeta1+
Whiteboard: PDT+ → [adt2 RTM] [ETA 06/26]
(Reporter)

Comment 37

16 years ago
Marking verified on trunk.
Status: RESOLVED → VERIFIED

Comment 38

16 years ago
The powers that be, please review bug 155100 and possibly affirm whether the two
are distinctly related.

Thank you
(Assignee)

Comment 39

16 years ago
I think bug 155100 is an unrelated issue, because it seems to me that mail/news
does not use the SSL proxy config to connect to the server.

I finally followed the source to see, where the code is that determines whether
a proxy will be used for a given URL or not. I ended at:
  nsProtocolProxyService::ExamineForProxy

The SSL/HTTPS proxy config is never used for any mail/news protocol. It is only
used for https.

I think the proxy UI is confusing. The UI says "SSL proxy". This implies, it
would be used for any kind of SSL connection. But right now the UI would better
say "https proxy".

So for now, bug 155100 can not be related to this bug.

Comment 40

16 years ago
alternatively all ssl connections should use the proxy information.

Comment 41

16 years ago
adding adt1.0.1-.  Let's look at this for the next release.
Keywords: adt1.0.1 → adt1.0.1-
This has created a very nasty SSL-SMTP regression: trying to send mail via
SSL/SMTP hangs forever, and if you cancel, the rest of necko is subsequently
completely horked (see bug 155431).  Unless there's a good reason not to, I'd
like to back this out.

Comment 43

16 years ago
If it can wait till Kai can take a look I'd prefer that.
Otherwise, go ahead.
I'd argue for backing it out now, for two reasons:

1) the regression seems notably worse than what the patch was intended to fix:
not only is there a loss of connectivity, but necko is left in a non-working state.

2) the patch is so tiny, relanding it shouldn't be hard at all (ie there won't
be any cvs merge conflicts).
Backed out; reopening.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 46

16 years ago
Thanks for your help, Dan.
(Assignee)

Comment 47

16 years ago
I think we need to carefully revisit the current logic in PSM's SSL I/O layer.
My understanding is that some people saw the regression 155341 always, while
other's only saw it sometimes. This sounds like timing problems.

This matches what is being reported in bug 153769. The reporter complains about
a race condition in the same code. He suggested a workaround, which "works for
him". But I don't want to try out any more code. Before I make additional
changes, I want to completely understand what's going on.
(Assignee)

Comment 48

16 years ago
Created attachment 94549 [details] [diff] [review]
Patch v3
Attachment #88937 - Attachment is obsolete: true
(Assignee)

Comment 49

16 years ago
My previous attempt to fix this bug failed.
This time I don't want to break it again.


The new patch I just attached tries to fix all of the following:

- make TLS intolerant server detection over proxies work 
  (this bug 87902)
- on failure, only retry without tls when it is really 
  likely to help
  (bug 149910)
- show correct error messages if tls is disabled
- remove obsolete workarounds in SSL i/o layer
  (see removed comments in patch)
- avoid to confuse programmers reading code,
  by renaming TLSStepUp (which means something else)
  to the correct term STARTTLS (what the code is actually doing).
  (As suggested by Nelson)
- if an invalid or expired etc. server certificate is presented,
  a warning is shown. If the user decides to cancel,
  network activity should stop. (we currently warn multiple times)
  (bug 87209)

In order to reach confidence about my patch, I did a lot of testing.

I tested 100 different combinations of configuration and site.

- 20 on Linux without the patch, to document our current incorrect 
  behaviour (only configurations with proxy, as configuration without
  proxy seem to work).
  Note: SMTP/SSL is very similar to a proxy mode connection.

- 40 on Linux with the patch applied

- 40 on Windows with the patch applied

===================
Linux test results:
===================

site / enabled options:          | SSL2 | SSL2 | SSL2 |      |
                                 |      | SSL3 | SSL3 | SSL3 |  
                                 |      |      | TLS  | TLS  | TLS 
---------------------------------|------|------|------|------|-----
https://investing.schwab.com/    |1a    |1b    |1c    |1d    |1e     
no proxy                         | conn | conn | conn | warn | warn 
---------------------------------|------|------|------|------|-----
https://www.verisign.com/        |2a    |2b    |2c    |2d    |2e   
no proxy                         | conn | conn | conn | conn | warn
---------------------------------|------|------|------|------|-----
https://webmail.wittenberg.edu/  |3a    |3b    |3c    |3d    |3e   
no proxy                         | conn | conn | conn | conn | warn
---------------------------------|------|------|------|------|-----
https://www.kuix.de/links/       |4a    |4b    |4c    |4d    |4e   
no proxy                         | stop | stop | stop | stop | stop
---------------------------------|------|------|------|------|-----
https://investing.schwab.com/    |1f    |1g    |1h    |1i    |1j     
with SSL proxy                   | conn | conn | conn | warn | warn  
---------------------------------|------|------|------|------|-----
https://www.verisign.com/        |2f    |2g    |2h    |2i    |2j   
with SSL proxy                   | conn | conn | conn | conn | warn
---------------------------------|------|------|------|------|-----
https://webmail.wittenberg.edu/  |3f    |3g    |3h    |3i    |3j   
with SSL proxy                   | conn | conn | conn | conn | warn
---------------------------------|------|------|------|------|-----
https://www.kuix.de/links/       |4f    |4g    |4h    |4i    |4j   
with SSL proxy                   | stop | stop | stop | stop | stop
---------------------------------|------|------|------|------|-----
send mail                        |5a    |5b    |5c    |5d    |5e   
with SMTP/SSL when available     | fail | conn | conn | conn | conn
---------------------------------|------|------|------|------|-----
send mail                        |5f    |5g    |5h    |5i    |5j   
with SMTP/SSL always             | fail | conn | conn | conn | conn   
---------------------------------|------|------|------|------|-----


=====================
Windows test results:
=====================

site / enabled options:          | SSL2 | SSL2 | SSL2 |      |
                                 |      | SSL3 | SSL3 | SSL3 |
                                 |      |      | TLS  | TLS  | TLS
---------------------------------|------|------|------|------|-----
https://investing.schwab.com/    |1a    |1b    |1c    |1d    |1e
no proxy                         | conn | conn | conn | warn | warn
---------------------------------|------|------|------|------|-----
https://www.verisign.com/        |2a    |2b    |2c    |2d    |2e
no proxy                         | conn | conn | conn | conn | warn
---------------------------------|------|------|------|------|-----
https://webmail.wittenberg.edu/  |3a    |3b    |3c    |3d    |3e   
no proxy                         | conn | conn | conn | conn | warn
---------------------------------|------|------|------|------|-----
https://www.kuix.de/links/       |4a    |4b    |4c    |4d    |4e   
no proxy                         | stop | stop | stop | stop | stop
---------------------------------|------|------|------|------|-----
https://investing.schwab.com/    |1f    |1g    |1h    |1i    |1j
with SSL proxy                   | conn | conn | conn | warn | warn
---------------------------------|------|------|------|------|-----
https://www.verisign.com/        |2f    |2g    |2h    |2i    |2j
with SSL proxy                   | conn | conn | conn | conn | warn
---------------------------------|------|------|------|------|-----
https://webmail.wittenberg.edu/  |3f    |3g    |3h    |3i    |3j   
with SSL proxy                   | conn | conn | conn | conn | warn
---------------------------------|------|------|------|------|-----
https://www.kuix.de/links/       |4f    |4g    |4h    |4i    |4j   
with SSL proxy                   | stop | stop | stop | stop | stop
---------------------------------|------|------|------|------|-----
send mail                        |5a    |5b    |5c    |5d    |5e
with SMTP/SSL when available     | fail | conn | conn | conn | conn
---------------------------------|------|------|------|------|-----
send mail                        |5f    |5g    |5h    |5i    |5j
with SMTP/SSL always             | fail | conn | conn | conn | conn
---------------------------------|------|------|------|------|-----

Note: an inhouse SSL capable proxy is available at carbuncle.mcom.com port 8080



The above test results match the expection, which is described next:

----------------------------------

Site only speaking SSL2:
  https://investing.schwab.com/

1d, 1e, 1i, 1j
expected error message:
  SSL version 2 disabled

1a, 1b, 1c, 1f, 1g, 1h
connection should work
----------------------------------

Site generally able to speak TLS, but having no algorithms 
in common with Mozilla:
  https://www.verisign.com/

2e, 2j:
expected error message:
  no algorithms in common

2a, 2b, 2c, 2d, 2f, 2g, 2h, 2i
connection should work
----------------------------------

Site incompatible with TLS protocol, needs a connection retry
(but the user should not notice that)
  https://webmail.wittenberg.edu/

confirm the warning about the expired cert (if any)
  
3e, 3j expected to see:
  Error, because SSL is disabled

3a, 3b, 3c, 3d, 3f, 3g, 3h, 3i
the first connection in a freshly
started browser session should work.
----------------------------------

Site with untrusted certificate:
  https://www.kuix.de/links/

On connect, a untrusted certificate message will be shown.
Press cancel.

4a-j: no additional error message should be shown.
----------------------------------

Sending mail with SMTP over SSL (STARTTLS).
I used judge.netscape.com as outgoing server.
To my big surprise, tests 5e and 5j failed.
My expectation was, that by definition a STARTTLS
capable SMTP server must be able to speak TLS.
However, the reported error is "server and client
do not have common encryption algorithms".

Nelson confirmed that judge.netscape.com is likely
to run an old version of NSS and the failure is not
a surprise. Also note that this configuration is nothing
new, the existing behaviour without the patch
(see end of comment) is the same.

I tested 5e and 5j with my private SMTP server
at www.kuix.de (need a cert to relay) and it worked.
This server will not relay, but you can send a test
message to k@kuix.de
----------------------------------



Below is a couple of tests I made without the new patch.
I did not test the non-proxy cases, because I assume they work.
It is meant to document the existing behaviour that needs to be fixed.

===============================
Linux test results without fix:
===============================

site / enabled options:          | SSL2 | SSL2 | SSL2 |      |
                                 |      | SSL3 | SSL3 | SSL3 |  
                                 |      |      | TLS  | TLS  | TLS 
---------------------------------|------|------|------|------|-----
https://investing.schwab.com/    |1a    |1b    |1c    |1d    |1e     
no proxy                         |      |      |      |      |      
---------------------------------|------|------|------|------|-----
https://www.verisign.com/        |2a    |2b    |2c    |2d    |2e   
no proxy                         |      |      |      |      |     
---------------------------------|------|------|------|------|-----
https://webmail.wittenberg.edu/  |3a    |3b    |3c    |3d    |3e   
no proxy                         |      |      |      |      |     
---------------------------------|------|------|------|------|-----
https://www.kuix.de/links/       |4a    |4b    |4c    |4d    |4e   
no proxy                         |      |      |      |      |     
---------------------------------|------|------|------|------|-----
https://investing.schwab.com/    |1f    |1g    |1h    |1i    |1j     
with SSL proxy                   | conn | conn | conn | warn | warn  
---------------------------------|------|------|------|------|-----
https://www.verisign.com/        |2f    |2g    |2h    |2i    |2j   
with SSL proxy                   | conn | conn | conn | conn | warn
---------------------------------|------|------|------|------|-----
https://webmail.wittenberg.edu/  |3f    |3g    |3h    |3i    |3j   
with SSL proxy                   | conn | conn |!FAIL |!FAIL |!FAIL
---------------------------------|------|------|------|------|-----
https://www.kuix.de/links/       |4f    |4g    |4h    |4i    |4j   
with SSL proxy                   |!FAIL |!FAIL |!FAIL |!FAIL |!FAIL
---------------------------------|------|------|------|------|-----
send mail                        |5a    |5b    |5c    |5d    |5e   
with SMTP/SSL when available     |      |      |      |      |     
---------------------------------|------|------|------|------|-----
send mail                        |5f    |5g    |5h    |5i    |5j   
with SMTP/SSL always             | fail | conn | conn | conn | conn   
---------------------------------|------|------|------|------|-----



Note for testing:
- in case 3* a cert warning is shown. press ok.
- in case 4* a cert warning is shown. press cancel




conn: connection was possible
warn: the expected warning was shown
stop: as expected, the connection stopped
fail: as expected, the connection failed
!FAIL: This does not meet the expectation



I am unable to test on Mac, because I do not have one.

We can either ask somebody to help out and produce a Mac test build,
or we risk the checkin and test Mac the day after the checkin.
(Assignee)

Comment 50

16 years ago
Created attachment 94584 [details] [diff] [review]
Patch v4

Same patch as v3, but has better comments.
Attachment #94549 - Attachment is obsolete: true
(Reporter)

Comment 51

16 years ago
Kaie, you should send me a Mac test build, preferably OSX.

Comment 52

16 years ago
Comment on attachment 94584 [details] [diff] [review]
Patch v4

r=javi

Changes in security look good.	Changes under mozilla/netwerk look good to me
as well, but I suggest finding someone from the necko team to look at those
changes as well.
Attachment #94584 - Flags: review+
(Reporter)

Comment 53

16 years ago
Javi's Mac OSX build works for me. Proxy is lab212sun.mcom.com:8080.
(Assignee)

Comment 54

16 years ago
I forgot to test one more thing, but I just did, and it works for me, too, on
both Linux and Windows.

I re-tested LDAP over SSL, since the patch also touches that code. Configuring
the inhouse LDAP directory nsdirectory and using a SSL connection, a dropdown
menu came up when typing an recipient in mail composer.
(Assignee)

Comment 55

16 years ago
John said, LDAP/SSL works with the Mac test build, too.
(Assignee)

Comment 56

16 years ago
Darin, Dan, Jean-Francois, can you please review the changes in your modules?

The latest patch makes renaming changes to the following modules:
- netwerk
- directory
- mailnews
See the beginning of section 49 for the motivation of those changes.


All the real code fixes are in security/manager, and have already been reviewed
by Javi.

Comment 57

16 years ago
Comment on attachment 94584 [details] [diff] [review]
Patch v4

r=darin for the netwerk changes.
Comment on attachment 94584 [details] [diff] [review]
Patch v4

R=ducarroz for mailnews changes
Comment on attachment 94584 [details] [diff] [review]
Patch v4

r=dmose for the mozilla/directory changes.
(Assignee)

Comment 60

16 years ago
Alec, can you please review?

Comment 61

16 years ago
Comment on attachment 94584 [details] [diff] [review]
Patch v4

sr=alecf
Attachment #94584 - Flags: superreview+
(Assignee)

Comment 62

16 years ago
Fixed on trunk.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
(Assignee)

Updated

16 years ago
Blocks: 87209
(Assignee)

Updated

16 years ago
Blocks: 149910
(Reporter)

Comment 63

16 years ago
Verified.
Status: RESOLVED → VERIFIED

Updated

13 years ago
Component: Security: UI → Security: UI
Product: PSM → Core

Updated

10 years ago
Version: psm2.0 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.