My favourite issue caused by a corporate firewall was when it altered an AJAX request to replace a specific combination of digits (in a long product ID) by asterisks.<p>Turns out that a substring of that product ID matched the client company's phone number and their security theatre intercepting proxy was replacing all occurrences of "sensitive" strings sent to the internet with asterisks.<p>The irony is, of course, that as the people running the site, I didn't know (and would never have wanted to know) the user's phone number until this incident.<p>How I loathe security theatre.
I work at a government agency and here are my tales.<p>1) They install a root certificate on all machines and use that to MITM all TLS connections using a firewall appliance. They turn this MITM on one day without notifying any developer. Overnight, all our builds (run on-prem) fail because npm install, pip install etc fail and we spent a long time trying to figure it out. They are still failing to this day and I have to get off the VPN every time I need to run these simple commands. IT absolutely doesn't give a flying **** about developers.<p>2) They ban all non-Chrome browsers from being installed. As in, if you install such a browser and try to launch it, the system will say "browser X is banned. Contact IT." They would have banned Safari too had it not been part of the OS. Furthermore, they also disabled private browsing in Chrome (probably the ability to do this is why they allow Chrome). I think they're preventing people from hiding their internet browsing.
"Aha, so an overzealous IT network decided to block the request before it even reached my server."<p>What classifies this as an "overzealous" act of network configuration? There may be a subjectively legitimate reason the user's network was configured this way.<p>"I had no idea I was ever going to get anything different."<p>There's an entire list of HTTP status codes. That was your clue that you would get something different. You made a decision to not have handling for them all. Not implementing handling for 418 is understandable, but forbidden and service unavailable responses are common enough.
While I am sympathetic with the developer, a large part of fault lies with them. Firewall actually behaved very nicely.<p>Always check status codes. Don't assume that backend (even if it is your own server) behaves as you think it should - complain when the response is not what you would have expected.<p>This is why I hate those error responses that encode the error message into JSON and return status 200. Gee, thanks - your backend is so special that it is an honor to write custom error handling for it. /s<p>Glad OP solved it in the end, but I would suggest reacting to all 4xx and 5xx statuses. It's a standard, if you get 418 you know what "your" backend is saying.
We once had to fight for stackoverflow access. Security responds: you devs should only require the manual provided by the vendor(in this case: Oracle javadocs)?
I worked in a financial company in mid 2000s where the network head did not believe in internal firewalls so that all internal users were on the same network as all the web app servers and database servers. If someone was downloading a movie then customer web access slowed; since everyone used Windows everyone was required to run virus scanners on their computers and that included the app and database server machines since they were not isolated from the rest of the network. If a vendor came to demo something they were unable to since there was no way to isolate their laptop from everyone else so they could not access the internet.<p>Good thing I never put any of my money in the company accounts...
I have a government client that has locked down all outgoing access for a web server except though a socks proxy.<p>It makes simple things really hard - like a links checker, package dependencies, remote servers or integrations with Google.<p>We can't even run test scenarios on the machine because we're also locked _out_ of the server. Instead, we rely on their IT department to run test scripts that we send them via email.<p>We were debugging an elastic server connection for 2 weeks that was working perfectly fine in their "QA". It's a horrible existence.
> It helpfully spits out this HTML response in return but, of course, my frontend code was expecting a JSON response. I had no idea I was ever going to get anything different.<p>I wish more front-end devs recognized that they're building HTTP clients whenever they make HTTP requests. There's a whole specification written about how to do that well so one doesn't have to learn things like this the hard way. Specs may look old and esoteric, but following them bakes hard-earned wisdom into your apps for free.
If I want to push to GitHub when I am in the office, I have to VPN out of the office connection because Port 22 is blocked.<p>And they wonder why I prefer to work from home?
I work on something that requires a reasonably cooperative NAT and unmolested real-time UDP traffic. I've seen varied failure-modes from corporate firewalls over the years - from simple NAT table overflow causing rapid source port switching, to the firewall appliance downloading an update and deciding UDP packets of a certain size ( and ONLY of a certain size.. ) were bittorrent and hence were to be blackholed. That was an interesting one to track down. I've also seen it block diagnostic GETs to varied bits of cloud infra, due to someone at some point in the distant past hosting porn on that particular IP. Not to mention just good old strict NATs..
I wonder what _showHtmlPage_ does? Did he just write something, something that allows 3rd party (corporate firewalls) inject HTML under his domain within TLS protected connection?<p>Cannot judge by not knowing how he displays errors. But a question to HN public: Is opening unknown HTML under my domain within another window safe? Or is there any possibility to strip down any "permissions" to cookies, requests, resources etc for that dedicated page?
I was expecting another section about all the other ways a corporate firewall can cause issues. Not all firewalls will give you a 403. Sometimes it will be a 200 with the error in the body. Sometimes you'll just never get a response at all. Sometimes you will get an SSL certificate error, because the error response is signed using the certificate for the firewall vendor's domain instead of yours. And etc.
Firewalls from security vendors with L7 decryption (using MITM root certificates from a company-wide PKI) is pretty standard in any business that needs to care about "cyber security".<p>I always hear people cry and moan about this but having worked on that side of the fence I would like you to know that I know of instances where people have been downloading illegal material (involving children) and running tor. That's not to mention the 75% of staff who willing give details during phishing campaigns.<p>Saying that, I find 60%+ of cyber businesses to be a waste of time at best, and at worse just frauds. Core firewalls with L7 capabilities from vendors such as Palo Alto and CheckPoint are legitimate security devices, especially suited for enterprise networks.<p>I do think it's pretty pointless running those in the cloud though, unless you have admin VMs on vnets for your production resources. But that way lies madness anyway.
I'm currently in my very first job where running a local silent NTLM proxy is not a vital skill of survival. For similar reasons I somehow always made an opensource sonatype nexus that is doing pypy proxy or similar, so that operators team can actually do meaningful work without triggering security teams daily.
You really need something like sentry to report all unhandled exceptions. I learned that lesson when I realized everyone on Safari couldn't use my website (submit forms) because a feature I used wasn't supported on Safari. Easy way to drop your conversion rate by 30%.
> Sorry, you don't have permission to visit this site.<p>> Website blocked<p>> Not allowed to browse Shareware Download category<p>> You tried to visit:<a href="https://www.valcanbuild.tech/handling-corporate-firewalls/" rel="nofollow">https://www.valcanbuild.tech/handling-corporate-firewalls/</a><p>The irony.