Is Google overreaching by forcing me to use TLS?

  • Gmail was recently changed to require HTTPS for everyone, whether they want to use it or not. While I realize that HTTPS is more secure, what if one doesn't care about security for certain accounts?

    Some have criticized Google for being Evil by forcing them into a secure connection even if they don't want to be secure. They argue that if it's just their own account, shouldn't they be the only one to decide whether or not to secure themselves?

    Note: This question was posted in reference to the article linked above in order to provide a canonical answer to the question being asked off-site (which is why it was answered by the same person who asked it).

    You might not want to secure yourself, but I can bet that 99% of other people want to be secure, especially when things like the NSA are still around. I mean I wouldn't like a stranger reading my Skype conversations - they are private. That's why we have them over the internet and not somewhere public. I wouldn't like some stranger on the other side of the world to read my emails. I often have a lot of sensitive emails that are very personal (not in that way! ;) .

    Sometimes security can be enforced. HTTPS is an example for this. Although not perfect, it is far much better than pure HTTP. It basically costs nothing, and makes bulk surveillance harder. There were even thoughts for HTTP 2.0 to be SSL only.

    Is Google overreaching by forcing you to log in with a password?

    I̶s̶ ̶g̶o̶o̶g̶l̶e̶ ̶E̶v̶i̶l̶ ̶f̶o̶r̶ ̶f̶o̶r̶c̶i̶n̶g̶ ̶y̶o̶u̶ ̶t̶o̶ ̶u̶s̶e̶ ̶H̶T̶M̶L̶?̶ ̶O̶r̶ ̶a̶ ̶b̶r̶o̶w̶s̶e̶r̶?̶ ̶O̶r̶,̶ ̶s̶a̶y̶,̶ ̶t̶h̶e̶ ̶i̶n̶t̶e̶r̶n̶e̶t̶?̶ ̶ U̶n̶f̶o̶r̶t̶u̶n̶a̶t̶e̶l̶y̶ ̶I̶ ̶f̶i̶n̶d̶ ̶t̶h̶a̶t̶ ̶t̶h̶i̶s̶ ̶q̶u̶e̶s̶t̶i̶o̶n̶ ̶d̶o̶e̶s̶n̶'̶t̶ ̶m̶a̶k̶e̶ ̶m̶u̶c̶h̶ ̶s̶e̶n̶s̶e̶.̶.̶. I didn't read your answer. The question didn't make much sense until I realized that you might wonder it and then wanted to answer it, so you had to ask it first (;

    You probably don't care about your online privacy but other people do, even with TLS google (or any third party that use SSL/TLS) can get access to your account coz they have the key used for encryption.

    Is the government overreaching you for requiring you to wear a seatbelt while driving?

    In order for this to be "evil", you'd have to argue that it causes some kind of harm.

    @JeffGohlke: But someone have to pick up the body parts, so I can understand that decision. And that person did nothing wrong, it's his job.

    I want the option to jump of the plane esp. when I have a parachute and know I am going to land on land.

    @Shiki That's a bit of a specious argument. I can use your logic to ban any human behavior. Everyone has right and power over their own life. Regardless, the original example actually isn't relevant to the question at hand. A government is in a different position than a business, and I actually do pay for roads and police officers by paying taxes, whereas a Google user is receiving a free service and thus needs to "vote" based on which services they decide to use. If you hate that Google makes you use TLS, use Yahoo! or some other service. That's how business works.

    Personally, I welcome this change. I was pleasantly surprised when Search (i.e. ``) loaded over TLS on a Chromebook that was connected to a network that used the `nossl.` subdomain. Frankly, if every website suddenly started forcing TLS (_good_ TLS; 1.1 or better and with forward secrecy), I would be a lot happier. \*mumbles something about no mainstream browser having a built-in force-TLS feature\*

    I don't get this question... Why would anyone object against better security?

    Yes, Google is being evil by forcing you to use a transaction based protocol like http, and by extension https, for a session based application like their email service. Any session based service should use a persistent connection rather than http; Google should clearly provide their email service over straight TLS instead of https.

    How is this question different from, say, *Slashdot is forcing me to use TCP/IP and HTTP to talk to them. Or this amber-screened WYSE terminal is forcing me to use an RS-232 cable to hook up to the computer. Or this fast-food worker insists on taking orders only in English.* (I'm not being sarcastic; someone point it out to me. Is it because it involves a security mechanism?)

    When you opt out of reasonable security measures, make sure to make that very clear to everybody in your contacts: "I object to protecting your data. Be aware if you send me any mail with personal information. Not only will Google have full access to that data, but also any person who listens to my unencrypted interaction with Google's servers". It's not only *your* data, dude!

    I'm surprised about the comments on alleged online privacy when in fact Google is not only actively abusing your emails but also actively forwarding them to US agencies (which isn't their fault, they have little choice). TLS may prevent that 14 year old kid from Kiev reading your mail, but the people you should worry about, the really vicious ones, are getting everything anyway. Online privacy is an illusion.

    @Damon That's actually a really, really good point. I'm surprised it hasn't been brought up in this entire discussion yet. I guess the "illusion of privacy" actually works.

    There is one argument against `https`. The handshake is significantly slower on networks far from the USA, and on low-spec computers. That might be part of the reason why StackExchange have kept their pages on the nippier http.

    @joeytwiddle SE is moving toward https everywhere. They've got it working in many areas but it's still in progress. The biggest problem is that an https page requires all assets (including third-party) to be delivered via https as well. This can be problematic with inlined images and such.

    {Tinfoil Hat on}: Google made use of He*rtbl**d to get some data from the users' browsers. {Tinfoil Hat off}, no idea why they'd do it since they've got everybody by the so-and-so's already without extra tricks.

  • It's not just about you. By forcing users to use TLS, they're creating a more secure environment for everyone.

    Without TLS being strictly enforced, users are susceptible to attacks such as sslstrip. Essentially, making unencrypted connections an option leads to the possibility of attackers forcing users into unencrypted connections.

    But that's not all. Requiring TLS is the first step in moving toward HSTS enforcement on the domain. Google already does opportunistic HSTS enforcement -- which is to say that they don't require TLS, but they do restrict which certificates are allowed to be used on (nb: this technique is now called HPKP). That's an improvement, but it's not ultimately a solution.

    For full HSTS enforcement, they need to ensure that requiring TLS on all Google services within the domain won't break any necessarily third-party solutions. Once enforcement is turned on, it can't easily be turned off. So by moving services one-by-one to strict TLS enforcement, they are paving the way toward making HSTS enforcement across the domain a reality.

    Once this enforcement is in place, browsers will simply refuse to connect to Google over an insecure or compromised connection. By shipping this setting in the browser itself, circumvention will become effectively impossible.

    Disclaimer: I work for Google now but I didn't work for Google when I wrote this. This is my opinion, not Google's (as should be immediately clear to anyone with a basic understanding of chronology).

    *It's not just about you.* Shouldn't this be *It's not just about me.*

    @VarunAgw it parses better this way. An conversation between two different people is mentally easier to follow than a confused monologue.

    This is similar to how being immunized from a disease helps everyone (by no longer being able to contract the disease from you), not just yourself.

    One of the reasons cited for using unencrypted connections in said article is performance. You could improve your answer by mentioning that Google services vs. Chrome browser are likely to use SPDY, which by construction avoids many of the performance drawbacks that HTTPS has. There will be only one encrypted channel which is being multiplexed across all connections, so all the negotiation overhead and TCP slowstart are gone.

    I have a question about the technical aspect of your answer. How does this prevent techniques like sslstrip? As a man in the middle, can't you still connect to Google via TLS, but act as a HTTP server without SSL to serve Google in an unencrypted form? Maybe you would have to strip out some Javascript as well that checks for TLS on the client side. I don't see how you could prevent that type of attack, if the browser itself does not have a builtin rule like "never visit without TLS" But as long as HSTS is not supported, this is not going to happen

    Not only are users protected, but Google is protected from being used as a tool for malicious purposes. I.e. if Google allowed non-secure connections, and accounts were compromised as a result, then those accounts could be used to launch phishing email campaigns, malware distribution, or other scams from those gmail accounts. One could debate whether Google was "evil"/liable for allowing its user base to operate accounts in an insecure manner that permitted such events to take place.

    This is such a tacky answer. If someone has control of your upstream, they can do whatever they want. Either your browser accepts it all, or gives you an error message. In case of Google, they still support HTTP for Google Search, BTW.

  • Let me rephrase your question with a few extra details, which are implicit but maybe not obvious to everybody:

    "Isn't Google being Evil by providing me with a free email service and gigabytes of storage and forcing me into a secure connection when I access that service which they have generously granted to me and that nobody forces me to use even if I don't want to be secure? If it's just my own account on their servers and given to me free of charge, based only to their usage terms to which I have agreed, shouldn't I be the only one to decide what should happen with THEIR servers and whether or not to secure myself with a technology whose costs are entirely on the server side and with no actual disadvantage to me ?"

    Truly, the nerve they have at Google !

    Commentary: reactions against Google in that respect look like knee-jerk reflexes: automatic, imperfectly targeted, and not involving any brain at all.

    **EVIL**. That's what dey ar. Givin me free stuff and makin sure I stay safe. That's the Devil's bargain, that is.

    Whether the service is free or not (and if you think about it, gmail is not free - the transaction simply doesn't involve $s) has nothing to do with the question. The question is simply whether it is good or bad that HTTPS is required and not left to users' choice. Free or not has nothing to do with it. The question seems perfectly valid (sans 'evil' reference, albeit 'evil' being grounded in not-so-subtle reference to Google's don't be evil and allowing users to have control over their data).

    @LB2: what matters is that there is a transaction: you use Gmail based on agreed-upon terms of usage. The lack of money exchange means that the user lacks leverage to dictate his own conditions. The underlying tone is that people often forget that Google is not a public service that they are _entitled_ to use, on their own terms.

    @TomLeek I agree with you! It is a transaction; is quite opposite when you answer "_providing me with a free email service_". It is a transaction and means user is giving up _something_ in exchange for something. Paying $0 vs $1 gives equivalently the same iota of leverage or ability to use on "_their own terms_", and my argument is that it's _contextually_ irrelevant. Evil remarks notwithstanding, I read OPs post as "why Google wouldn't allow http access and leave user's own security to his discretion?" (to which my answer is necessity to keep everyone secure, and is a good thing).

    Google isn't free? Please edit. I pay for Google like most online services by being bombarded with adds. Some services allow a paid version without adds including Google though enterprise licensing.

    @DeanMeehan You pay to view ads?

    @Brian payment isn't necessarily in cash

    "If you are not paying for the service, you are the product"

    Nice answer – love the irony!

    @Brian I pay **by** viewing adds

    @DeanMeehan Having ads on the services that you use costs you nothing, therefore you are not paying. YouTube ads before videos, which cost you time, are the exception.

    @Brian It also costs 'time' looking a webpage based adds. the only difference between website adds and video adds is a website add contains 1 frame taking less time to get their message along. That 1/2 second of my time costs me time, costs the advertiser money and makes the webmaster $$$

    Google is evil, although not because of this policy in particular. They're evil because of the abomination they've created called "Android".

    HTTPS is not all server-side: if it was all server-side you wouldn't be able to complete the secure connection to your computer. All HTTPS protocols require cryptographic computations on the end-user machine. Even with SPDY you still need to do crypto on the secure data, albeit withless overhead.

    Now I know what the "evil" Black Company of The Long Earth series reminded me of...

  • If Google wants the content of their servers to be transferred securely, that is entirely within their discretion, even if that content is your email box.

  • In fact, no, Google is not evil with this, not at all.

    The first important thing about this is that the use of secure connection is not a user preference or some personalized setting. Some people might find this confusing because they are familiar with a system only from the position of an end-user. Being a software developer myself, I can tell you that security is done on application level and affects all users of the system. There is no way to technically enforce authentication security based on user choice without compromising the security of the entire system and all the other users, most of whom might rely on the system's protection of their data. Yet, if it is possible, I'd surely like to know how.

    The logical choice for Google, as a public service provider, is to establish a secure environment for all of its users. It is not for the sake of security for the users only, but for the company too. Imagine, if someone becomes a victim of a security breach, and fires a lawsuit against Google, and proves that it is them who are responsible? This could be the case if they did not take the standard measures to protect the user data, and could have to face an entire community of angry users in court. Not using HTTPS is an example for such a thing - anyone can intercept your web request and see the information as a plain text. Google's user data is sensible. It seems like a simple email address and a password, but these two items form a key to all your contacts, correspondence and personalized Google services.

    Moreover, Google is an OpenID provider, which means the same user password (the one of the Google account) can be used to authenticate to external systems (like the sites in the StackExchange network, including this one, YouTube, Disqus, Picasa and many other popular systems). It is hard for me to imagine that one would prefer to have his "key" to so many accounts and services being unsecured.

    In general, this is a measure of technical requirements, rather than enforcement over user preferences. I, personally, would never trust a system that does not enforce the minimal security conditions like secure connection and authentication, when it comes to email, online payments and other services working with my private data.

  • Evil for forcing you to use a secure connection?

    No, I don't think it's evil. It protects the community at large with no downside to you as an individual.

    I think its only evil if they're forcing you to use SSL/TLS, then failing to use forward secrecy, thus giving you and everyone else using the service a false sense of security.

    Without forward secrecy, your session can be archived for an indeterminate length of time, the private key later obtained (via whatever means; social engineering, theft, government) and your long-ago session decrypted.

    With forward secrecy and ephemeral keys, that concern is seriously mitigated.

    Who can enumerate the downsides of using a SSL/TLS connection? Anyone? :-)

    There can be performance issues, but really only if the website is badly designed so that it requires lots and lots of fresh connections to serve content from a page. That kind of design will have a serious negative impact on a regular non-secure HTTP session, too.

    The performance hit from HTTPS is virtually all in the connection handshake since it takes more round trips and a little bit of compute-intensive asymmetrical ciphering to gin up the symmetrical session key on the server and decrypt it on the client (asymmetrical encryption is real expensive compared to symmetrical encryption).

    The compute cost of encrypting and decrypting the actual session data with a symmetrical cipher after the initial key exchange is negligible.

    What does an enforced SSL/TLS session cost you? Offhand, I honestly don't believe there is a measurable cost to you.

    One cost to me is that it is a could be a move towards enforcing TLS everywhere. I do not like unnecessary layers.

    On the other hand, a lot of people believe more widespread use of secure HTTP is a good idea, or put another way that SSL/TLS may well be a *necessary* layer. Any time any service requires credentials, the credentials must be protected with SSL/TLS. If authentication is secure, then the entire session needs to be secure (MIM attacks). Using SSL/TLS to protect authentication, then passing an unsecured auth token back and forth afterward is an error, good that Google stopped doing it. SSL/TLS is already in your browser. Using a secure site doesn't complicate your life. It should become the norm.

    Certificates have historically cost too much, and there's a little setup required on the server side, but as the market grows, the price will drop. I'm not a fan of punishing people who don't secure their servers, but an unsecured server is wide open to all kinds of spoofing and main-in-the-middle situations that a secured server naturally protects against.

    necessary on a lot of sites definitely. Should Google (or anyone) be trying to force it on *the entire Internet*? Almost certainly not. Is Google trying to do that? I don't know, but if they are then this is a step in that direction. There is evidence that they do want to force it on the entire Internet - see Chrome rejecting non-TLS HTTP/2.0 connections. Maybe I'm just too paranoid.

    for some reason the site won't accept @Craig in the previous comment, so here's another ping.

    @immibis I don't necessarily trust everything they might be up to, but I do think that to a large degree Google (and Microsoft and Yahoo and others) are doing this in reaction to things like the ongoing NSA spying saga and issues around FISA requests where they have been compelled to hand over lots and lots of data without being permitted to notify the owners of the data. They are, at least in name, pushing for better security and privacy for the unwashed masses. I don't necessarily think *Google* is pushing for "HTTPS everywhere," but some people in government definitely are.

    @immibis, they are out there to get you buddy.

    @immibis it's not just Google that is pushing for the entire Internet to be on TLS - so is the EFF, Mozilla, Microsoft... many other large companies. in fact, the IETF is considering/has considered making TLS a required part of the HTTP/2.0 spec. I never looked at the outcome of that, but last I heard they were going to make a strong recommendation for it, and only recommend turning it off in known-safe environments (e.g. corporate intranets).

    @strugee true, however computational expense isn't the only relevant factor. Network latency is a big issue that has to be taken into account. HTTPS requires twice as many round trips per session as HTTP to establish the connection. If your ping time is 50ms, it takes close to a quarater second to establish an HTTPS connection due to round-trip latency alone. That's why it is so important to re-use connections, combine scripts and css files, use css sprites instead of lots of requests for small images, and so on. All of these methods would dramatically speed up HTTP pages, as well. Win win.

    also, public service announcement: TLS is not computationally expensive anymore. and it hasn't been for a long time.

    of course, HTTP/2.0, IIRC, can reuse TLS/TCP connections for multiple HTTP requests. right? so the "multiple resources" thing doesn't really apply. (I may be wrong about reuse, though. I'm not entirely sure.)

    Multiple requests will still slow you down. Worse, though, is a requests full of requests to other sites (analytics JavaScript includes, anyone?), because each of *those* connections requires a fresh HTTPS connection. It's unconscionable for people not to at least be loading those kinds of scripts asynchronously.

    @strugee Just an observation, but that article makes the claim that "modern" hardware can do 1,500 handshakes per second per core, using 1024 bit keys. But 1024 bit keys are not only considered to be too weak now, you can't even get SSL/TLS certs with keys that small. Bigger keys = slower asymmetrical ops. That doesn't invalidate your argument; just another factor.,, etc.

    @Craig no need to convince me, I'm well aware of the move to 2048-bit keys. I certaintly cannot claim to be an expert; I'm just pointing out a different side of the topic.

    @strugee I appreciate it--you do realize I'm advocating in *favor* of SSL/TLS, right? :-) Still, 2,048 bit certs require 4 times more CPU than 1,024 bit certs. So the 1,500 handshakes per second with 1,024 bit keys drops to 375 handshakes per second with 2,048 bit keys. That's not nothing. Yes, the HTTP 2.0 spec allows for HTTP keep alives, but that doesn't mean they always get used, and all the other arguments about consolidating CSS and script content, using CSS sprites and otherwise taking steps to minimize the number of requests make a real difference over HTTP, *doubly* so for HTTPS.

    @Craig yes, I do realize that. but I enjoy a good technical debate as much as the next guy :D. and yes, of course all that stuff should be done. I'm fully on board with minification and all that (so long as you can see source, for the copyleftist in me).

    @Craig my ping time to many servers (tested,,,,,, is on the order of 200 to 400 ms. ~40ms to, presumably because that's using a server geographically near me, but the vast majority of sites can't afford to have servers everywhere.

    also, apart from the latency problem, I only oppose TLS everywhere for the same reason I oppose any standard changing - like Microsoft wanting devs to switch from GDI to GDI+ to WinForms to WPF to HTML5 to Metro (I'm sure that sequence of technologies is wrong, but that's not the point).

    @immibis things change-just the way it is. HTTPS is not a different standard from HTTP, though. It's just a little additional transport config on the server, and is not *gratuitous* change, and it radically improves security. Also, I'm sticking to my guns on the whole issue of latency having severe effects on HTTP as well. I have apps running over HTTPS that are crazy fast compared to other apps I've seen running over HTTP. I think the latency thing is a red herring and an excuse for continuing to tolerate bad design. I'm just saying that it *is* an issue to bear in mind during design.

    Also, consider the advanced in hardware. When the web was just starting to become a public thing, a *screaming* fast brand-new machine was a 60 or 66Mhz single-core Pentium. The clock speed of a typical server CPU is at least 40 times that today, plus radical advances in CPU technology (super pipelining, RISC features, etc.) that enable today's CPU's to run many more instructions per clock cycle, **plus** the fact that the CPU's are all multi-core. Intel is shipping 12 core Xeon CPUs with hyperthreading (24 threads) now, and that will only increase.

    Plus you have the possibility of using massively parallel GPUs or custom ASICs in servers to make light work of the crypto computations. Yes, the newest Xeon CPU's are expensive, but people can increasingly host their apps on VPS services like AWS or Azure (and a number of others) where they just pay for time instead of paying for their own hardware (expensive and rapidly outdated) and paying for co-location (also not cheap). Imagine $5,000 for 25 months of a VPS service at $200/month, or $5,000 for a beefy new server, plus co-location or ISP charges.

    Now, cloud service security is its own separate topic!! :-)

    What if there was a DNS record class to specify whether TLS should always be used on that domain?

    Well, there *is* HSTS

  • It's sad that people's first reaction is to defend Google by using the "you don't HAVE to use it" fallacy. As for transaction of money, don't you think your own personal information which they sell to advertisers has monitory value? Google isn't free, it still requires a payment which most people don't even realize they are making.

    Now, to answer the question, I don't think they are overreaching or "evil" for doing this. What if you look up information which could harm others if it's leaked (e.g. Googling something like "how do i treat my daughter's herpes"), or what if you're sending an email to another person who DOES want to be secured. Should it be up to you whether or not what THEY send is encrypted on your end? You may not care about security, but other people do, and it's only end-to-end if both ends actually enforce security. However, I would prefer if Google gave a method to use non-TLS connections if there are still devices which use Google but which are too memory/resource/entropy starved to establish a secure connection.

    +1 for mentioning that no, software companies don't give you free services out of their kind natures and gentle hearts. They want to make a profit, and you don't owe them anything for that. You're free to make any demands you please, even if they are as preposterous as this one, and they are free to refuse.

  • Google not only protects you and your data, but also themselves.

    The vast majority of internet users out there does not know about security, and does not care about. When offering any insecure path as fallback, user's would use it, and if it is some man-in-the-middle breaking everything else.

    If your account is compromised, that's not only a problem for you and your data, but also for google:

    • Spam mails might be sent using their services
    • Google's credibility for authentication (single sign on) will suffer
    • An attacker might misuse services, leading to costs (for Google) they might not be able to get compensation for
    • Recovering the account for you will require manual interaction, which involves costs

    Security can also be a matter of saving money.

    also, the possibility of lawsuits, as mentioned in other answers.

  • Was Google evil for requiring you to use the HTTP protocol instead of the Gopher protocol? I don't think most people would argue that it was. But if requiring the use of one protocol over another is not evil, then why would it be evil in this particular case: wrapping SSL around HTTP?

  • Googles hands are tied. Google arent just doing it to protect you. They are doing it to protect themselves. They dont want other people to mess with your stuff because they are carrying it for you, and they have a whole lot of legal obligations that come with hosting other peoples stuff. They are obligated to prevent any account being used in a way that makes a problem for others.

  • As others say, normally you have nothing to lose by using encryption instead of non-encryption, even if you think you don't need encryption.

    But if you really want to access it non-encrypted (perhaps to prove to someone observing your line that you are doing nothing evil), you could set up some HTTP server, which itself connects to Google by HTTPS, and forward all requests and responses (suitably adapted).

    You should modify the logo and some of the text so it doesn't look like you are directly using Google. And you should think about using HTTPS at least for the login procedure.

    This should work for every "evil" server which only supports HTTPS.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM