> "IT professionals" who believe they can secure their company by blocking WebSockets haven't retired yet.<p>There are some experienced people in the field who are just encyclopedias. And they keep on growing. And they leverage their knowledge to build great systems.<p>Then there are the people as described in the quote. Refusing to budge. Refusing to adopt modern technology. The same kind of people that don't allow outbound traffic on ports above 3000 (arbitrary number). So now I have to fight to be able to access my AWS instance which deploys docker containers for testing. Or I want to test WebSockets, which are blocked. Or QUIC. No. New. Is bad.<p>The same kind of security people who block Google Chrome's password manager because of some security issue in Cisco. No clue how that relates, but the idea that you're blocking a password manager to make things MORE secure just shows how disconnected these people are.<p>Either they are so senior and a bunch of trustees or they are too green and are hired as security people with 0 in-the-field experience.<p>Before I forget, these are the same kind of people who thought it was a good idea to sniff all of the GitHub traffic. Which works on our company laptops, as that has the root certificate installed. But all of your Docker containers suddenly fail to connect to GitHub because of a certificate error.<p>If the current economy wasn't going downhill I'd jump ship.
I don’t understand this, but the description of it is interesting to me. I like forward to a potential blog post or some documentation explaining it in-depth.
how do you block websockets in a world with tls around the majority of http connections?<p>wouldn't you have to resort to proxies with certificate authorities forced on users in order to block websockets?
Nice tool. I wish it would incorporate something like iodine though for really restrictive networks or ones with login portals. DNS almost always gets through.