When accessing some websites, users receive the following error exception message:
Server response could not be processed. Invalid characters/missing colon in header line or header name is empty This could be caused by a malformed response, or possibly a misconfiguration.
Users receive this error message because the site they are attempting to access is not RFC compliant. To allow users access to legitimate sites that are not RFC complaint, Blue Coat has added support for detecting malformed HTTP response headers in SGOS 126.96.36.199 and later.
These changes include:
Converting alternate whitespace characters in headers to standard spaces
Improved handling of invalid characters at the beginning of header and HTTP 0.9 responses
Detecting invalid HTTP version strings in HTTP responses.
Improved handling of invalid/missing HTTP response codes.
Unfolding normal and empty continuation lines in the HTTP response
Improved handling of different variations of responses that include chunked encoding instructions.
If you see the above error exception message, Blue Coat recommends that you upgrade to SGOS 188.8.131.52. SGOS 184.108.40.206 has support for normalizing certain forms of invalid headers rather than rejecting them. Two new access log fields with policy substitution (
x-bluecoat-invalid-response-headers) have also been added. In cases where 220.127.116.11 does still reject a response, the
x-bluecoat-invalid-response-headers field will report what made the response invalid. And in cases where the ProxySG appliance automatically normalizes the headers and returns the corrected response to the client, the
x-bluecoat-normalized-response-headers field reports what normalization changes the appliance made.
If you continue to see the exception error after upgrading to 18.104.22.168, you can enable the following CPL to bypass the exception:
Note: If you enable the ProxySG appliance to tolerate invalid headers, your appliances might be open to client-side attacks that involve headers that are not RFC compliant. Blue Coat recommends that you should only enable the following policy in cases where you trust the OCS and the network path between the OCS and you client computers.
define url.domain condition tolerate_sites_resp domain_1.com domain_2.com www.domain_3.com end
Refer to the following for Steffen Ullrich's HTTP Evader tool findings.
Extracted from the previous URL: "HTTP 0.9 style responses (i.e. no HTTP header) are simply passed through. These responses are accepted by all browsers except Safari. Maybe libhtp would log this too but again I could find no way to make Suricate show the problem."