Caching is beneficial because it can eliminate redundant cryptographic
computations and network traffic when re-establishing a connection to
the same server, thus saving time and conserving power.
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.)
The constructor now saves the certificate chain, so the code to retrieve
it again or to perform any additional error checking in
getCertificateChain() is no longer needed.
The constructor now retrieves and saves the private key so that any
resulting errors are detected sooner.
Methods that retrieve the alias perform checks to assure that the client
cert. satisfies the requested issuers and key type. It's known that
Sendmail may provide a list of issuers in its certificate request, but
then may authenticate against a much larger set of CAs, but then later
reject the mail because the client certificate was not acceptable.
Vetting against the issuer list helps detect such certificate problems
sooner (upon connection) rather than later (upon transmission of mail).
Earlier error detection is necessary so that errors may be presented to
the user during account setup.
Portions of these modifications are based on code from KeyManagerImpl:
https://android.googlesource.com/platform/external/conscrypt/+/master/src/main/java/org/conscrypt/KeyManagerImpl.java
Move KeyChainKeyManager to com.fsck.k9.net.ssl because it is used by
SslHelper and because the class extends X509ExtendedKeyManager, which is
in javax.net.ssl.
If the alias is empty or null, don't bother using KeyChainKeyManager.
If the alias is not empty, confirm that it is associated with a
certificate, otherwise throw a CertificateValidationException
which will notify the user of the problem and ask the user to
check the server settings.
Likewise, the user is notified if the client certificate was
not accepted by the server.
With this commit, KeyChainKeyManager no longer throws the exception and
AccountSetupCheckSettings no longer catches it.
It was being thrown when the server requested a client certificate but no
client certificate alias had been configured for the server.
The code was making the incorrect assumption that the server would only
request a client certificate when such a certificate was *required*.
However, servers can be configured to accept multiple forms of
authentication, including both password authentication and client
certificate authentication. So a server may request a certificate without
requiring it. If a user has not configured a client certificate, then
that should not be treated as an error because the configuration may be
valid and the server may accept it.
The only indication that a certificate is *required* is when a
SSLProtocolException is thrown, caused by a SSLHandshakeException
resulting from a fatal handshake alert message received from the server.
Unfortunately, such a message is fairly generic and only "indicates that
the sender was unable to negotiate an acceptable set of security
parameters given the options available." So there is no definitive way to
know that a client certificate is required.
Also, KeyChainKeyManager.getCertificateChain() and getPrivateKey() no
longer throw IllegalStateException(). These methods are permitted to
return null, and such a response is appropriate if the user has deleted
client certificates from the device. Again, this may or may not cause the
server to abort the connection, depending on whether the server *requires*
a client certificate.
The app's minSdkVersion = 15 (Android 4.0.3, Ice Cream Sandwich MR1),
so there's no need to test the API level.
This also removes '@SuppressLint("TrulyRandom")'. I find no
documentation for it, nor do I find any additional lint errors
with its removal.
Blacklist a couple of weak ciphers, bring known ones in a defined order and sort unknown
ciphers at the end. Also re-enable SSLv3 because it's still used a lot.
Instead, have K9.onCreate initialize the location of the key
store file (similar to what is done with
BinaryTempFileBody.setTempDirectory).
Also, LocalKeyStore.getInstance has been changed so that it
no longer needs to be synchronized.
The classes are just as much related to com.fsck.k9.mail.transport
as com.fsck.k9.mail.store, so having them in
com.fsck.k9.mail.store doesn't seem appropriate.
Move LocalKeyStore to com.fsck.k9.security
Move TrustManagerFactory and TrustedSocketFactory to com.fsck.k9.net.ssl
