Author Topic: Does HTTPS actually protect your data?  (Read 6898 times)

0 Members and 1 Guest are viewing this topic.

Offline Ash

  • Regular Contributor
  • *
  • Posts: 161
  • Country: au
Re: Does HTTPS actually protect your data?
« Reply #25 on: October 14, 2017, 11:51:51 am »
1: Almost all ads are served by javascript. You can't serve ads by javascript and not run javascript.  :-//

If not you'd have to insert the ads directly into your page before it's sent. You could do that statically, but only for a fixed set of ads. In theory, PHP can grab the contents of a foreign page and then inject the HTML into the current page. In doing so it could grep for malicious code and remove it. That would be a lot safer, but it would require a lot more preparatory work by the webmaster. Which is why it's not so common. It would also require that the main site's host act as a gateway for the ad traffic, which would probably not go down too well.

I'd say all of them are.

That doesn't mean that you go shoving their javascript into your site with out verifying it. If you don't trust your ad provider, why are you using them?

The script doesn't need to be put into the page. You should be able to set up an iframe. The document in that iframe will be provided by them and it will be in their domain as far as the same origin policy works.

Normally, frames and popups opened from the same site can access the opener's properties, thus running ads in a frame or popup of some kind is not in itself a protection against them spying on the main page. Doing the login in a popup is a protection from ads on the main page, but only because js cannot enumerate windows.  Not so with a frame, because the frameset can be enumerated.

You simply don't understand how this works. Go and try it.

If the content of the Iframe was loaded from the same fully qualified name, sure it will be able to access each other. If the iframe is from a different machine on the same domain BOTH pages can change their domain to a higher level and then be able to access - but note: BOTH sides have to cooperate to do this. (as an example www.example.com content and static.example.com content could interact if both set their domain to example.com.

However, if the content of the document (the HTML page that contains the script tag loading the ad server code) you load into an iframe (using a src tag for instance) is on a different domain, it will not be able to access your page.

Popups are similar.

3: Quoting propaganda posted on stackexchange proves nothing. If repetition made things true, we'd all be running everything on magnet motors.

Ok.. um... so, you have a large number of professionals telling you something is the way it is. You have banks and large internet companies and live and die by the trust of their users telling you the same thing.. You have the very very cleaver people that spend their lives architecting these standards telling your the same thing, but you know better, its clearly a conspiracy...

We've all had a go at explaining this to you, hoping that you might see where you have gone wrong, but no. Apparently we must all be wrong because we are repeating a "truth" that you don't agree with so you compare us to free energy crackpots..  Really?

I think the answer is denied to you because of your ego. I'll not waste any more time on this... believe what you will, the rest of us will continue with reality.

Ash.

 

Offline IanMacdonaldTopic starter

  • Frequent Contributor
  • **
  • Posts: 943
  • Country: gb
    • IWR Consultancy
Re: Does HTTPS actually protect your data?
« Reply #26 on: October 14, 2017, 01:08:44 pm »
No, Ash. What you have demonstrated is that by resorting to ad hominem remarks, that you have already lost the argument:clap:

In any case, all of this hinges on site operators taking precautions other than, or in addition to, those embodied in HTTPS. For the moment let's forget the question of whether or not  they are effective. There is no way of telling if any given site has implemented these protections, so the bottom line is that you can never trust a site with ads on it to be secure against a MITM attack. That is the nature of the problem. 
 

Offline rich

  • Frequent Contributor
  • **
  • Posts: 250
  • Country: gb
Re: Does HTTPS actually protect your data?
« Reply #27 on: October 14, 2017, 05:42:21 pm »
No, Ash. What you have demonstrated is that by resorting to ad hominem remarks, that you have already lost the argument:clap:

Ian, whatever you've taken umbrage to doesn't actually devalue all the thoughtful, high quality and detailed technical replies you've received in this thread.

I'm struggling to grasp what in this discussion is left in doubt. You want an indicator in the browser for non-tech savvy users to confirm that any site they visit is 'safe'. An admirable goal, but far fetched. Even if the browser could report on the specific scenario of your ad demo, that doesn't tell you if the site is 'safe'.

Calling your demo code a MITM attack and beating on https for not solving it is wilfully broadening the scope of https to suit your argument that https is snake oil.

There is no way of telling if any given site has implemented these protections, so the bottom line is that you can never trust a site with ads on it to be secure against a MITM attack. That is the nature of the problem.

The nature of the problem is much worse than that. The bottom line is that, as a user, you can never trust any site to be 100% secure. But as a user, you trust the origin site to have implemented measures appropriate to the risk and to use trusted 3rd party sources appropriately. I covered this in my earlier post.

 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19279
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Does HTTPS actually protect your data?
« Reply #28 on: October 14, 2017, 06:00:23 pm »
There's an old cryptographer's aphorism that is obliquely relevant to this thread, in that it adds an important missing viewpoint...

"If you think cryptography will solve your problem, then you don't understand cryptography and you don't understand your problem".

To some this extent this entire thread is a "how many angels can dance on a pinhead" discussion.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline xani

  • Frequent Contributor
  • **
  • Posts: 400
Re: Does HTTPS actually protect your data?
« Reply #29 on: October 14, 2017, 06:33:31 pm »
No, Ash. What you have demonstrated is that by resorting to ad hominem remarks, that you have already lost the argument:clap:

Sometimes people got tired of ignorance and fundamental misunderstanding of topic of other person that they just do that out of annoyance. Doesn't mean their arguments are not valid.

Quote
In any case, all of this hinges on site operators taking precautions other than, or in addition to, those embodied in HTTPS. For the moment let's forget the question of whether or not  they are effective. There is no way of telling if any given site has implemented these protections, so the bottom line is that you can never trust a site with ads on it to be secure against a MITM attack. That is the nature of the problem.

That's not a MITM attack tho, that's just ad sites serving basically a malware.

Trojans from ad sites are still served securely over https with no option to MITM that.

HTTPS have NOTHING to do with attacks you describe, it's not even in same place of the stack

Quote
There is no way of telling if any given site has implemented these protections, so the bottom line is that you can never trust a site with ads on it to be secure against a MITM attack. That is the nature of the problem.

First part of it is true but it is not just "ads". Site can have any number of exploitable errors in it. Second part is bullshit, this has nothing to do with MITM. The "bad" or vulnerable code is running directly on your machine
 

Offline apelly

  • Supporter
  • ****
  • Posts: 1061
  • Country: nz
  • Probe
Re: Does HTTPS actually protect your data?
« Reply #30 on: October 14, 2017, 07:10:56 pm »
the bottom line is that you can never trust a site [using https] with ads on it to be secure against a MITM attack
Yes. You absolutely can. That's the whole point.

You might not be able to trust the site, but TLS protects your data from observation and manipulation while in transit. That's it.

The OP is confused about the problem that HTTPS solves. But you pointed that out earlier.
 

Offline grumpydoc

  • Super Contributor
  • ***
  • Posts: 2905
  • Country: gb
Re: Does HTTPS actually protect your data?
« Reply #31 on: October 14, 2017, 09:34:43 pm »
Lets take it step by step.

  • A (secure) hash takes the password and applies either a key or salt to the plain text resulting in the "Hash". Let us assume that this is done in the browser
  • The browser now submits this hash along my by user name (or similar) to the server over a HTTP connection
  • The server receives the hash and user name, and looks this up in its database
  • The server can't do anything with the hash, it doesn't know the password, it has to use what it got
  • It therefore can only store what was given (sure it could hash it again, but that doesn't add any security to the password), so it does a check against what it stored
  • User is "signed in"
  • Sadly for this user, they were using an open WiFi connection at a local restaurant... I'm sitting on the same WiFi network running some tools that allow be to dump WiFi traffic in promiscuous mode.. Hum.. interesting a signing request to insecurebank.com, I wonder...
  • I take the plain text http request I saw on the wire and play it again. What happens?
  • Server sees request, server looks at user name and hash, server validates hash. Bingo. I can be you.
  • The hash is the password
Errr, well, if you implement it that way, however the problem of replayable hashes was solved a long time ago.

A more secure approach is that the server sends the client a challenge containing a random key. This is combined with the password and sent back by the client. The server also computes the hash and compares what the client sent, if they match then you are in.

Only if you know the password (which never goes over the wire) and the challenge are you able to compute the hash and the hasing functions are, obviously, one way so that the password (or password as mangled by the random number) cannot be recovered from them.
 

Offline timb

  • Super Contributor
  • ***
  • Posts: 2536
  • Country: us
  • Pretentiously Posting Polysyllabic Prose
    • timb.us
Does HTTPS actually protect your data?
« Reply #32 on: October 15, 2017, 12:16:35 am »
...so the bottom line is that you can never trust a site with ads on it to be secure against a MITM attack. That is the nature of the problem.

This shows that you’re the one who’s missing something fundamental.

First off, if your site content is being served over HTTPS, but the third party JS is being served from a non-secure source, the user will absolutely see a warning pop up in their browser telling them as much.

However, if the malicious ad is also being served up over HTTPs, the data being sent back and forth is still, absolutely, 100% without a doubt protected from a MITM attack.

I think the problem lies in your use of the term “MITM”. Your use of it greatly differs from everyone else’s.

You’re trying to call malicious JS served up (securely) by a third party advertiser a man in the middle attack, when it’s not. It’s simply malicious code being served up by a third party!

Because it’s being served over HTTPS, the user is still protected from the data being viewed or modified in transit by any third party.

Again, that’s the key that I don’t think you quite get. HTTPS is designed to protect data while it goes from a server to your browser. It was never designed to verify the content being transferred isn’t malicious. That’s a job for software like AdAware and such.
« Last Edit: October 19, 2017, 02:56:34 am by timb »
Any sufficiently advanced technology is indistinguishable from magic; e.g., Cheez Whiz, Hot Dogs and RF.
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 9810
  • Country: 00
  • Display aficionado
Re: Does HTTPS actually protect your data?
« Reply #33 on: October 15, 2017, 02:05:24 am »
The way I like to see encryption is that it does not stop eavesdropping 100%, but it slows it down. The big 5 eyes networks store every packet that crosses their listening posts, if they can't decrypt it with today's tech they will be able to with tomorrow's, but they may also have discard the data by then if they feel it's not important to them or them finding out the info may not be as critical by then.
How do yo figure they store every packet? Purely from a logistical point of view, that's pretty much an impossible task, even with the massive data centers these agencies have.

I know there is some evidence that it's done in the case of a handful of specific countries, but not every country.
 

Offline Ash

  • Regular Contributor
  • *
  • Posts: 161
  • Country: au
Re: Does HTTPS actually protect your data?
« Reply #34 on: October 16, 2017, 01:20:56 am »
Lets take it step by step.

  • A (secure) hash takes the password and applies either a key or salt to the plain text resulting in the "Hash". Let us assume that this is done in the browser
  • The browser now submits this hash along my by user name (or similar) to the server over a HTTP connection
  • The server receives the hash and user name, and looks this up in its database
  • The server can't do anything with the hash, it doesn't know the password, it has to use what it got
  • It therefore can only store what was given (sure it could hash it again, but that doesn't add any security to the password), so it does a check against what it stored
  • User is "signed in"
  • Sadly for this user, they were using an open WiFi connection at a local restaurant... I'm sitting on the same WiFi network running some tools that allow be to dump WiFi traffic in promiscuous mode.. Hum.. interesting a signing request to insecurebank.com, I wonder...
  • I take the plain text http request I saw on the wire and play it again. What happens?
  • Server sees request, server looks at user name and hash, server validates hash. Bingo. I can be you.
  • The hash is the password
Errr, well, if you implement it that way, however the problem of replayable hashes was solved a long time ago.

A more secure approach is that the server sends the client a challenge containing a random key. This is combined with the password and sent back by the client. The server also computes the hash and compares what the client sent, if they match then you are in.

Only if you know the password (which never goes over the wire) and the challenge are you able to compute the hash and the hasing functions are, obviously, one way so that the password (or password as mangled by the random number) cannot be recovered from them.

Ok, fair call if you have a shared secret you are trying to prove one or both sides share (this is a common enough technique, but doesn't belong on a web page in Javascript), but you are still left with the question of what is stored on the server in the case of a password/credential?

Both ends need to be able to create a hash of the data in question. Lets assume this is a password. Now to do this properly, we should be using something like a HMAC structure (there are known weaknesses in doing just HASH(KEY + SECRET) or HASH(SECRET + KEY), but that is not relevant here).

What does the server store in its DB to be able to perform this hash? We need to be able to do the same computation as the client. There are 3 options that I can see.

  • Store the password plain text so the server can compute HMAC(Key, password)
  • Store the password encrypted so the server can compute HMAC(Key, DECRYPT(decryptKey, password))
  • Store HASH(password), the client then computes HMAC(Key, HASH(password)) which can again be verified on the server

The first two are bad simply because we now have unlimited access to the password on the server and I believe that we all agree that storing passwords is regarded as poor form. So, we are left with the third option, storing a hash of the original password.

But for all three options, we are now stuck - how do we securely send this password/hash to the server without exposing it when I create my account or change my password? If I can see you send that original password hash I can now correctly respond to any challenge key you issue from the server. This HASH(password) is now again effectively the password.

At some point you will need to securely send the password (or hash) to the server so all the additional code you have used to hash the password on the client still relies on a secure connection.

So just do it the way it was designed in the beginning - https because this provides additional levels of security (authenticating the server to the client). How does your Javascript hashing code determine that it is talking to the correct server? I can setup a proxy between you and the server and truly Man-in-the-middle this process.

Now the next problem is how are you maintaining the "session" state? normally this is handled in a cookie (or a query string argument) but access to this cookie is now access to your identity. Again without HTTPS encryption, there is no way to protect this data and again, If I can get this cookie, I can access your account on the server.

This is the problem that the HTTPS-all-the-thingz campaigns are about fixing.

I see these issues all the time. There is a lack of understanding by a lot of web developers, even of quite popular systems used by many sites.

For instance, even the forum code used here on EEVBlog will let you happily sign in using HTTP, then proceed to issue you a session token. Again all over HTTP, using some javascript client side "hashing". It simply isn't secure. Make sure you use HTTPS. If you do sign in using HTTPS, the forum software doesn't seem to set the HTTPS only flag on the session cookie, so if you then hit the server with HTTP it is still sent and your account exposed.

The thing is, you as the user have to make a call about what information is important enough to protect. Personally, there is very little information about me here and I use large random passwords which are all different for all my accounts so I'm not too worried about leaking my password. I make the judgement that I get more utility using the site than what I risk.

Ash.


 

Offline IanMacdonaldTopic starter

  • Frequent Contributor
  • **
  • Posts: 943
  • Country: gb
    • IWR Consultancy
Re: Does HTTPS actually protect your data?
« Reply #35 on: October 16, 2017, 10:40:04 am »
The basic principle behind devising a (reasonably) secure system is that:

All passwords are hashed using a salt, at the client. This can be a 'site secret' which applies to all accounts, or it can be based on a particular (unchanging) feature of the account such as the user's name or DOB.

At signup this hash has to be sent to the server, which does represent a slight security risk. Encryption could be used to mitigate this. However, signup occurs only very infrequently so the chances of interception are small.

At login, the client requests a nonce from the server.

The client hashes the user's input with the both the site secret and the nonce, and sends it.   

The server gets the database password field for this user and hashes it with the nonce. If this equals the submitted value, the correct password was typed. The nonce is then discarded.

Consequences:
The hash seen on the wire at signup will not log the user in.
An intercepted login hash will only work once, and only if the MITM can beat the user to logging-in, because the nonce will not be accepted a second time.

A weakness is that the values stored in the database would work for login if the hacker understands the nonce mechanism, and can request one. This can be prevented by reversibly encrypting the stored values. Of course the hacker might be able to pinch the encryption key too, but hey, if he owns the server to that extent, why does he need a login anyway? 

No process is ever 100% secure, the best you can do is make it hard enough for a hacker that they will decide to try somewhere easier.
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23017
  • Country: gb
Re: Does HTTPS actually protect your data?
« Reply #36 on: October 16, 2017, 11:08:54 am »
You shouldn't salt with a known value. See Common Weakness Enumeration CWE-760: https://cwe.mitre.org/data/definitions/760.html ... Salt should be per credential from a hardware RNG. If someone finds out how to generate the salt from the data then the salt serves no purpose.

HMAC signs the body and performs authentication so you know it's not been tampered with and that the originator is authentic. It doesn't however protect the body in transit. That's what TLS is for :)

Our API stuff uses HMAC signed requests/responses over TLSv1.2.
« Last Edit: October 16, 2017, 11:10:51 am by bd139 »
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 9810
  • Country: 00
  • Display aficionado
Re: Does HTTPS actually protect your data?
« Reply #37 on: October 17, 2017, 09:09:47 am »
You shouldn't salt with a known value. See Common Weakness Enumeration CWE-760: https://cwe.mitre.org/data/definitions/760.html ... Salt should be per credential from a hardware RNG. If someone finds out how to generate the salt from the data then the salt serves no purpose.

HMAC signs the body and performs authentication so you know it's not been tampered with and that the originator is authentic. It doesn't however protect the body in transit. That's what TLS is for :)

Our API stuff uses HMAC signed requests/responses over TLSv1.2.
A salt is historically intended to prevent the use of rainbow tables. That way, generic rainbow tables aren't enough to compromise your environment. Deducing your salt and creating targeted rainbow tables is considerably more work, which should provide a level of protection.

Obviously, creating unique salts provides even more protection, but you could argue the same way that if someone finds out your salt list, they serve no purpose. Both already mean a significant breach of security.
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23017
  • Country: gb
Re: Does HTTPS actually protect your data?
« Reply #38 on: October 17, 2017, 09:27:49 am »
That's not where your responsibility ends.  You need to plan to lose your identity, the hash and the salt. If your salt is predictable than it makes it considerably easier to attack the passwords. After that you can then leverage the credentials elsewhere where users have reused credentials. The whole point of the salt is to make that computationally more difficult.

If you're deriving the salt source from anything that isn't random, then there's no point in having a salt.

There's no such thing as secure or more secure. It's boolean, and only while the mathematics are intact.
 

Offline Mr. Scram

  • Super Contributor
  • ***
  • Posts: 9810
  • Country: 00
  • Display aficionado
Re: Does HTTPS actually protect your data?
« Reply #39 on: October 17, 2017, 03:34:09 pm »
That's not where your responsibility ends.  You need to plan to lose your identity, the hash and the salt. If your salt is predictable than it makes it considerably easier to attack the passwords. After that you can then leverage the credentials elsewhere where users have reused credentials. The whole point of the salt is to make that computationally more difficult.

If you're deriving the salt source from anything that isn't random, then there's no point in having a salt.

There's no such thing as secure or more secure. It's boolean, and only while the mathematics are intact.
Patato, patato, I guess. You could be saying that means my 4 character password isn't anywhere near as secure as your 4859 character password. You could also be saying that both are equally secure until the actual breach. Both could arguably be true.
 

Online Bud

  • Super Contributor
  • ***
  • Posts: 6877
  • Country: ca
Re: Does HTTPS actually protect your data?
« Reply #40 on: October 17, 2017, 04:10:54 pm »
This shows that you’re the one who’s missing something fundamental.

What timb said.

HTTPS provides point-to-point protection of traffic. Once your traffic hits the remote server it pops out in clear text and the remote web server sees it as clear  text and therefore can insert whatever it wants in its response back. As far as HTTP is concerned it is outside of its scope. Think of a robust hard pipe that connects two buckets. You can pump gold through the pipe or you can pump shit, the pipe does not care. However the pipe will make sure nothing leaks between the end points.
Facebook-free life and Rigol-free shack.
 

Online Marco

  • Super Contributor
  • ***
  • Posts: 6693
  • Country: nl
Re: Does HTTPS actually protect your data?
« Reply #41 on: October 17, 2017, 05:16:23 pm »
The problem of "fake" certificates of MITM proxies and rogue CAs can be solved by DANE.

Google, Mozilla and Microsoft "independently" closed feature requests for DANE with WONTFIX. Security wise EV certificates with pinning/transparency are almost as good, but cloud services have pretty much killed those. The hardware nature of EV certificates clash with the cloud concept and no one has bothered fixing it.

This is all of course a complete coincidence. HTTPS is definitely not security theatre as the WPA2 hack shows, but the CA clusterfuck does seem custom designed to allow security agencies to abuse it ... as long as they are willing to throw a CA under the bus to do so.
« Last Edit: October 17, 2017, 07:32:29 pm by Marco »
 

Offline madires

  • Super Contributor
  • ***
  • Posts: 7695
  • Country: de
  • A qualified hobbyist ;)
Re: Does HTTPS actually protect your data?
« Reply #42 on: October 18, 2017, 02:32:25 pm »
That clearly shows how much they care about security and privacy. >:D It's a tradeoff between supporting the middleboxes (plus law enforcement) and providing secure communication to users.
 

Offline cdev

  • Super Contributor
  • ***
  • !
  • Posts: 7350
  • Country: 00
Re: Does HTTPS actually protect your data?
« Reply #43 on: October 18, 2017, 02:48:32 pm »
The entire process should be transparent in a way it has never been.

All OS defaults now seem likely to be badly chosen and likely to be insecure. Complexity adds likelihood of insecurity and should be minimized, not maximized.



« Last Edit: October 18, 2017, 03:08:46 pm by cdev »
"What the large print giveth, the small print taketh away."
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf