8 ms·
Gmail Will Soon Warn Users When Emails Arrive Over Unencrypted Connections
- lwh 11y agoYou mean without PGP right?
- ChrisCinelli 11y agoA step in the right direction!
- daryltucker 11y agoBut they force XMPP/Jabber s2s connections to be in the clear? smh
- d0ugie 11y agoLooking forward to seeing Chrome marking HTTP as not secure.. https://plus.google.com/+FrancoisBeaufort/posts/TaTACsJSnjN https://plus.google.com/+FrancoisBeaufort/posts/TaTACsJSnjN
- agwa 11y agoThis 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 agoThere'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 agoIf Gmail did this, the MitM would be sure to correctly validate Gmail's certs.
- tedunangst 11y agoIntroducing spurious failures to improve security feels like one of those ideas likely to have unintended consequences.
- cortesoft 11y agoWhat 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 ago99% 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 agoThat'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 agoIf 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 agoCan an attacker MitM a connection without changing the key fingerprint?
- scintill76 11y agoNo, 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 agoWe'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 agoThis 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 agoI 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 agoI'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 agoI'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 agoI have to agree with this. Email is not a secure medium and this is just going to confuse people.
- Someone1234 11y agoWhat depresses me is that many organisations agree that SMTP needs some work. However the stakeholders simply don't care enough to do anything about it, all Google is doing here is adding a pretty little icon for opportunistic encryption (that doesn't work very well). Let's look at the biggest stakeholders in SMTP: - Microsoft: Exchange (8% mail servers), Outlook (client), Outlook.com (23% of webmail). - Google: Gmail & Google Apps (40% of webmail) - Yahoo (21% of webmail) - OSS: Sendmail, Postfix So if Google, Microsoft, and Yahoo! signed up that is the majority of SMTP on the internet today. Then we find some funds to get OSS updated (or summer of code), and boom, we have an SMTP update fit for 2015. Heck have it downgrade for right now, and we can talk about actually switching over in 2025 or whatever. But at least in 2025 we'll have something ready, the longer we take to kick this off the longer it will take to upgrade. It is utterly insane that nothing is moving here. It is like SMTP is stuck in a perpetual IE 6 situation, and Microsoft is largely causing it all over again (Exchange + Outlook.com).
- yid 11y ago> However the stakeholders simply don't care enough to do anything about it, Perhaps that's a sign that "it" (smtp) now works well enough with the decades of engineering investment put into spam detection, access, standardization and inter-operability that have been put into it to not justify the massive investment that an "SMTP update fit for 2015" would involve.
- mschuster91 11y ago> spam detection, access, standardization and inter-operability Spam detection works on a higher level than transport security, it is independent from transport (although a spam classifier might favor mails from SMTP servers sent with SSL and a client certificate signed by a CA for its domain name). Access... well, that's IMAP/POP3's job, both support SSL for ages. Standardization/interop, uh we already have SMTPS. The standard is there, what's lacking is support for inter-server encryption.
- darkr 11y ago
- Spoom 11y agoThis is a great marketing move, because users have absolutely no control over the flow that their email takes... except to tell the other user to start using Gmail.
- widforss 11y agoI will soon warn my users when they're recieving an email that is not PGP-encrypted.
- mtgx 11y agoIs Google's End-to-End extension still progressing? Or are they hoping we forgot about it?
- workitout 11y agoI use Postfix, I'll have to check how it makes outgoing connections but I'd assume it's unencrypted. My client connection to my server is encrypted but never thought to use it for the connections to the servers my server delivers mail to.
- baudehlo 11y agoYou have to install a certificate if you want it to be encrypted.
- Wicher 11y ago#opportunistic encryption s2s smtp_tls_security_level = may smtp_tls_CApath = /etc/ssl/certs This will use STARTTLS to upgrade the connection. This does not protect you against an active attacker, but it will protect you against passive eavesdropping (~mass surveillance).
- workitout 11y agoThanks Wicher and baudehlo, great tips.
- bqe 11y agoGmail will warn users for this, but not for soft failing SPF. That doesn't make sense.
- tiatia 11y agoYou should not use Gmail anyway. Privacy issues and security issues. I still have several Gmail accounts. Daily warnings in my Thunderbird (Someone has your password....--- Yes, guess fucker, it is me who has my password). I have one Gmail account that I can not access anymore besides knowing my password, the previous password and a security question. Unfortunately I have a domain registered with this email. This domain may be lost. Pay a few bucks and get your own email. External email, hosted in Switzerland (high privacy, not EU or US jurisdiction) costs me 15 Euro per year. I can use my own (even external!) domain.
- tiatia 11y agoA minus -3 downvote for this post? I mean, really? You must really be some google cock-sucking mf.... I doubt that Schneier uses Gmail. Repeat after me: Gmail is a serious privacy and security risk. The looser that I am I spent 15 Euro a year to host my email in Switzerland. And if shit hits the van I CALL THEM. Have you ever tried calling google?
- zo1 11y ago>"The looser that I am I spent 15 Euro a year to host my email in Switzerland. And if shit hits the van I CALL THEM. Have you ever tried calling google?" If you have to call your email provider, there is something seriously wrong, and you should probably move to another provider.
- tiatia 11y agoI never called them. But I could if I wanted to and if there would be a problem. And I have a problem with a Gmail account. How do you call google? How do you email google?
- smackfu 11y agoSo the security issue is that they are too secure?
- y0ghur7_xxx 11y agoThis Thunderbird addon does the same, if you prefer a local client: https://addons.mozilla.org/en-us/thunderbird/addon/paranoia/ https://addons.mozilla.org/en-us/thunderbird/addon/paranoia/