These options originated in the AOSP email client from which K-9 Mail was
forked. They provide an odd combination of 2 features:
1. Don't bother to authenticate the server's certificate (applies to both
SSL/TLS and STARTTLS); i.e., blindly accept all certificates. This is
generally a bad security policy which is susceptible to MITM attacks.
2. If STARTTLS is selected but the server doesn't claim to support
STARTTLS, then proceed without using encryption. This, too, is a bad
security policy which is susceptible to MITM attacks.
Since the time that K-9 Mail was forked, a couple things have changed:
> K-9 Mail has implemented the ability for users to review and permanently
accept individual certificates that would otherwise fail authentication.
With this ability, there is no need for a user to subject themselves to
the ongoing risks of feature 1. above. Hence, this commit removes feature
1.
> The AOSP email client has changed its behavior and no longer permits a
security downgrade to an unencrypted connection if the server doesn't
claim to support STARTTLS (i.e., they eliminated feature 2. above). K-9
Mail should do the same. It's unlikely that a server is going to provide
STARTTLS on an intermittent basis, so providing a contingency for such
unusual behavior is an unnecessary risk. Hence, this commit removes that
feature as well.
Effect on existing users:
If the old connection security setting was "SSL/TLS (if available)" (which
now gets remapped to "SSL/TLS"), and the server does not provide a
certificate that can be authenticated, then a "Certificate error for
<account name>" notification is generated telling the user to check their
server settings. Tapping the notification takes the user to the relevant
server settings, where the user can tap "Next" to review the certificate
and choose to permanently accept it. This process would occur during the
first syncing of folders after application upgrade or (in the case of
SMTP) during the first attempt to send a message.
If the connection security setting was "STARTTLS (if available)" (which
now gets remapped to "STARTTLS"), and the server does not provide a
certificate that can be authenticated, then the same process as above
would occur.
If the old connection security setting was "STARTTLS (if available)", and
the server doesn't claim to support STARTTLS, then the user would get a
certificate error notification which would lead them to the server's
settings. There they would need to choose a different connection security
-- most likely "NONE". If they didn't change anything but instead just
tapped "Next", the server settings would be checked again and a dialog
would pop up saying, "Cannot connect to server. (STARTTLS connection
security not available)". (The implementation of notifications when
STARTTLS is not available is not actually included here -- it's in the
commit that follows.)
Regarding the changes to providers.xml: in cases where the scheme ended
with "+ssl", the schemes were simply updated by appending "+". In cases
where the scheme ended with "+tls", a check of the server was made to
assure that STARTTLS was available before appending "+" to the scheme.
Domains paran.com and nate.com failed the check and were removed because
no current information could be found. Domains me.com and mac.com also
failed and were updated based on http://support.apple.com/kb/ht4864.
Applicable for strings not intended for user consumption.
A %d string format code can generate eastern-arabic numerals
for users with an arabic locale.
V/k9 (20763): conn1103774136>>> 5 UID SEARCH ٦٤٦:٦٧٠ NOT DELETED
V/k9 (20763): conn1103774136<<<#5# [BAD, Invalid Search criteria]
E/k9 (20763): synchronizeMailbox
E/k9 (20763): com.fsck.k9.mail.store.ImapStore$ImapException: Command: UID SEARCH ٦٤٦:٦٧٠ NOT DELETED; response: #5# [BAD, Invalid Search criteria]
If the user chooses a connection security option which assures the use of
encryption, then the PLAIN auth. option is labeled "Normal password",
otherwise it is labeled "Password, transmitted insecurely".
This is similar to Thunderbird's behavior.
The LOGIN option is no longer offered to users as a choice. This does
*not* eliminate the SASL LOGIN authentication mechanism. Any pre-existing
LOGIN setting or any imported LOGIN setting will still be recognized. In
all cases, a user setting of either "Normal password" or "LOGIN" will
result in the SASL PLAIN mechanism being tried first if available,
otherwise SASL LOGIN will be tried if available.
This mirrors similar behavior that exists for IMAP.
AUTOMATIC = "Automatic"
PLAIN = "Normal password"
CRAM_MD5 = "Encrypted password"
SMTP also uses LOGIN. No localized text was associated with that because
a future commit will remove that option.
(The text is similar to that of Thunderbird's)
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
Also, implement the ability to configure an alternate key store
file location. This permits the running of unit tests without
clobbering the live key store file.
Also, add a test to confirm that the key store file is being written
out and reread correctly.
Proper host name validation was not being performed for certificates
kept in the local keystore. If an attacker could convince a user to
accept and store an attacker's certificate, then that certificate
could be used for MITM attacks, giving the attacker access to all
connections to all servers in all accounts in K-9.
This commit changes how the certificates are stored. Previously, an
entire certificate chain was stored for a server (and any of those
certificates in the chain were available for validating signatures on
certificates received when connecting). Now just the single
certificate for the server is stored.
This commit changes how locally stored certificates are retrieved.
They can only be retrieved using the host:port that the user
configured for the server.
This also fixes issue 1326. Users can now use different certificates
for different servers on the same host (listening to different ports).
The above changes mean that users might have to re-accept certificates
that they had previously accepted and are still using (but only if the
certificate's Subject doesn't match the host that they are connecting
to).
This commit modifies AccountSetupBasics so that it now calls
AccountSetupCheckSettings twice -- once for checking the incoming
settings and once for the outgoing settings. Otherwise, an exception
could occur while checking incoming settings, the user could say
continue (or the user could accept a certificate key), and the
outgoing settings would not be checked. This also helps with
determining if a certificate exception was for the incoming or
outgoing server, which is needed if the user decides to add the
certificate to the keystore.
If you attempted to use SSL to connect to a server that speaks
STARTTLS, you should get an SSL protocol error. Instead, you
were likely to get an "Unrecognized Certificate" error that shows
you an unrelated certificate chain and asks you to accept it or
reject it. Neither action would work because the actual problem
had nothing to do with certificates. The unrelated certificate
chain that popped up had been statically stored when validating
a prior connection to a different server.
With this patch, certificate chains are no longer stored statically
when validating server connections.
Issue 5886 is an example of a user experiencing this problem.
* 'Issue_4503_auto-fit_messages_option' of https://github.com/zjw/k-9:
Revert "Don't show a disabled preference if there is nothing a user can do to enable it."
Fix indentation
Correct preference version number.
Issue 4503: Auto-fit messages option
Don't show a disabled preference if there is nothing a user can do to enable it.
The server search itself does work. But the results are not displayed
to the user because only the message headers of found messages are
downloaded and the subsequent search in the local database won't return
those messages.
by default.
The message view theme isn't something the user is likely to change on a
regular basis, so we don't need to clutter the message view menu with
this setting. The menu item can still be enabled for those who want it.
The commit that introduced those notifications also introduced a rather
... interesting design pattern: The CertificateValidationException
notified the user of its pure existance - it's no longer a 'message'
only, but defines policy. As this is more than unusual, replace this
pattern by the MessagingController treating
CertificateValidationException specially when accessing remote folders.
Also make clear which account failed when constructing the notification.
* zjw/folder_search:
Provide message search capability from the folder list.
Eliminate unused code.
Switch to using the action bar for folder searches.
Use a more appropriate title when diplaying folder search results.
Switch to using the action bar for folder searches.
Provide new action bar "find folder" icons
Create action buttons to search for folders.
Readjust settings version number based on current master
Control wrapping of folder names programmatically only
Permit the folder list item to expand vertically.
Create new preference option for wrapping folder names in folder list view.
Issue 1911: Permit folder names to wrap on multiple lines in folder list view so users can see the entire name.
With this fix, a CertPathValidatorException or CertificateException will
create a "Certificate error: Check your server settings" notification
in the status bar. When the user clicks on the notification, they are
taken to the appropriate server settings screen where they can review their
settings and can accept a different server certificate.
With the introduction of the action bar there is no longer a separate
button bar for refile actions. So it's no longer necessary to hide the
buttons to save screen space.
* imapsearch:
Change settings version to 18 to match what's currrently on master.
Handle aborted imap searches by nuking in-progress connections.
Move IMAP search into the Folder level.
Remove duplicate notification on remote search start.
Rename variables
changed PREFERENCE_CLOUD_SEARCH_ENABLED from "cloud_search_enabled" to "remote_search_enabled" in activity/setup/AccountSettings.java to resolve FC.
Add cloud search icon to local search result screen. Implement pull-to-remote-search.
Log remote search exceptions in addition to toasting them.
Add settings export for remote search settings.
Whitespace; no functional changes.
Handle implicit vs. explicit searches in ActionBar home button behavior.
Whitespace fix; no functional changes.
Add remote search actionbar icons.
IMAP Search: log exceptions on remote search, properly dispatch MessageList changes.
modified loadMessageForView() to dowload message if neither X_DOWNLOADED_FULL nor X_DOWNLOADED_PARTIAL.
Add remote IMAP search support.
Conflicts:
res/menu/message_list_option.xml
res/values/attrs.xml
res/values/themes.xml
src/com/fsck/k9/activity/MessageList.java
src/com/fsck/k9/preferences/Settings.java
* rbayer/IMAPsearch: (21 commits)
More cleanup
Code Cleanup getRemoteSearchFullText -> isRemoteSearchFullText line wraps for preference items
Refactor to allow fetching of extra search results beyond original request. Most code moved out of ImapStore and ImapFolder and into MessagingController.searchRemoteMessagesSynchronous. Should make it easier to add remoteSearch for other server types.
Prevent delete of search results while search results open
remove duplicated code block
Don't hide Crypto when IMAPsearch disabled
Code Style Cleanup: Tabs -> 4 spaces Remove trailing whitespace from blank lines
tabs -> spaces (my bad...)
Fix opening of folders to be Read-Write when necessary, even if they were previously opened Read-Only.
add missing file
Working IMAP search, with passable UI.
UI improvements
Simple help info when enabling Remote Search
Dependency for preferences
Basic IMAP search working
Now that the subject line is gone, the right side of the header is now the tallest part of the header.
Put date and time on the same line to keep the header compact.
We always allow zooming but hide (provided the Android version supports
it) the on-screen zoom controls if the device supports multi-touch,
hence pinch-to-zoom.
Joe Steele