How to know your network proxy sucks: when everything IDE-related (downloading new package, using Gradle…) is blocked, but almost everything prohibited (like streaming) isn't.
Love university.

Force over http... it sucks, but sometimes it's all we got, Even in enterprise networks 😞

@CodeTalker
Hah, I can top that.
Our network-proxy blocks "large" files from "untrusted" sources, downloads them on an offsite sandbox server, analyses them and then forward the user to a download-site where you can download the file.
But it doesn't recognize if you are downloading stuff with curl or something other headless, so the proxy just breakes those downloades.

@metamourge ok, that's a whole other level of fuck you. Don't tell my company, life's already hard enough getting things to work inside the network.

Our company's network proxy does TLS inspection and re-encrypts packets with its own cert. But the cert chain is all messed up so half of our automation tools that depend on https don't work properly without workarounds. Terraform can't access the provider registry. Pip and conda can't download packages. Sometimes certain websites just don't work at all.

We found workarounds for all of these but it took a while.

@EmberQuill That looks like a massive vunluarebility.

@EmberQuill ive been trying to tell our security team that on-the-wire packet decryption is not what we need, but they continue to insist its the best way to go. Fml

Every corporate network ever. 🤦🏻‍♂️🤦🏻‍♂️

Takes like 1 week to get stuff unblocked for a new engineer, I just had a new hire quit within the week because he couldn’t work

@EmberQuill Pretty normal in big companies... you have a firewall (inserting it's won certificate) and all https connections are forwareded fine...

@blubberfish yeah, I know it's normal. It's just a giant pain in the ass since my company's implementation of it isn't very good. Anything written in Go that relies on a trusted https connection doesn't work unless you have admin rights to fix the messed up cert chain, because of an issue with inherited trust settings. GitHub would sometimes fail to fetch images and stylesheets due to a bad interaction between our proxy and the browser CORS policy. You couldn't download modules with pip or conda.

We found workarounds for everything, but it's still a huge pain to deal with. And the firewall has problems too. It randomly failed to authenticate me today and I lost the ability to SSH to any of our cloud servers for a while (port 22 is blocked by default, for good reason, but I normally have an exception since I need to SSH to cloud VMs).

I like the stability of working for a large corporation, but the amount of bullshit and red tape I have to deal with on a daily basis is aggravating.

@EmberQuill Don't know how it's in your company... but I worked in some financial companies before (and in different jobs)... bit dizzy at the moment... https is always safe (or filtered by your company)

@What's GO?

@blubberfish https is proxied here in my company, so anything that verifies certificates just rejects them. Which is the problem.

You can do work arounds or install every certificate - which defeats the entire purpose of certs or fall back to http.

I've had to modify SDK's to identify if the code base is being ran in the cloud or inside the network just so I can disable ssl verification.

There's a fine line between too secure, and forcing people to make bad decisions that compromise your security just to do their job.

@C0D4 companies put their own SSL certificate over all network, to ensure that files like *zip, *exe and *.* are scanned

Worked as server admin, before getting a dev

@blubberfish I get that, and I understand the need for it. But it creates a royal pain in the ass.

@C0D4 yeah pain in the ass, for me today too, but i know where it's coming from :)

@TheCommoner282 the primary "workaround" I have to use at work isn't strictly a workaround, I suppose. Basically, our proxy puts its own cert on all https traffic that passes through. The cert chain has a root CA (explicitly trusted by all endpoints) and two intermediate CAs (which are signed by the trusted root CA but not explicitly trusted themselves). Unfortunately, some applications have issues with this, as they can see that a cert is signed by an intermediate CA, but not that the intermediary is signed by a trusted root.

For Python, I can tell it to trust a PEM file containing the full chain. For golang projects, I had to go into the Keychain and explicitly trust the intermediaries (which probably made the PEM file redundant for Python, now that I think of it).

Basically I'm just telling applications to explicitly trust a CA that should already be implicitly trusted.