[mschuster91]

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.

[lmm]

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

[brown9-2]

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

[mschuster91]

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.

[amalag]

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

[cmdrfred]

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.

[drodgers]

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

[icebraining]

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

[cmdrfred]

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.

[lmm]

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

[ncallaway]

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

[mschuster91]

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

[cmdrfred]

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.

[pingec]

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

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