3 ms·

I went to a community college that did transparent HTTP proxying with not just deep packet inspection but caching and "security"-oriented javascript injection.

I went to a community college that did transparent HTTP proxying with not just deep packet inspection but caching and "security"-oriented javascript injection. Headers would get reordered, and its parser wasn't perfect so multi-line headers would get broken sometimes. They'd inject JS into pages to scan for... something? Other injected JS? I have no idea. But it was impossible to directly connect to another server without going through their proxy even though from the TCP layer it looked like you were. Lots of difficult to debug issues.

lazide 4y ago
Wow, that’s impressively evil. Right up there with the old ‘rewrite DNS traffic’ trick from ISPs. Any idea what make/model the proxy was?
- ketralnis 4y ago
  Sadly that's well beyond my memory now. It was pretty formative for me though because I learned a lot of networking and programming and unix stuff so that I could write a TCP-over-HTTP tunnel to a home server just to bypass it. So all in all, great success to be honest.
- tonyarkles 4y ago
  Oh man, an old employer had one that did the same HTTP header monkeying. I discovered it because it broke, of all things, the C2 wiki. I thought the wiki was down when sent a link to a coworker but then checked from my home machine (working remote but over Remote Desktop). And then, of course, had to figure out why it would work at home but not at work :D I believe it was FortiGate but don’t quote me on that. It also liked to drop idle TCP connections out of its routing table without sending a FIN or RST. HashiCorp Vault, at the time, only used TCP keep-alive and no additional in-band heartbeat mechanism. Naturally, the firewall dropped the idle connection earlier than the default keep-alive interval (which is long…). Additionally, packets sent to an IP-port combo that it didn’t have in its routing table were black holed, without an RST. We had this painful bug to chase where first thing every morning we could read but not write to Vault for a few minutes and then it work fine for the rest of the day without incident. I left tcpdump running overnight to see it. At night no one was using Vault… first thing in the morning, the first write goes out to the existing (still valid on both sides according to netstat) but just disappears into the ether. Takes a few minutes for the write to timeout (while spamming retries) at which point Vault closed the connection and started a new one. I just about flipped the table over. Edit: and just like that, Twitter delivers https://twitter.com/substitute/status/1597695409903714304?s=61&t=tbga53bRz5TUIvKJdK65Rw https://twitter.com/substitute/status/1597695409903714304?s=...
jesprenj 4y ago
Interesting. There's a Fortinet product as well in our school. I bet it's corruption and some sysadmin is somehow earning money, because it's so obviously unnecessary. And it's set to block games. Ironically, I tried playing minecraft on a library computer and the server connection succeeded. Worst of all, lichess.org is blocked so students have to compete using their LTE network during chess tournaments. It shows that we have a part private part state owned company employed as sysadmins in our school. They don't really understand the needs of the school.

lazide 4y ago

Wow, that’s impressively evil. Right up there with the old ‘rewrite DNS traffic’ trick from ISPs. Any idea what make/model the proxy was?

ketralnis 4y ago
Sadly that's well beyond my memory now. It was pretty formative for me though because I learned a lot of networking and programming and unix stuff so that I could write a TCP-over-HTTP tunnel to a home server just to bypass it. So all in all, great success to be honest.
tonyarkles 4y ago
Oh man, an old employer had one that did the same HTTP header monkeying. I discovered it because it broke, of all things, the C2 wiki. I thought the wiki was down when sent a link to a coworker but then checked from my home machine (working remote but over Remote Desktop). And then, of course, had to figure out why it would work at home but not at work :D I believe it was FortiGate but don’t quote me on that. It also liked to drop idle TCP connections out of its routing table without sending a FIN or RST. HashiCorp Vault, at the time, only used TCP keep-alive and no additional in-band heartbeat mechanism. Naturally, the firewall dropped the idle connection earlier than the default keep-alive interval (which is long…). Additionally, packets sent to an IP-port combo that it didn’t have in its routing table were black holed, without an RST. We had this painful bug to chase where first thing every morning we could read but not write to Vault for a few minutes and then it work fine for the rest of the day without incident. I left tcpdump running overnight to see it. At night no one was using Vault… first thing in the morning, the first write goes out to the existing (still valid on both sides according to netstat) but just disappears into the ether. Takes a few minutes for the write to timeout (while spamming retries) at which point Vault closed the connection and started a new one. I just about flipped the table over. Edit: and just like that, Twitter delivers https://twitter.com/substitute/status/1597695409903714304?s=61&t=tbga53bRz5TUIvKJdK65Rw https://twitter.com/substitute/status/1597695409903714304?s=...

jesprenj 4y ago

Interesting. There's a Fortinet product as well in our school. I bet it's corruption and some sysadmin is somehow earning money, because it's so obviously unnecessary. And it's set to block games. Ironically, I tried playing minecraft on a library computer and the server connection succeeded. Worst of all, lichess.org is blocked so students have to compete using their LTE network during chess tournaments. It shows that we have a part private part state owned company employed as sysadmins in our school. They don't really understand the needs of the school.