GNOME Bugzilla – Bug 772305
Advertise both SSL and STARTTLS for GMail
Last modified: 2017-09-11 14:59:52 UTC
Current situation: Presently, `goagoogleprovider` uses "ImapUseSSL" (IMAP over TLS, yes the name is poor) and "SmtpUseTLS" (SMTP over STARTTLS, again poor name). How this is a problem: * STARTTLS provides opt-in (aka. opportunistic) "security": it defaults back to clear-text (no SSL/TLS at all) in case of an active attack or if any router anywhere is misconfigured. * The content of the email itself can then trivially be read by the attacker in such a case. * Far worse, most clients will try to identify anyway even in case of a downgrade, without any notification. In the most common cases (PLAIN or LOGIN), this means that the account password is graciously given in cleartext. Suggested fix: In this very specific case, Google supports SMTP over TLS (without any password leakage possible). The way to get this for free is to change "smtp-use-tls" by "smtp-use-ssl" there: https://github.com/GNOME/gnome-online-accounts/blob/master/src/goabackend/goagoogleprovider.c#L358 in order to set the following to TRUE: https://developer.gnome.org/goa/stable/gdbus-org.gnome.OnlineAccounts.Mail.html#gdbus-property-org-gnome-OnlineAccounts-Mail.SmtpUseSsl Note, once again, that the naming is poor: TLS will actually be used there. Nota Bene: I am well aware of SMTP shortcomings: using such an option won't prevent the email from being read afterwards from SMTP servers to SMTP servers before reaching its final destination due to the very same problem. However that guarantees, at least, that the password won't be leaked. And again, this is for free: Google supports that already.
(In reply to lltp from comment #0) > Presently, `goagoogleprovider` uses "ImapUseSSL" (IMAP over TLS, yes the > name is poor) and "SmtpUseTLS" (SMTP over STARTTLS, again poor name). Yes, the *UseTls and *UseSsl names are unfortunate. They date back to 2011: https://git.gnome.org/browse/gnome-online-accounts/commit/?id=c6b207076a7dec3ced76bae4641f522845af6fe0 Once the boolean *UseTls properties were added, we had to use a separate set of variables to differentiate STARTTLS and non-STARTTLS. Ideally the variables should have been integers representing flags. > How this is a problem: > > * STARTTLS provides opt-in (aka. opportunistic) "security": it defaults back > to clear-text (no SSL/TLS at all) in case of an active attack or if any > router anywhere is misconfigured. > * The content of the email itself can then trivially be read by the attacker > in such a case. > * Far worse, most clients will try to identify anyway even in case of a > downgrade, without any notification. In the most common cases (PLAIN or > LOGIN), this means that the account password is graciously given in > cleartext. Are you aware of any specific mail client that falls back to plain text when STARTTLS fails? I am told that since 3.22 Evolution will error out if it was unable to establish a secure connection. > In this very specific case, Google supports SMTP over TLS (without any > password leakage possible). The way to get this for free is to change > "smtp-use-tls" by "smtp-use-ssl" there: > > [...] > > I am well aware of SMTP shortcomings: using such an option won't prevent the > email from being read afterwards from SMTP servers to SMTP servers before > reaching its final destination due to the very same problem. However that > guarantees, at least, that the password won't be leaked. And again, this is > for free: Google supports that already. Yes, you are right. Google supports both STARTTLS (ie. port 465) and without (ie. port 587) for SMTP: * https://support.google.com/mail/answer/7126229?hl=en * https://support.google.com/a/answer/176600?hl=en
(In reply to Debarshi Ray from comment #1) > > In this very specific case, Google supports SMTP over TLS (without any > > password leakage possible). The way to get this for free is to change > > "smtp-use-tls" by "smtp-use-ssl" there: > > > > [...] > > > > I am well aware of SMTP shortcomings: using such an option won't prevent the > > email from being read afterwards from SMTP servers to SMTP servers before > > reaching its final destination due to the very same problem. However that > > guarantees, at least, that the password won't be leaked. And again, this is > > for free: Google supports that already. > > Yes, you are right. Google supports both STARTTLS (ie. port 465) and without > (ie. port 587) for SMTP: > * https://support.google.com/mail/answer/7126229?hl=en > * https://support.google.com/a/answer/176600?hl=en Also: https://www.lifewire.com/what-are-the-gmail-smtp-settings-1170854
Created attachment 352790 [details] [review] google: Set smtp-use-ssl to TRUE
I think it will be more appropriate to advertise support for both schemes, and let the MUAs decide which one to use. This is in line with our policy of not getting involved too much in the specific details of IMAP, SMTP, CalDAV, etc. and delegating as much as possible to the relevant clients.
There had been filled also bug #783385, which I used for evolution-data-server. You might advertise different server for SMTP, not only that it knows SSL, in case of Gmail, like smtp.googlemail.com (and imap.googlemail.com for IMAP), instead of using the gmail.com domain.