HTTP/1.1 — STOP; HTTP/1.0 — GO!

Here’s something I came across not too long ago that I thought was a bit odd. An externally accessible web server was being protected by what appeared to be Cisco’s web filtering technology. This was strange because it is the kind of thing one would expect to see on an internal network, restricting access to the outside world. Protecting servers that still require access from the Internet by authorized users is generally done by things like firewalls, IP address whitelists, and VPNs. I believe this was a case of misuse of technology. An attempt to make something work in a way that was not intended. However, that is my job and it is the opposite of what network/systems administrators should be doing when implementing solutions.

Access was denied and a scary sounding message “Access to this destination is not allowed due to a possible malware threat” was presented when trying to access the website:

Access Denied

malware detected! maybe…

I had not seen that before and my first thought was that maybe an IPS detected the vulnerability scan that ran the night before. That scenario would have been annoying but not surprising as the scans are quite noisy. Maybe my source IP got flagged as potentially dangerous? But, after a few checks, it turned out to not be the case. Must be some kind of content filtering setup with a generic message and possibly IP-based, I figured. Or, even worse, malware got planted during an earlier compromise and internal Cisco solution was flagging it but the administrators haven’t noticed.


I noticed that the test results I was getting back were inconsistent. Some were coming back with the “Access Denied” page, while others with something else entirely. A few manual checks later it became apparent that the Cisco solution was only filtering HTTP/1.1 requests that are normally used by browsers, and letting everything HTTP/1.0 through.

After ensuring all my applications and tools were set to use HTTP/1.0 for communications with this web sever, it turned into just a regular day at work. This is what was behind the content filtering wall:

ShoreTel's login interface

Beyond the wall.

The moral of the story here is two-fold. One, if you are setting up security controls, don’t rely on web content filtering solutions as a means of controlling access to your external websites. Two, if you are testing security, always poke with several different sticks and from several different angles even when you think “there’s no way that would work.”