468664 - TB 3 could not connect pop3 with TLS option and port different from 995

Status: RESOLVED WORKSFORME

(Thunderbird :: Security, defect)

Description

[Honza Bambas (:mayhemer)]

I have got a free email account on www.volny.cz and I am using TLS to download from their pop server. In TB 2 server setting are:

server: pop3.volny.cz
port: 110 (the default POP3, not TSL, I had to override to make it work)
security: TLS

According to Wireshark the communication is really being encrypted after STLS request when using TB 2. Had to add a cert exception, too.

The bug is that TB 3 doesn't correctly migrate port set to 110 from TB 2 profile when TLS option is set for the server and default it to 995. When I open the same profile after it has been opened in TB 3 again with TB 2 the port setting is as expected, 110.

There is a secondary account with following settings too:
server: pop.gmail.com
port: 995
security: SSL

Port 995 is accessible on the server but TB 3 doesn't communicate. It means - TB 3 opens a TCP connection to pop3.volny.cz:995 and then stuck, no data sent nor any communication made. Not sure now how POP3 over TLS works... might be the volny portal problem.

Comment 1

[Honza Bambas (:mayhemer)]

Might be related to bug 465702.

Comment 2

[Magnus Melin [:mkmelin] (away until Aug 10)]

> The bug is that TB 3 doesn't correctly migrate port set to 110 from TB 2
> profile when TLS option is set for the server and default it to 995.

AFAIK, there we do not attempt to migrate you to port 995, nor should we.

Comment 3

[Honza Bambas (:mayhemer)]

Anyway, I see port 995 in the settings and there is also attempt to connect port 995. Could the secondary account settings leak somehow or affect the first account?

I can spend some time on this bug and find out what's wrong but it is probably not hi priority. The settings are not that usual.

Comment 4

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #3)
> Could the secondary account settings leak somehow or affect the first account?

Possibly problem in account definition. Following problem is already found.
(1) Define Account-1 with Server-X, User-X (hostname=Server-X/userName=User-X)
(2) Change user name of Account-1 to User-1. (realUserName=User-1)
(3) Define Account-2 with Server-X, User-X.
    DUP check looks to be done on hostname/realUserName of Account-1,
    and Tb creates server entry with same hostname=Server-X/userName=User-X,
    or mis-uses already defined server entry. Then following occurs.
    (3-A) Tb branch : Generates wrong settings in prefs.js.
                      Account-2 is invisible. (Folder Pane/Account Settings)
    (3-B) Tb trunk  : Seems to generate appropriate settings in prefs.js.
                      But accounts use wrong entries. (DUPed account)

If garbages by (3) exist in prefs.js, wrong entry can be used upon server access. Check prefs.js entries.
> mail.account.accountMM.server
> mail.server.serverNN.hostname 
> mail.server.serverNN.realhostname 
> mail.server.serverNN.userName 
> mail.server.serverNN.realuserName

Comment 5

[WADA:World Anti-bad-Duping Agency]

FYI. Bug 303542 is problem I described in Comment #4.

Comment 6

[WADA:World Anti-bad-Duping Agency]

Following phenomenon was also reported in other bugs.
  Multiple mail.account.accountX.server entries point to same "serverN".
Sorry but it's relevant to Bug 303542 or not.

Comment 7

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #6)
I wanted to say. (sorry for spam)
> Sorry but I don't know whether it's relevant to Bug 303542 or not.

Comment 8

[Magnus Melin [:mkmelin] (away until Aug 10)]

Did you mean port 993? 
This sounds a lot like bug 470067 (which is fixed now), if that's the case.

Comment 9

[Ludovic Hirlimann [:Usul]]

Honza, do you still see this with recent nightlies ?

Comment 10

[Kai Engert [:KaiE:]]

Honza, there are two different variations for POP3 with encryption.

The first one is POP3 + STARTTLS (TLS).
This connection is usually on port 110.
It starts with a plaintext socket, and after the client sends a comment, both client and server switches the open connection to encrypted and start the crypto handshake.

The second one is POP3 + SSL
This connection is usually on port 995.
This type wraps encryption around the inner protocol, exactly as done with https.

I think maybe you have used the incorrect STARTTLS/SSL setting. Try both.

I just made a test, used POP3 to pop3.volny.cz with STARTTLS and default port 100. I get a connection. I get a certificate error (unknown issued), but this tells me the SSL connection worked.

When I connect to pop3.volny.cz using SSL and default port 995, it works, too (same cert error, but connection ok).

Comment 11

[Kai Engert [:KaiE:]]

Once Honza has tested we can probably close this bug as invalid.

Comment 12

[Honza Bambas (:mayhemer)]

Thanks for all comments, it seems the behavior is described in comment 4 - the settings leaks each between other. However, I have to test this again with recent nightly and report back.

Kai, I believe this is not caused by any psm/nss problem.

Comment 13

[Honza Bambas (:mayhemer)]

This is fixed at Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090225 Shredder/3.0b3pre.

Comment 14

[Magnus Melin [:mkmelin] (away until Aug 10)]

->WFM ("FIXED" is only used when known code changes resolved the issue)