An interrupted connection attempt to the server yields an SSLException
as well, like this:
E/k9 ( 6937): Caused by: javax.net.ssl.SSLHandshakeException: Connection closed by peer
E/k9 ( 6937): at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(Native Method)
E/k9 ( 6937): at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:302)
E/k9 ( 6937): at com.android.org.conscrypt.OpenSSLSocketImpl.waitForHandshake(OpenSSLSocketImpl.java:598)
E/k9 ( 6937): at com.android.org.conscrypt.OpenSSLSocketImpl.getInputStream(OpenSSLSocketImpl.java:560)
E/k9 ( 6937): at com.fsck.k9.mail.store.ImapStore$ImapConnection.open(ImapStore.java:2459)
We don't want the user to notify of 'certificate problems' in that case.
Fix it by checking whether the SSLException was actually triggered by a
CertificateException.
First we try the original MIME type unless it's application/octet-stream.
Then we try the MIME type inferred from the attachment's file extension.
Then we fall back to application/octet-stream.
In all cases we first try the content:// URI, then a file:// URI.
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 was dead code. The exception message will always start with either
"SMTP response is 0 length" from checkLine() or else "Negative SMTP reply"
from NegativeSmtpReplyException().
The problem originated from way back before 4.904.
