249223 - POP with SSL/TLS fails with apache secure pop with error -12229

Status: VERIFIED INVALID

(MailNews Core :: Networking: POP, defect)

Description

[Ralf Hauser]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040614
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040614

apparently, Mozilla tries to impose a cipher apache james doesn't know:
"Could not create cipher AES/128" and "No implementation for AES/CBC/NoPadding
found"

see also http://james.apache.org/

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Christian Eyrich]

Yep, could verify this on Linux with a current nightly. It works if you switch
of 128-bit AES in Preferences/Privacy&Security/SSL/Edit Ciphers/Extra SSL3/TLS.

But I can't say for sure why this fails - is it because the algorithm is buggy
in Mozilla or because the server doesn't support it.
In the latter case, why does it try to use it then, there are enough other?

At least TLS_RSA_WITH_AES_128_CBC_SHA doesn't seem to be buggy in Mozilla
because it works in conjunction with stunnel4 though it doesn't with James. So I
tend to a problem in James.

Comment 2

[Christian Eyrich]

Nelson, any idea how to test who's wrong - James or Mozilla?

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Based solely on the info given above, this is a server error.


The client sends a list of ciphersuites that it supports to the server.
This list is ordered in descending order of the client's preference,
that is, most preferred first.

The server then picks one from that list, one that it also supports,
and sends a reply back to the client saying "I chose this one".
The server is supposed to pick the first ciphersuite in that list that
it (the server) also supports.

However, according to the report above, the server apparently picked a
ciphersuite from the client's list that it does not actually implement.  
when it tried to use the ciphersuite that it chose, it failed.  
Removing that particular ciphersuite from the list sent by the client 
reportedly solves the problem, which implies that with that particular
suite removed, the server picks one that it really does implement.

Clearly it is not a client bug if the server picks a ciphersuite that 
it does not implement.  So, this is not a valid client bug.  

Comment 4

[Ralf Hauser]

see also bug 239019
This was solved on the server side, by adding the bouncycastle.org provider to
the JVM because Mozilla used ciphers Sun didn't offer by default (see the james
issue for details).

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

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