Does not having https moot this entire site?

Question

On a bank website the other day, I noticed that they were giving out a phone number on a page that wasn't over https. This seemed really wrong to me, since it would allow somebody to change the phone number to the bank and get me to dial a fake number.

Now, I'm realizing that we're providing a TON of information here at stackexchange, but that even this site isn't over HTTPS. How do I know I can trust any of the information here? How can I know it hasn't been tampered with and changed? How do I know that the answers to this question are not being intercepted and MIM'ed?

I know the information here is crowd-sourced, so how can I trust it in the first place, but if we assume the system is working, and that the best answers are generally right, how can we know we can trust them?

Answer 1

My 2 cents, not really from an IT security standpoint:

Ideally you would be correlating and checking up on information found on this site. Generally, answers fall into two categories:

• Summarizing or explaining relevant information.

• Providing original thoughts or analysis.

The first one ultimately comes down to someone re-writing existing human knowledge. In these cases, you should probably be verifying the answers and checking them elsewhere if you need the information for anything important. Eg, "Some guy on SE said so" isn't a good dictator of a cooperate IT policy, you should understand and agree with what was said before following it.

In those cases, you would pursue the information mentioned on IT.SE and pull it from other sources in your research. You should see the same facts and explanations come up elsewhere. Anyone performing a MITM against you and IT.SE would be forced to also perform an MITM against all the other source you look at. While not impossible to do, it raises the attack difficulty such that they need to be filtering your entire Internet browsing experience. At that point, the issue is more about the lack of universal HTTPS and whether the Internet connection itself is safe.

For the occasional post that contains original information that is very difficult or near impossible verifiable in another way, this is a valid point. An attacker could subvert your own source of that information. But unfortunately, most other places don't host such content over HTTPS either; this isn't unique to IT.SE.

Answer 2

If attackers are doing a MitM to inject good answers in the stream, I certainly won't mind...

More seriously, StackExchange counts on most people being basically honest, and most attackers being basically people, i.e. lazy. It takes quite some effort and resources to maintain a working wide-scale Man-in-the-Middle attack so we can just assume that the overwhelming majority of connections to SE sites will not be tampered with. Not very reassuring, but the whole concept of Civilization builds on even flimsier foundations and we have learned to live with it (and, occasionally but not that rarely, to die for it).

From the SE managers point of view, this is a trade-off: what would they gain with site-wide SSL, and what would they lose ? Site-wide SSL increases CPU load, but not by much: according to Google, a mere +1% CPU and +2% network bandwidth. This was in the context of Gmail; an SE site has different usage patterns, and in particular serves a lot of "public and mostly static data" which could be cached (e.g. by transparent proxies installed by ISP). The biggest cost might be referencing: although search engines now index HTTPS content, it can be imagined that they handle it differently from what they do with HTTP content. Search Engine Optimization is the Life Force of free Web sites. To sump up, there seems to be some costs or risks (which are, economically, the same thing) to switching to full-site HTTPS.

On the other hand, what would SE gain from full-site HTTPS ? They don't guarantee anything about the veracity of the data, and it is public. What sense would it make to guarantee the confidentiality and integrity of the data in transit, while it was not confidential and not provably genuine to begin with ? And, even more importantly, would SE make more money out of it, to recoup the extra cost ? Remember that StackExchange is a private business. They are not Mother Theresa. They want to, one way or another, make money.

Thus, logically, SE managers will envision full-site HTTPS only when they believe that it will bring sufficiently extra readership. This seems dubious to me. I don't say that I don't want more SSL generally; but I cannot blame SE maintainers for choosing otherwise.

Answer 3

You should never believe, without confirmation, anything you read on the Internet.

This site provides a useful resource and discussion with some people who really undertand security. But everything you read here (and everywhere else) needs to be independently confirmed.

While pages transmitted without SSL could in fact be tampered with, it's far more likely that information you read is just plain wrong -- here and everywhere else. Like Wikipedia, StackExchange should not be considered a "primary source" of information. It's an an aggregation of information that needs to be independently confirmed.

Answer 4

Really, you can't. There is no authentication on the information. That said, the chances of a meaningful attack in that vector are probably fairly minimal in general, so the bank probably decided that it wasn't worth the cost of having SSL on the page (it does take more server resources to do HTTPS). The balancing point of what is a good trade off and what isn't is always a blurry line, but for example, if an attacker posted a phone number, it would have to actually be registered to a person and would be easier to track down who is responsible, where as simply attacking the login credentials to make them enter it on a phishing site is generally going to be easier than MitMing the website itself.

But no, there is no way to prove that the number is correct.

Also, for future reference, if you happen to be on the site because you think your computer is infected with a virus and the site says, don't nuke it from orbit, then clearly your virus is attacking the content being served and thus you should nuke it from orbit. :)

Answer 5

In regards to that bank giving out phone numbers without HTTPS, yes, this is stupid, and yes, also typical. Does it moot the entire site? Obviously it doesn't directly affect the security of the HTTPS part of their site, but it is a reflection on their overall security governance. Try emailing "security@their-domain-name" about the problem. See if you get a response. See if the email bounces. That will tell you even more about their attitude.

In regards to Stack Exchange and other IT advice found online, the answer is simple: Don't do things you don't understand. Especially don't follow instructions in the format "download and run this script." By doing things you don't understand, not only are you opening yourself to an attack, but you're missing out on learning. Much better to learn and stay safe at the same time.

Answer 6

HTTPS doesn't work like that - it isn't a check or balance on the quality or provenance of things you receive via HTTPS.

An https connection is an http connection encrypted with a server certificate, and means that, for that given connection, only software and organisations your trust can read that data.

A valid server certificate (that is, an https connection that doesn't generate an error in your browser) means only one thing, in general terms: something you trust (your browser) trusts something else (your operating system) trusts something else (your operating system vendor) trusts something else (a root certificate provider) who in turn sends 'trust' down to the person you're connecting to.

That chain of trust usually means that people can't fake an https session - usually, the chain of trust and network path go via different organisations (except at the endpoints), and that means that https is secure in most typical scenarios (and is why organisations can snoop on your https traffic at the proxy server - your admins can inject their certificate at the 'your machine' level).

So, given all that - what is it actually good for? Well, an https connection means you're overwhelmingly likely to be talking to the entity you think you are. That doesn't make their servers or networks any more secure however - if someone is able to get into the bank's site and change contact details, well, https isn't going to help since they can change the http and https sites.

Coming all the way back, what does this mean for content on the internet?

Well, https is a technical implementation of a chain of trust - since you can't verify who I am, even if there was an https connection between me and https://security.stackexchange.com/, you still don't have any reason to trust me, or any of the information I'm proving you.

You can, however, verify your bank is who they say they are - they know things about you noone else knows (such as a code they sent you via regular mail or the account numbers on your statements) - so the fact that you used that code to log in, or that the account numbers match your bank statements means that you believe they are who they say they are. https then provides you a mechanism for leveraging that trust - you're comfortable they are who they say they are, you trust them via a technical chain of trust and that chain encrypts your communication so your network layer can't read into the conversation.