6 ms·

This is a bad move that will give users a false sense of security. Server-to-server SMTP is unauthenticated. Just because an email arrived at Gmail over an en

by agwa 11y ago

This is a bad move that will give users a false sense of security. Server-to-server SMTP is unauthenticated. Just because an email arrived at Gmail over an encrypted connection doesn't mean that the connection wasn't intercepted by a MitM that read the message and then relayed it to Gmail over an encrypted connection. Opportunistic encryption is nice to have because it stymies passive surveillance, but it's not something that can be relied upon to provide security or privacy. Thus, its presence or absence should never be communicated to users, to avoid suckering them into a false sense of security.

harshreality 11y ago
There's a way to fairly reliably mark messages as insecure when they're sent by clients that don't verify certs. For every incoming ssl smtps connection, google could forge a cert the first time it encounters a connection from a particular ip on a particular day. If the client continues with the ssl negotiation, google would know to mark the message as unsecure, because the sender isn't verifying certs. You could obviously adjust the frequency with which the recipient (eg google) tests each IP. It wouldn't have to be every 24 hours. You could also use additional heuristics to re-test, even going so far as to disconnect immediately and force the client to retry (giving it a forged cert test) if you trust the client ip but see a different helo than you saw last time. You could even use global bgp feed to invalidate any successful tests from a netblock when there's a visible routing change for it.
- agwa 11y ago
  If Gmail did this, the MitM would be sure to correctly validate Gmail's certs.
- tedunangst 11y ago
  Introducing spurious failures to improve security feels like one of those ideas likely to have unintended consequences.
- cortesoft 11y ago
  What would stop the MiTM from verifying Gmail's cert? Say, the email is sent in plain text, it is intercepted by the bad guy, then the bad guy sends it on to gmail encrypted, with cert checking and everything. I am failing to see what your proposal would help.
wyldfire 11y ago
99% of gmail users will never know that the feature exists until they see the warning. That can only have the benefit of encouraging the correspondent to get their provider(s) to enable the encryption. > stymies passive surveillance... presence or absence should never be communicated ... to avoid suckering them into a false sense of security. I think you're not giving enough weight to the first point. This really does provide an advantage for individuals who receive their password/reset url or some other credentials via email. At least it wouldn't be intercepted on that hop. Seems like the benefits outweigh the drawbacks.
- agwa 11y ago
  > At least it wouldn't be intercepted on that hop It wouldn't be passively intercepted. It could trivially be actively intercepted. Gmail would not display a warning in this case, thus making the user think their password/reset URL was safe when it really wasn't. And trying to inform users about the difference between passive and active interception, and expecting them to make a risk evaluation based on it, is just not realistic for the vast majority of users.
  - andrewaylett 11y ago
    That's not always true, and with more and more hosts supporting key pinning technologies like DANE, it'll be less true with time. My mail server is set up to know that mail to Google domains (and others, like those hosted by Google or Microsoft) must be encrypted and the certificate must be correct. I occasionally look through my server logs to find more domains I can add to the list.
- andreasvc 11y ago
  If anything, a spammer or phiser has more motivation to deliver their mail over TLS because of this development, compared to some legitimate host. Whether the mail was delivered via TLS provides no information on its legitimacy. That is why it is problematic that it could give a false sense of security.
  - 11y ago
secabeen 11y ago
Can an attacker MitM a connection without changing the key fingerprint?
- scintill76 11y ago
  No, but the problem is that the SMTP specs don't define how to validate the cert -- for example, many deliveries will work with a self-signed certificate[0], so a MITM can just make a new certificate. [0] https://serverfault.com/questions/579138/is-it-ok-to-use-self-signed-certificates-for-smtp-transport https://serverfault.com/questions/579138/is-it-ok-to-use-sel...
  - jcrites 11y ago
    We're talking about deliveries to Gmail, and Gmail can decide what kind of client certificates count as authenticated when sending emails to Gmail. For example, they could establish the convention that the highest tier of lock icon requires a client certificate under the same domain name as the sender's address, verified by path validation of commonly trusted certificate authorities. A lower tier of lock icon might be a path-validated certificate of some kind, and the lowest tier might be a self-signed certificate - perhaps analogous to how tiers of HTTP and HTTPS are displayed. The proposal for "Secure SMTP using DNS-Based Authentication of Named Entities (DANE)" applies a similar strategy, though it's only for client authentication of the server certificate, not vice versa [1]. There was a proposal at one point to add client certificate requirements to the DMARC standard, though that work appears to have fizzled out. [1] https://tools.ietf.org/html/draft-ietf-dane-smtp-01 https://tools.ietf.org/html/draft-ietf-dane-smtp-01
    - scintill76 11y ago
      This is true, I forgot that element of context. If they do this, I hope they pick a "good" standard, and hope that nobody else applies a different standard (forcing senders to decide whose to use, or complicating their implementation to support both.)
jcrites 11y ago
I think this is a good move that establishes a useful foundation, building on the work that Google has done thus far in their Safer Email effort. The quality of the security depends on the implementation details, but being Google, I would expect the Gmail team to have considered these issues carefully, and to have a plan for the future. There are a number of short term and long term benefits. A few years ago, a significant majority of all email was transmitted in plaintext. Google's Safer Email Transparency Report called attention to this, and provided an incentive for ISPs to enable opportunistic TLS and increase their TLS percentage to 100%. This first step appears to have had a meaningful impact on the amount of TLS employed by large senders and ISPs. At this point, however, messages appear identically to email receivers, whether sent across TLS or not. This report alone was not enough motivation for all large senders and ISPs to employ TLS. Much like how websites with the "lock icon" have a privileged status in browser UIs, the next step of displaying the TLS status (or lack of TLS) in the UI will provide an incentive for senders to employ it. Employing more TLS today is a benefit even as things stand. Opportunistic TLS protects against passive eavesdropping, which is still a win, and it allows you to detect active MITM interception with scrutiny: MITM interception will leave a permanent trail in message metadata. Plus, one only needs to employ a basic degree of path validation to deter most casual MITM interception (based on self-signed certificates). Gmail could establish tiers of trust, analogous to the types of HTTPS lock icons, and require senders to use a properly path-validated client certificate from a generally trusted CA in order to achieve the highest degree of trust, analogous to the lock icons in HTTPS. The STARTTLS protocol anticipates this kind of authentication [1], but does not specify it: > Both the SMTP client and server must check the result of the TLS negotiation to see whether an acceptable degree of authentication and privacy was achieved. Ignoring this step completely invalidates using TLS for security. The decision about whether acceptable authentication or privacy was achieved is made locally, is implementation-dependent, and is beyond the scope of this document. I would expect Gmail to raise the bar over time. This initial effort creates an incentive to roll out opportunistic TLS, even if poorly implemented such as with self-signed certificates. Simply getting TLS in place universally will be a great starting point for further refinement. Over time, I'd expect to see additional features such as, perhaps: (1) incentives to use path-validated certificates from a trusted CA, over self-signed certificates (2) mechanisms for sending domains to declare what kind of certificate and TLS they'll use when sending, such that receivers can validate TLS connections and reject invalid client certificates. There was some talk in the past about adding this to the DMARC standard, but that fizzled out. There is another effort toward establishing a convention for this by applying DNS-based Authentication of Named Entities (DANE) to SMTP [2]. Although the existing DANE SMTP protocol only establishes a convention for server authentication and not client authentication, there is still value for senders, and I expect work to progress toward client authentication over time. Protocols aside, Gmail could also establish their own conventions, out-of-band mechanisms, or tiers of authentication, like browsers have for EV certificates. We might also see (3) better support for grappling with identity alignment, i.e., emails from example.com are expected to be sent across TLS using an example.com client certificate (perhaps not necessary given DKIM). In the interim, Gmail can add metadata to the message that captures the client certificate used to transmit the message. A security-conscious receiver can inspect those details, perhaps using a plugin or with a visual scan. It would not be so hard to build a plugin that pins certificates or expected CAs for popular domains, for example. To summarize, I think this is useful and is heading in the right direction. It's not a complete solution, but it's difficult to go directly from where email is today to a complete solution. [1] https://tools.ietf.org/html/rfc3207 https://tools.ietf.org/html/rfc3207 [2] https://tools.ietf.org/html/draft-ietf-dane-smtp-01 https://tools.ietf.org/html/draft-ietf-dane-smtp-01
rdl 11y ago
I'm happy about incrementally rolling this stuff out. STARTTLS for now. Surfacing that in the UI. Then maybe DANE, and in parallel some form of downgrade notification, or pinning, or something.
- agwa 11y ago
  I'm all for rolling out opportunistic STARTTLS, but I don't see how you can surface it in the UI in a way that's meaningful to the vast majority of users. If STARTTLS was not used, the message might have been intercepted. If STARTTLS was used, it's less likely it was intercepted, but it still easily could have been. (How much less likely? No one knows for sure.) How is this information helpful to users? Let's get things like DANE and pinning deployed first. Once Gmail can make a strong assertion that a message was securely delivered, then it can surface this information.
RexRollman 11y ago
I have to agree with this. Email is not a secure medium and this is just going to confuse people.

by agwa 11y ago

harshreality 11y ago

There's a way to fairly reliably mark messages as insecure when they're sent by clients that don't verify certs. For every incoming ssl smtps connection, google could forge a cert the first time it encounters a connection from a particular ip on a particular day. If the client continues with the ssl negotiation, google would know to mark the message as unsecure, because the sender isn't verifying certs. You could obviously adjust the frequency with which the recipient (eg google) tests each IP. It wouldn't have to be every 24 hours. You could also use additional heuristics to re-test, even going so far as to disconnect immediately and force the client to retry (giving it a forged cert test) if you trust the client ip but see a different helo than you saw last time. You could even use global bgp feed to invalidate any successful tests from a netblock when there's a visible routing change for it.

agwa 11y ago
If Gmail did this, the MitM would be sure to correctly validate Gmail's certs.
tedunangst 11y ago
Introducing spurious failures to improve security feels like one of those ideas likely to have unintended consequences.
cortesoft 11y ago
What would stop the MiTM from verifying Gmail's cert? Say, the email is sent in plain text, it is intercepted by the bad guy, then the bad guy sends it on to gmail encrypted, with cert checking and everything. I am failing to see what your proposal would help.

wyldfire 11y ago

99% of gmail users will never know that the feature exists until they see the warning. That can only have the benefit of encouraging the correspondent to get their provider(s) to enable the encryption. > stymies passive surveillance... presence or absence should never be communicated ... to avoid suckering them into a false sense of security. I think you're not giving enough weight to the first point. This really does provide an advantage for individuals who receive their password/reset url or some other credentials via email. At least it wouldn't be intercepted on that hop. Seems like the benefits outweigh the drawbacks.

agwa 11y ago
> At least it wouldn't be intercepted on that hop It wouldn't be passively intercepted. It could trivially be actively intercepted. Gmail would not display a warning in this case, thus making the user think their password/reset URL was safe when it really wasn't. And trying to inform users about the difference between passive and active interception, and expecting them to make a risk evaluation based on it, is just not realistic for the vast majority of users.
- andrewaylett 11y ago
  That's not always true, and with more and more hosts supporting key pinning technologies like DANE, it'll be less true with time. My mail server is set up to know that mail to Google domains (and others, like those hosted by Google or Microsoft) must be encrypted and the certificate must be correct. I occasionally look through my server logs to find more domains I can add to the list.
andreasvc 11y ago
If anything, a spammer or phiser has more motivation to deliver their mail over TLS because of this development, compared to some legitimate host. Whether the mail was delivered via TLS provides no information on its legitimacy. That is why it is problematic that it could give a false sense of security.
- 11y ago

secabeen 11y ago

Can an attacker MitM a connection without changing the key fingerprint?

scintill76 11y ago
No, but the problem is that the SMTP specs don't define how to validate the cert -- for example, many deliveries will work with a self-signed certificate[0], so a MITM can just make a new certificate. [0] https://serverfault.com/questions/579138/is-it-ok-to-use-self-signed-certificates-for-smtp-transport https://serverfault.com/questions/579138/is-it-ok-to-use-sel...
- jcrites 11y ago
  We're talking about deliveries to Gmail, and Gmail can decide what kind of client certificates count as authenticated when sending emails to Gmail. For example, they could establish the convention that the highest tier of lock icon requires a client certificate under the same domain name as the sender's address, verified by path validation of commonly trusted certificate authorities. A lower tier of lock icon might be a path-validated certificate of some kind, and the lowest tier might be a self-signed certificate - perhaps analogous to how tiers of HTTP and HTTPS are displayed. The proposal for "Secure SMTP using DNS-Based Authentication of Named Entities (DANE)" applies a similar strategy, though it's only for client authentication of the server certificate, not vice versa [1]. There was a proposal at one point to add client certificate requirements to the DMARC standard, though that work appears to have fizzled out. [1] https://tools.ietf.org/html/draft-ietf-dane-smtp-01 https://tools.ietf.org/html/draft-ietf-dane-smtp-01
  - scintill76 11y ago
    This is true, I forgot that element of context. If they do this, I hope they pick a "good" standard, and hope that nobody else applies a different standard (forcing senders to decide whose to use, or complicating their implementation to support both.)

jcrites 11y ago

I think this is a good move that establishes a useful foundation, building on the work that Google has done thus far in their Safer Email effort. The quality of the security depends on the implementation details, but being Google, I would expect the Gmail team to have considered these issues carefully, and to have a plan for the future. There are a number of short term and long term benefits. A few years ago, a significant majority of all email was transmitted in plaintext. Google's Safer Email Transparency Report called attention to this, and provided an incentive for ISPs to enable opportunistic TLS and increase their TLS percentage to 100%. This first step appears to have had a meaningful impact on the amount of TLS employed by large senders and ISPs. At this point, however, messages appear identically to email receivers, whether sent across TLS or not. This report alone was not enough motivation for all large senders and ISPs to employ TLS. Much like how websites with the "lock icon" have a privileged status in browser UIs, the next step of displaying the TLS status (or lack of TLS) in the UI will provide an incentive for senders to employ it. Employing more TLS today is a benefit even as things stand. Opportunistic TLS protects against passive eavesdropping, which is still a win, and it allows you to detect active MITM interception with scrutiny: MITM interception will leave a permanent trail in message metadata. Plus, one only needs to employ a basic degree of path validation to deter most casual MITM interception (based on self-signed certificates). Gmail could establish tiers of trust, analogous to the types of HTTPS lock icons, and require senders to use a properly path-validated client certificate from a generally trusted CA in order to achieve the highest degree of trust, analogous to the lock icons in HTTPS. The STARTTLS protocol anticipates this kind of authentication [1], but does not specify it: > Both the SMTP client and server must check the result of the TLS negotiation to see whether an acceptable degree of authentication and privacy was achieved. Ignoring this step completely invalidates using TLS for security. The decision about whether acceptable authentication or privacy was achieved is made locally, is implementation-dependent, and is beyond the scope of this document. I would expect Gmail to raise the bar over time. This initial effort creates an incentive to roll out opportunistic TLS, even if poorly implemented such as with self-signed certificates. Simply getting TLS in place universally will be a great starting point for further refinement. Over time, I'd expect to see additional features such as, perhaps: (1) incentives to use path-validated certificates from a trusted CA, over self-signed certificates (2) mechanisms for sending domains to declare what kind of certificate and TLS they'll use when sending, such that receivers can validate TLS connections and reject invalid client certificates. There was some talk in the past about adding this to the DMARC standard, but that fizzled out. There is another effort toward establishing a convention for this by applying DNS-based Authentication of Named Entities (DANE) to SMTP [2]. Although the existing DANE SMTP protocol only establishes a convention for server authentication and not client authentication, there is still value for senders, and I expect work to progress toward client authentication over time. Protocols aside, Gmail could also establish their own conventions, out-of-band mechanisms, or tiers of authentication, like browsers have for EV certificates. We might also see (3) better support for grappling with identity alignment, i.e., emails from example.com are expected to be sent across TLS using an example.com client certificate (perhaps not necessary given DKIM). In the interim, Gmail can add metadata to the message that captures the client certificate used to transmit the message. A security-conscious receiver can inspect those details, perhaps using a plugin or with a visual scan. It would not be so hard to build a plugin that pins certificates or expected CAs for popular domains, for example. To summarize, I think this is useful and is heading in the right direction. It's not a complete solution, but it's difficult to go directly from where email is today to a complete solution. [1] https://tools.ietf.org/html/rfc3207 https://tools.ietf.org/html/rfc3207 [2] https://tools.ietf.org/html/draft-ietf-dane-smtp-01 https://tools.ietf.org/html/draft-ietf-dane-smtp-01

rdl 11y ago

I'm happy about incrementally rolling this stuff out. STARTTLS for now. Surfacing that in the UI. Then maybe DANE, and in parallel some form of downgrade notification, or pinning, or something.

agwa 11y ago
I'm all for rolling out opportunistic STARTTLS, but I don't see how you can surface it in the UI in a way that's meaningful to the vast majority of users. If STARTTLS was not used, the message might have been intercepted. If STARTTLS was used, it's less likely it was intercepted, but it still easily could have been. (How much less likely? No one knows for sure.) How is this information helpful to users? Let's get things like DANE and pinning deployed first. Once Gmail can make a strong assertion that a message was securely delivered, then it can surface this information.

RexRollman 11y ago

I have to agree with this. Email is not a secure medium and this is just going to confuse people.