75

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).

tylerl
  • 82,225
  • 25
  • 148
  • 226
  • 5
    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! ;) . – George Mar 25 '14 at 21:36
  • 5
    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. – Karol Babioch Mar 26 '14 at 00:06
  • 143
    Is Google overreaching by forcing you to log in with a password? – Stephen Touset Mar 26 '14 at 00:16
  • 1
    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 (; – Francisco Presencia Mar 26 '14 at 04:24
  • Is the government overreaching you for requiring you to wear a seatbelt while driving? – Shadur Mar 26 '14 at 11:30
  • 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. – ismael Mar 26 '14 at 10:31
  • 24
    In order for this to be "evil", you'd have to argue that it causes some kind of harm. – pjc50 Mar 27 '14 at 10:27
  • 3
    @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. – Apache Mar 27 '14 at 14:07
  • 1
    I want the option to jump of the plane esp. when I have a parachute and know I am going to land on land. – numan Mar 27 '14 at 14:13
  • 4
    @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. – asteri Mar 27 '14 at 14:15
  • 3
    Personally, I welcome this change. I was pleasantly surprised when Search (i.e. `https://www.google.com/`) 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](https://security.stackexchange.com/a/54233/42192)), I would be a lot happier. \*mumbles something about no mainstream browser having a built-in force-TLS feature\* – Blacklight Shining Mar 29 '14 at 05:07
  • I don't get this question... Why would anyone object against better security? – Populus Mar 31 '14 at 15:13
  • 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. – Warren Dew Apr 01 '14 at 03:09
  • 2
    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?) – Kaz Apr 01 '14 at 05:05
  • 1
    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! – Raphael Apr 01 '14 at 08:00
  • 1
    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 Apr 01 '14 at 08:27
  • @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. – asteri Apr 01 '14 at 14:46
  • 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 Apr 02 '14 at 11:51
  • @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. – tylerl Apr 02 '14 at 17:25
  • {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. – Deer Hunter Apr 09 '14 at 07:41

12 Answers12

170

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 google.com 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 Google.com (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).

tylerl
  • 82,225
  • 25
  • 148
  • 226
  • 6
    *It's not just about you.* Shouldn't this be *It's not just about me.* – VarunAgw Mar 27 '14 at 18:17
  • 10
    @VarunAgw it parses better this way. An conversation between two different people is mentally easier to follow than a confused monologue. – tylerl Mar 27 '14 at 18:23
  • 3
    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. – asmeurer Mar 27 '14 at 20:31
  • 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. – Isotopp Mar 28 '14 at 08:19
  • 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 google.com without TLS" But as long as HSTS is not supported, this is not going to happen – Niklas B. Mar 30 '14 at 15:49
  • 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. – AaronLS Apr 01 '14 at 12:00
  • +1 for [HSTS](https://www.owasp.org/index.php/HTTP_Strict_Transport_Security) – Craig Tullis Apr 01 '14 at 19:50
  • 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. – cnst Jan 20 '20 at 21:27
89

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.

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • 38
    **EVIL**. That's what dey ar. Givin me free stuff and makin sure I stay safe. That's the Devil's bargain, that is. – tylerl Mar 25 '14 at 20:57
  • 7
    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 Mar 25 '14 at 21:06
  • 8
    @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. – Tom Leek Mar 25 '14 at 21:59
  • @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). – LB2 Mar 25 '14 at 22:19
  • 5
    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. – Dean Meehan Mar 26 '14 at 17:02
  • 1
    @DeanMeehan You pay to view ads? – Brian Mar 26 '14 at 19:32
  • 1
    @Brian payment isn't necessarily in cash – user253751 Mar 27 '14 at 04:57
  • 15
    "If you are not paying for the service, you are the product" – Liasssa Lurkrof Mar 27 '14 at 13:59
  • Nice answer – love the irony! – e-sushi Mar 27 '14 at 20:22
  • 2
    @Brian I pay **by** viewing adds – Dean Meehan Mar 28 '14 at 11:17
  • @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 Mar 28 '14 at 13:47
  • @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 $$$ – Dean Meehan Mar 28 '14 at 14:44
  • 1
    Google is evil, although not because of this policy in particular. They're evil because of the abomination they've created called "Android". – SSH This Mar 28 '14 at 21:41
  • 1
    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. – machine yearning Mar 30 '14 at 03:45
  • Now I know what the "evil" Black Company of The Long Earth series reminded me of... – Tobias Kienzler Apr 02 '14 at 11:27
18

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.

Brian
  • 281
  • 2
  • 7
14

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.

Ivaylo Slavov
  • 241
  • 1
  • 5
11

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.

Craig Tullis
  • 1,483
  • 10
  • 13
  • One cost to me is that it is a could be a move towards enforcing TLS everywhere. I do not like unnecessary layers. – user253751 Mar 27 '14 at 01:17
  • 2
    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. – Craig Tullis Mar 27 '14 at 03:56
  • 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. – Craig Tullis Mar 27 '14 at 03:57
  • 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. – user253751 Mar 27 '14 at 04:53
  • for some reason the site won't accept @Craig in the previous comment, so here's another ping. – user253751 Mar 27 '14 at 04:57
  • @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. – Craig Tullis Mar 27 '14 at 05:16
  • 2
    @immibis, they are out there to get you buddy. – OneOfOne Mar 28 '14 at 12:22
  • 1
    @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 Mar 30 '14 at 02:00
  • also, public service announcement: TLS is not computationally expensive anymore. and it hasn't been for a long time. https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html – strugee Mar 30 '14 at 02:04
  • 2
    @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. – Craig Tullis Mar 30 '14 at 03:02
  • 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.) – strugee Mar 30 '14 at 03:05
  • 2
    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. – Craig Tullis Mar 30 '14 at 03:10
  • @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. http://www.networking4all.com/en/ssl+certificates/ssl+news/your+1024-bit+ssl+certificate+will+no+longer+work+after+october+1st+2013/, https://www.google.com/#newwindow=1&q=1024%20bit%20vs%202048%20bit%20certificates, etc. – Craig Tullis Mar 30 '14 at 03:25
  • @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 Mar 30 '14 at 06:00
  • @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 Tullis Mar 30 '14 at 06:14
  • @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). – strugee Mar 30 '14 at 06:17
  • @Craig my ping time to many servers (tested stackoverflow.com, imgur.com, reddit.com, mit.edu, facebook.com, tvtropes.org, dropbox.com) is on the order of 200 to 400 ms. ~40ms to google.com, presumably because that's using a server geographically near me, but the vast majority of sites can't afford to have servers everywhere. – user253751 Mar 30 '14 at 06:52
  • 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). – user253751 Mar 30 '14 at 07:04
  • @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. – Craig Tullis Mar 30 '14 at 17:07
  • 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. – Craig Tullis Mar 30 '14 at 17:19
  • 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. – Craig Tullis Mar 30 '14 at 17:25
  • Now, cloud service security is its own separate topic!! :-) – Craig Tullis Mar 30 '14 at 17:27
  • What if there was a DNS record class to specify whether TLS should always be used on that domain? – user253751 Mar 30 '14 at 20:07
  • Well, there *is* [HSTS](https://www.owasp.org/index.php/HTTP_Strict_Transport_Security) – Craig Tullis Apr 01 '14 at 19:48
8

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.

Guest dude
  • 91
  • 1
  • 2
    +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. – GregRos Mar 29 '14 at 00:14
8

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.

Jens Erat
  • 23,446
  • 12
  • 72
  • 96
4

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?

The Spooniest
  • 1,637
  • 9
  • 10
3

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.

2

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.

Paŭlo Ebermann
  • 2,467
  • 19
  • 20
1

TL;DR: It's better, but it's not good enough.

The chance of having a tapped connection versus the costs of this type of security are obvious and require no further consideration than "yes this is required".

It is vital to remember that SSL might not be perfect and the implementations are very unlikely to be waterproof. Additionally, especially in a case like Google, your privacy and letter-secret is not preserved by using SSL.

Effectively the only risk that Google prevents is forms of espionage by actors not powerful enough to subvert your computer, Google or SSL. It might also increase the effort for other actors.

It does not prevent all kinds of SSLStrip, as SSLstrip can do in transit reworking or even redirects. A common user won't notice the lack of a little SSL lock. A little extra magic could even bring back a new security lockpad.

Lodewijk
  • 131
  • 3
  • It's not clear whether (cost of tapped connection * chance of tapped connection) > cost of TLS. But if Google doesn't mind paying the extra cost (if there is one), that's their choice. – user253751 Mar 27 '14 at 01:14
  • The reason is mostly that TLS is so very cheap compared to any sort of human disaster. Maybe it's not even ALWAYS true, but it's not an interesting discussion. Given the choice someone will invariably choose "Create problems for me" mode. – Lodewijk Mar 27 '14 at 01:22
  • 1
    I'm not saying it's bad - at least not for this reason. When you multiply a huge number and a tiny number, it's hard to know whether the result is huge or tiny. Google is just erring on the side of caution, which is a good thing. – user253751 Mar 27 '14 at 01:25
  • Exactly! :) ________ – Lodewijk Mar 27 '14 at 01:30
0

Perhaps they should offer an option to disable SSL if necessary. Perhaps there are some encryption restrictions in some countries or network requirements that would prevent users from accessing the service. I can see some business and user value to providing insecure options, but the defaults should be secure.

However, Google likely made this as a business decision and you are bound by the terms of their service. Google always encrypts other information, like search results when you are logged on so log servers and stats can't read the keywords of your search. If you are not happy with the service being provided (too little or too much security) you can always switch providers. In the case of email, its trivial to use IMAP to actually get your data out and imported elsewhere.

I don't think they have allowed IMAP/POP access without encryption for some time now either.

Eric G
  • 9,691
  • 4
  • 31
  • 58
  • 2
    Even allowing the option to connect to HTTP instead of HTTPS opens the door to man-in-the-middle attacks. Not a good option for any server that provides access to critical data. – Craig Tullis Mar 27 '14 at 04:02
  • @Craig: please elaborate? Is there an attack that would leave the user thinking he is using a secure connection when he is not? – user253751 Mar 27 '14 at 04:50
  • @immibis well, if the site will work over HTTP or HTTPS, then malware (I've seen this a number of times) on the computer itself could quietly redirect the browser to the HTTP version of the sites. If the server doesn't work over HTTP, this obviously wouldn't work. Also, SSLSTRIP (and by association its MIM kin) is mentioned at least once in other posts on this page. :-) – Craig Tullis Mar 27 '14 at 05:12
  • @Craig People who really care about security will have checked that they are using https, surely? – user253751 Mar 27 '14 at 05:15
  • 1
    @immibis you have no doubt gained some past insight into how savvy most "normal" people are about this stuff, right? :-) They just don't think about it, and that's part of the issue--the fact that so many people just don't even know which end is up and they get taken advantage of without even understanding what's happening to them. I honestly think it's good to have some protections in place for the ordinary average folks. One feature of SSL/TLS on a web server is that the web browser will bark at you if the certificate doesn't match the domain name. There's just a higher bar with HTTPS. – Craig Tullis Mar 27 '14 at 05:23
  • And "ordinary average folks" is in no way a pejorative. Some people (and by "some" I mean "most") make their livings being very competent at things *other* than computing and communications technology. For them, this stuff is a means to an end, and it shouldn't get in their way or cause them harm by being dangerous if they don't hold their head just right while they're using it. – Craig Tullis Mar 27 '14 at 05:26
  • @Craig Yes, I have gained the insight that they will accept http://www.google.com.evilhackervirusalert.co.za/ or even just http://evilhackervirusalert.co.za/ and so there's no point in trying to save those people. – user253751 Mar 27 '14 at 05:49
  • @immibis the main problem with checking for HTTPS is that it is something active that you need to remember to do. I consider myself competent at using the internet and computers securely, but even I don't regularly check for HTTPS. the flaw in current security practice is that there is no way to tell when a site is legitimately HTTP and when you're being _forced_ onto HTTP - and because of that, browsers can't display a warning when HTTP is used. therefore, security indicators are passive. if the entire internet were on TLS, this wouldn't be a problem. – strugee Mar 30 '14 at 02:15
  • and note that what I just said was not so much about technical security as it was about user experience. it is virtually impossible to remember to check for a passive indicator. an active indicator is easy to spot; you don't even need to check for it (by definition). – strugee Mar 30 '14 at 02:16
  • @strugee what would you do about self signed HTTPS? – user253751 Mar 30 '14 at 06:51