Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That's true. Fortunately, if everything else fails, we should always be able to connect on 443 via stunnel for example, no matter what protocol we use. That's the price to pay for the net getting more complex and more abused.


Unfortunately, that's not true. Corporate networks got rid of plain old proxies that just passed anything SSL on 443 many years ago. In order to meet regulatory requirements to record employee communications, pretty much every US company of any decent size uses a proxy (blue coat, zscaler, palo alto, etc.) that executes MiTM attacks on all SSL traffic. If it's something other than HTTP over SSL, or if it's to a blocked hostname, it won't go through.


The sad part is that a lot of people don't even seem to care.

When my relatively small company announced that they were installing a Palo Alto firewall and that everyone needed to install client side certificates in order for web browsers to continue working, it set off major alarm bells in my head that led to one conclusion -- "No more non-work related web browsing at the office. No exceptions."

Most of my coworkers (albeit mostly those in support and not developers, but still people at least somewhat familiar with the way computers work) only cared that they'd still be allowed to visit Facebook during the day.

I was assured that "nobody was actively looking at employee web traffic" but that doesn't matter. They didn't even think it was a big deal to put this new monitoring in writing until I made a big stink out of it, and they added this to the employee handbook:

>Each of these communication avenues are subject to monitoring by the IT Security Manager, a supervisor, or the President. When using any of these communications, be aware that a business record is made, which is retained by the company and becomes the company's property. This business record may potentially contain sensitive personal information related to the sites you are viewing and into which you are logging on, including user/password information. If you do not wish to share such information, it is suggested you do not access those items using [employer]'s network.


We can go one step further, and put our payload into an encrypted body in an innocent looking HTTP request. Thus begins the game of cat and mouse…




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: