HTTP gurus, please chime in!
Client makes a connection across Checkpoint R61 on Nokia to an HTTP
service running on Server. SmartDefense rejects the connection:
Attack: Malformed HTTP
Attack Information: WSE0020001 illegal header format detected:
Illegal start line in request
Reason: 1B4
Packet capture shows three-way handshake, then Client issues an HTTP
POST with "Transfer-encoding: chunked", and "Expect: 100-continue"
headers. Server replies with "100-continue", which Client does. The next
packet is from Client, it has no HTTP headers, 443 bytes of data, and
the first bytes following the TCP header read "1B4", followed by CR LF
CR LF.
If I read HTTP 1.1 RFC 2616, sec. 3.6 correctly, 1B4 should refer to the
length of the following data in octets. Convert 1B4 from hex to decimal,
you get 436. Adding the seven octets 1b4 CR LF CR LF, makes exactly 443
octets.
Checkpoint support responds:
> Pertaining to that SK, he said that your customer is using 'Chunk'
> HTTP transfer encoding, and that the 'Content-Length'
> field is not included in the HTTP header.
> Because of this, we don't know the length of the Content Header, and
> so we don't know where the content header stops and the data portion
> of the packet starts. The Content-Length field in the header should
> have been included by the developers.
I think they're mistaken. From my reading of RFC 2616, "Content-Length"
does not specify the length of a header, but the length of the message
body being transferred. Also, it's illegal to have both:
4.4 Message Length
<snip>
Messages MUST NOT include both a Content-Length header field and a
non-identity transfer-coding. If the message does include a non-
identity transfer-coding, the Content-Length MUST be ignored.
Chunking is specifically intended to be used when you don't know how
much data will be transferred. That is, when you *can't* calculate the
"Content-length" header. It seems the app is perfectly compliant with
the RFC.
Further, Checkpoint's recommended fix is to "enable Active TCP
Streaming...by...checking 'ASCII Only Response Headers' ". This did
resolve the issue.
Ironically though, while passive TCP streaming complains when chunked
HTTP does *not* include a Content-length header, apparently the active
TCP streaming feature complains when both are present. The fix when that
happens is to use passive TCP streaming by unchecking "ASCII Only
Response Headers".
See, for example:
http://oldfaq.phoneboy.com/gurus/200609/msg00024.html
http://datacomguy.tripod.com/blog/labels/firewall.html
When I pointed this out to Checkpoint support, their response was "this
is a limitation of our passive streaming engine...As far as whether or
not this limitation is compliant with the RFC's, we would not be the
proper channel for that discussion, as I'm afraid we don't make those
kinds of determinations. For that, you would need to submit an RFE".
I did.
As this is not the only issue I have with it, I'm beginning to think I'm
better off eliminating SmartDefense completely. (Though it appears even
that is problematic.) SmartDefense, it would seem to me, is apparently
neither.
Dan Lynch, CISSP
Information Technology Analyst
County of Placer
Auburn, CA
=================================================
To set vacation, Out-Of-Office, or away messages,
send an email to [EMAIL PROTECTED]
in the BODY of the email add:
set fw-1-mailinglist nomail
=================================================
To unsubscribe from this mailing list,
please see the instructions at
http://www.checkpoint.com/services/mailing.html
=================================================
If you have any questions on how to change your
subscription options, email
[EMAIL PROTECTED]
=================================================
