[GH-ISSUE #839] Clean up security settings for IMAP servers #663

Closed
opened 2026-02-26 01:31:15 +03:00 by kerem · 14 comments
Owner

Originally created by @Woi on GitHub (Feb 12, 2018).
Original GitHub issue: https://github.com/jberkel/sms-backup-plus/issues/839

I just stumpled on configuration options in extended settings -> IMAP server settings -> Security. First the difference between SSL and TLS is unclear. I assume it's the very old and confusing naming scheme of Netscape and Mozilla for STARTTLS vs. IMAPS [1].
Second: the optional settings could allow for silent downgrade attacks. I can't imagine any reason why there could be an IMAP server supporting STARTTLS sometimes and sometimes not.

So my suggestion is to remove the (optional) settings completely and make clear what is meant by SSL and TLS. Maybe ending up with None, SSL/TLS and STARTTLS as options, just as Mozilla did [1].

[1] http://forums.mozillazine.org/viewtopic.php?t=2730845

Originally created by @Woi on GitHub (Feb 12, 2018). Original GitHub issue: https://github.com/jberkel/sms-backup-plus/issues/839 I just stumpled on configuration options in _extended settings_ -> _IMAP server settings_ -> _Security_. First the difference between SSL and TLS is unclear. I assume it's the very old and confusing naming scheme of Netscape and Mozilla for STARTTLS vs. IMAPS [1]. Second: the _optional_ settings could allow for silent downgrade attacks. I can't imagine any reason why there could be an IMAP server supporting STARTTLS sometimes and sometimes not. So my suggestion is to remove the _(optional)_ settings completely and make clear what is meant by _SSL_ and _TLS_. Maybe ending up with _None_, _SSL/TLS_ and _STARTTLS_ as options, just as Mozilla did [1]. [1] http://forums.mozillazine.org/viewtopic.php?t=2730845
kerem 2026-02-26 01:31:15 +03:00
Author
Owner

@jberkel commented on GitHub (Feb 16, 2018):

@Woi thanks for the feedback, I'll change it for the next version

<!-- gh-comment-id:366192550 --> @jberkel commented on GitHub (Feb 16, 2018): @Woi thanks for the feedback, I'll change it for the next version
Author
Owner

@Woi commented on GitHub (Feb 23, 2018):

That's great. Thanks :)

<!-- gh-comment-id:368017054 --> @Woi commented on GitHub (Feb 23, 2018): That's great. Thanks :)
Author
Owner

@jberkel commented on GitHub (Mar 13, 2018):

@Woi I'm just looking at this issue. You're right:

  • SSL means SSL/TLS
  • TSL means STARTTLS
  • None = no SSL/TLS

SSLv3 is actually blacklisted and cannot even be used. so the options should be TLS, STARTTLS, None.

Optional has been renamed to "Trust all" (#391). It doesn't downgrade the connection but rather trusts all certificates (usually for self-hosted IMAP servers). Maybe this should be a separate option named "trust all certificates", since it applies both to TLS and STARTTLS.

screenshot_1520949069

<!-- gh-comment-id:372674344 --> @jberkel commented on GitHub (Mar 13, 2018): @Woi I'm just looking at this issue. You're right: * SSL means SSL/TLS * TSL means STARTTLS * None = no SSL/TLS SSLv3 is actually blacklisted and cannot even be used. so the options should be `TLS`, `STARTTLS`, `None`. Optional has been renamed to "Trust all" (#391). It doesn't downgrade the connection but rather trusts all certificates (usually for self-hosted IMAP servers). Maybe this should be a separate option named "trust all certificates", since it applies both to `TLS` and `STARTTLS`. ![screenshot_1520949069](https://user-images.githubusercontent.com/18891/37345815-06295a38-26ce-11e8-9a08-ae33a21ad7f9.png)
Author
Owner

@jberkel commented on GitHub (Mar 13, 2018):

@Woi does this make sense?
screenshot_1520966230

<!-- gh-comment-id:372773727 --> @jberkel commented on GitHub (Mar 13, 2018): @Woi does this make sense? ![screenshot_1520966230](https://user-images.githubusercontent.com/18891/37362593-f18eec3c-26f5-11e8-8585-ccb1ebe8d1e4.png)
Author
Owner

@Woi commented on GitHub (Apr 2, 2018):

Looks great in 1.5.11-BETA18. Thanks a lot :)

However, I have some concerns about the "trust all" settings: If the certificate changes, there needs to be a notification to the user. Otherwise we allow for silent man-in-the-middle attacks. (Dunno how it really behaves, because I can't test it)

One solution would be to pin the certificate after the first connection. A second solution would be to remove this option, and just allow users to (permanently) trust a self-singed cert whenever it occurs. A third way to handle this, is to remove the code completely. People running their own email-server, can easily get a let's encrypt certificate nowadays. The code can still be re-added and improved, should people complain. Plus: we know know that this feature is used and worth the effort :)

<!-- gh-comment-id:377985873 --> @Woi commented on GitHub (Apr 2, 2018): Looks great in 1.5.11-BETA18. Thanks a lot :) However, I have some concerns about the "trust all" settings: If the certificate changes, there needs to be a notification to the user. Otherwise we allow for silent man-in-the-middle attacks. (Dunno how it really behaves, because I can't test it) One solution would be to pin the certificate after the first connection. A second solution would be to remove this option, and just allow users to (permanently) trust a self-singed cert whenever it occurs. A third way to handle this, is to remove the code completely. People running their own email-server, can easily get a let's encrypt certificate nowadays. The code can still be re-added and improved, should people complain. Plus: we know know that this feature is used and worth the effort :)
Author
Owner

@jberkel commented on GitHub (Apr 3, 2018):

Yes, it could be improved, pinning would help to some degree. Can't say for sure but there are definitely many users will self-signed certificates out there, so I'm a bit hesitant about removing it completely. Maybe for version 1.6.0.

<!-- gh-comment-id:378186180 --> @jberkel commented on GitHub (Apr 3, 2018): Yes, it could be improved, pinning would help to some degree. Can't say for sure but there are definitely many users will self-signed certificates out there, so I'm a bit hesitant about removing it completely. Maybe for version 1.6.0.
Author
Owner

@madduck commented on GitHub (Apr 13, 2018):

Just chiming in quickly here, because I noticed that SMS Backup+ changed its behaviour and stopped syncing for me with the last backup. I use CAcert.org certificates (for now), and those are not in the "official" trust chain, but I imported them manually into Android. That works fine for K9 Mail, but it stopped working for SMS Backup+ — and I don't think I ever had "(trust all)" selected beforehand.

Anyway, I am currently forced to "trust all certificates", which is terrible in terms of the risk of MITM attacks as pointed out by @Woi . And no, it's sometimes not possible to get Letsencrypt certificates yet (in my case for lack of wildcard support).

<!-- gh-comment-id:381002537 --> @madduck commented on GitHub (Apr 13, 2018): Just chiming in quickly here, because I noticed that SMS Backup+ changed its behaviour and stopped syncing for me with the last backup. I use CAcert.org certificates (for now), and those are not in the "official" trust chain, but I imported them manually into Android. That works fine for K9 Mail, but it stopped working for SMS Backup+ — and I don't think I ever had "(trust all)" selected beforehand. Anyway, I am currently forced to "trust all certificates", which is terrible in terms of the risk of MITM attacks as pointed out by @Woi . And no, it's sometimes not possible to get Letsencrypt certificates yet (in my case for lack of wildcard support).
Author
Owner

@madduck commented on GitHub (Apr 13, 2018):

So I actually just deployed LE wildcard certs, but I still think that there ought to be a TOFU approach of sorts.

<!-- gh-comment-id:381012225 --> @madduck commented on GitHub (Apr 13, 2018): So I actually just deployed LE wildcard certs, but I still think that there ought to be a TOFU approach of sorts.
Author
Owner

@jberkel commented on GitHub (Apr 13, 2018):

@madduck how did you import the certs into Android? when you say it stopped working, when did it stop? did it work with SMS Backup+ 1.5.10?

and what's a TOFU approach?

<!-- gh-comment-id:381044196 --> @jberkel commented on GitHub (Apr 13, 2018): @madduck how did you import the certs into Android? when you say it stopped working, when did it stop? did it work with SMS Backup+ 1.5.10? and what's a TOFU approach?
Author
Owner

@Woi commented on GitHub (Apr 19, 2018):

I found the answer: "Trust on first use", that's exactly what I described as second solution :).

Usually I like the iterative approach: things have improved, let's ship and do further improvements for later releases.
But this is a security relevant topic, so I hesitate to say it to easily.

I would base the decision on the following points:

  • Default settings are save
  • How much work is it to implement TOFU or #875 for the 1.5.11 release?
  • When do you plan to release the next but one version?

Do you like to have an issue/feature request for TOFU support?

<!-- gh-comment-id:382682582 --> @Woi commented on GitHub (Apr 19, 2018): I found the answer: "Trust on first use", that's exactly what I described as second solution :). Usually I like the iterative approach: things have improved, let's ship and do further improvements for later releases. But this is a security relevant topic, so I hesitate to say it to easily. I would base the decision on the following points: * Default settings are save * How much work is it to implement TOFU or #875 for the 1.5.11 release? * When do you plan to release the next but one version? Do you like to have an issue/feature request for TOFU support?
Author
Owner

@madduck commented on GitHub (Apr 19, 2018):

@jberkel sorry for the late response. I imported the certs into Android using the settings dialog, and yes, it used to work with prior versions, though I admit I don't know for sure that I hadn't selected "TLS (trust all)" beforehand, though I seriously doubt it, because I just would not settle for that.

<!-- gh-comment-id:382686444 --> @madduck commented on GitHub (Apr 19, 2018): @jberkel sorry for the late response. I imported the certs into Android using the settings dialog, and yes, it used to work with prior versions, though I admit I don't know for sure that I hadn't selected "TLS (trust all)" beforehand, though I seriously doubt it, because I just would not settle for that.
Author
Owner

@jberkel commented on GitHub (Apr 20, 2018):

@Woi I'm with you regarding the importance of security related issues but I'd like to ship 1.5.11 soon. I don't have the numbers but only a very small percentage use this feature (as you said, default settings are save). I think it will be a bit of work since some GUI / notification is needed, which also means new strings + translations + testing. Let's do this for the next version (shouldn't be too long this time). Can you create a ticket for it? (for the tofu approach)

<!-- gh-comment-id:382992182 --> @jberkel commented on GitHub (Apr 20, 2018): @Woi I'm with you regarding the importance of security related issues but I'd like to ship 1.5.11 soon. I don't have the numbers but only a very small percentage use this feature (as you said, default settings are save). I think it will be a bit of work since some GUI / notification is needed, which also means new strings + translations + testing. Let's do this for the next version (shouldn't be too long this time). Can you create a ticket for it? (for the tofu approach)
Author
Owner

@Woi commented on GitHub (Apr 22, 2018):

@jberkel Created

<!-- gh-comment-id:383408692 --> @Woi commented on GitHub (Apr 22, 2018): @jberkel Created
Author
Owner

@acht commented on GitHub (Dec 18, 2018):

I have the same observation like madduck. A self-signed certificates imported to the android key-store worked fine. For me it changed after the upgrade to android 7.
Never the less I would prefer a certificate pinning.

<!-- gh-comment-id:448413076 --> @acht commented on GitHub (Dec 18, 2018): I have the same observation like madduck. A self-signed certificates imported to the android key-store worked fine. For me it changed after the upgrade to android 7. Never the less I would prefer a certificate pinning.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/sms-backup-plus-jberkel#663
No description provided.