Hacker News Reader

Comment by brown9-2 | Hacker News Reader

Parameters sent via GET can get cached by proxies and they appear in log-files.

Not to argue in favor of sending sensitive data via GET, but I think it is worth pointing out that third-party proxies cannot see the URL or other parts of the HTTP headers or body when the connection is using HTTPS.

View on HN

But there is a good chance that these GET parameters are logged by the webserver. Even if these servers are very secure and strictly monitored, one bad employee can cause a lot of trouble.

Perhaps, but an employee in that position can steal credentials even without GET logs.

This entire discussion is predicated on a contradictory assumption, that an employee would be corrupt enough to steal credentials from web server logs, but not corrupt enough to steal the same credentials from any other source (inc. database access).

It is like letting a criminal into your home, then being concerned that they might see your security system's pin written on a sticky note on the fridge. Sure, it is a problem, but ultimately the criminal doesn't need that pin to steal your shit, you already let them walk right in.

GET logs end up in all sorts of places. I would not be at all surprised if anyone working at EBay could get access to them. Not to say they should have access to them, but access to the logs is different from access to the server. Log reading permissions have a rightfully lower standard than ssh/deployment permissions.

(But part of what makes it OK to have more people with access to the logs is you don't put things like username/passwords for all of your customers in the logs.)

With that logic it doesn't make sense to store passwords encrypted in the DB then either. If an outside attacker gains access to a system it would really suck to have a bunch of passwords sitting in logs unencrypted. Security in depth and all...

Often times server logs are sent to other locations (such as central locations) for storage. This can be storage for compliance purposes. I wonder if these are logged and sent to some other location. They may be visible to a great many people who don't have direct server access.

In general don't log sensitive information because you don't know how those logs will be used.

Not exactly. In corp/uni environments there may very well be a SSL-stripping proxy - and it works because in a corp setting you have the fake ca cert installed by IT, and in uni you often have to accept a cert when first connecting to the uni VPN.

I'm writing a Html5/Js end to end encrypted chat app for just this scenario. It won't stop a nation state modifying requests in transit and injecting their own js but it will probably stop a nosy sysadmin.

"It won't stop a nation state modifying requests in transit and injecting their own js"

It should stop a nation state if you serve up the JS via HTTPS and use certificate pinning.

Pinning doesn't work against the "corporate CA" scenario, at least if the user is using Chrome:

Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. “Data loss prevention” appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning.

https://www.chromium.org/Home/chromium-security/security-faq...

Thanks for that. I had no idea. I wish there was a way to grab the certificate in Js. Just so you could alert the user that they are MITMed. As it stands I will have to instruct them to check manually.

You could use https://openpgpjs.org/ for example to provide in-browser cryptography between user and server.

I've considered it but the overhead on the server side would be too much for the ad-free (ad's = loss of privacy IMO) and non-monetized vision I have. I use diffie-hellman to distribute an encrypted master key to each client that is used initially for the chat. I'm going to tell users not to consider that private (I can certainly man in the middle it from the server as I'm the one who generated the key) but they can use that key to discuss what private key they will use and then enter it manually (my brown dog's name + my birthday with only the first letter of my last name capitalized for example). In that master key I sent earlier there is also a salt to add to the hash of the password they select so even if the key they pick is weak it still might protect them. Everything is wrapped up in AES256 thanks to the Stanford Javascript Crypto Library.

I may use openpgpjs down the line for private messages within rooms. I also want to experiment with WebRTC for private messages and maybe offer some opportunistic peer to peer connections but I haven't gotten the far yet.

If they're MITMing they could replace whatever JS you put with something else, by definition.

While this is true, a parent comment from the user you're responding to has already explicitly mentioned this as a potential issue:

"It won't stop a nation state modifying requests in transit and injecting their own js but it will probably stop a nosy sysadmin."

Wait, what? So I guess our admin can read my gmail :/

Will pay attention to what certs are being served from now on...

In that kind of environment all bets are off already and recovering security is hopeless, no?

In this scenario the distinction between GET and POST becomes irrelevant.

No, it does not, because usually an appliance will have some sort of logging - which will usually include the URL, which in turn contains the GET parameter.

If there is an inserted CA then I believe any cert from any website can be MITM'ed and there are appliances that do this.

From PaloAltoNetworks website:

"... firewall proxies outbound SSL connections by intercepting outbound SSL requests and generating a certificate on the fly for the site the user wants to visit."

you got a point, i will do a short edit here.

Reply on news.ycombinator.com