SslHelper has been removed, and its functionality has been transferred
into TrustedSocketFactory. The added layer of indirection wasn't really
simplifying anything. It's now easier to see what happens when
createSocket() is invoked.
A new instance of SecureRandom is no longer passed to SSLContext.init().
Instead, null is passed.
The (default) provider of the TLS SSLContext used is OpenSSLProvider,
which provides an SSLSocket instance of type OpenSSLSocketImpl. The only
use of SecureRandom is in OpenSSLSocketImpl.startHandshake(), where it is
used to seed the OpenSSL PRNG with additional random data. But if
SecureRandom is null, then /dev/urandom is used for seeding instead.
Meanwhile, the default provider for the SecureRandom service is
OpenSSLRandom, which uses the OpenSSL PRNG as its data source. So we were
effectively seeding the OpenSSL PRNG with itself. That's probably okay
(we trust that the OpenSSL PRNG was properly initialized with random data
before first use), but using /dev/urandom would seem like a better source
(or at least as good a source) for the additional seed data added with
each new connection.
Note that our PRNGFixes class replaces the default SecureRandom service
with one whose data source is /dev/urandom for certain vulnerable API
levels anyway. (It also makes sure that the OpenSSL PRNG is properly
seeded before first use for certain vulnerable API levels.)
This is done when the SASL EXTERNAL mechanism isn't advertised (indicating
the possibility that the server did not accept the client certificate) or
when the command for authenticating with SASL EXTERNAL fails.
The CertificateValidationException will trigger a notification to the user
that there's an authentication problem that needs addressing.
Also, there were instances where CertificateValidationException was being
thrown with a new CertificateException as the cause for the purpose of
notifying the user when STARTTLS is not available. This has been slightly
simplified by eliminating the need to include a new CertificateException
as a cause.
In response to Issue 1794,
- add a configuration option in the account preferences to show
notifications only for 1st/2nd/etc class folders
- add an option in the folder preferences to set the notification class
as 1st, 2nd or inherited from the folder's push class
The default behaviour remains unchanged.
Instead of interpreting a "-" at the beginning of a line as
an error response, consider the absence of a "+" at the
beginning of a line as an error response.
This is what Thunderbird does.
http://hg.mozilla.org/releases/comm-esr24/file/55e96a433bd1/mailnews/local/src/nsPop3Protocol.cpp#l1177
The problem arises with godaddy servers spewing additional
lines of data upon login failure. The login was being
interpreted as successful, and a STAT commanded was subsequently
being sent, resulting in a dialog saying 'Cannot connect to
server. (Invalid int: "auth_error:")'.
$ openssl s_client -quiet -crlf -connect pop.secureserver.net:995
...
+OK <24984.1394317012@pop.secureserver.net>
user testuser
+OK
pass testpass
testuser not found in the auth database
warning: auth_error: authorization failed (no such object)
-ERR authorization failed Check your server settings.
Some IMAP servers are broken and don't correctly handle string
literals with the LOGIN command.
This switches to using quoted strings instead.
This is what Thunderbird does.
