[Sake Blok <sake@xxxxxxxxxx>]

On Tue, Apr 15, 2008 at 05:29:55PM +0100, DePriest, Jason R. wrote:
> 
> This end-user has an application that is trying to update itself.  The
> app is called LaserApp and both Wireshark and our proxy servers think
> this is a Bad Request.
> 
> I have attached three packets from a capture that are HTTP requests
> that Wireshark doesn't think are HTTP requests.
> 
> Here is a sample.
> 0000  00 e0 81 47 0d 0a 00 01 64 f9 1a 01 08 00 45 00   ...G....d.....E.
> 0010  00 fb 2a ad 40 00 7d 06 5e 24 ac 1c b9 c4 0a 46   ..*.@.}.^$.....F
> 0020  04 05 0e 28 1f 90 0f 51 d4 da 37 f6 b6 e2 50 18   ...(...Q..7...P.
> 0030  ff ff 91 84 00 00 43 4f 4e 4e 45 43 54 20 77 77   ......CONNECT ww
> 0040  77 2e 6c 61 73 65 72 61 70 70 2e 63 6f 6d 3a 34   w.laserapp.com:4
> 0050  34 33 20 48 54 54 50 2f 31 2e 30 0d 0a 43 6f 6e   43 HTTP/1.0..Con
> 0060  74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 36 31 35   tent-Length: 615
> 0070  0d 0a 50 72 61 67 6d 61 3a 20 6e 6f 2d 63 61 63   ..Pragma: no-cac
> 0080  68 65 0d 0a 50 72 6f 78 79 2d 43 6f 6e 6e 65 63   he..Proxy-Connec
> 0090  74 69 6f 6e 3a 20 6b 65 65 70 2d 61 6c 69 76 65   tion: keep-alive
> 00a0  0d 0a 48 6f 73 74 3a 20 77 77 77 2e 6c 61 73 65   ..Host: www.lase
> 00b0  72 61 70 70 2e 63 6f 6d 3a 34 34 33 0d 0a 41 63   rapp.com:443..Ac
> 00c0  63 65 70 74 3a 20 74 65 78 74 2f 68 74 6d 6c 2c   cept: text/html,
> 00d0  20 2a 2f 2a 0d 0a 55 73 65 72 2d 41 67 65 6e 74    */*..User-Agent
> 00e0  3a 20 4d 6f 7a 69 6c 6c 61 2f 34 2e 30 20 28 63   : Mozilla/4.0 (c
> 00f0  6f 6d 70 61 74 69 62 6c 65 3b 20 4c 61 73 65 72   ompatible; Laser
> 0100  20 41 70 70 29 0d 0a 0d 0a                         App)....
> 
> If I follow the TCP stream, Wireshark looks like it knows what it is.
> CONNECT www.laserapp.com:443 HTTP/1.0
> Content-Length: 615
> Pragma: no-cache
> Proxy-Connection: keep-alive
> Host: www.laserapp.com:443
> Accept: text/html, */*
> User-Agent: Mozilla/4.0 (compatible; Laser App)

Actually, Wireshark just displays the content of the TCP stream. It does
not *know* *what* it is showing.

> But the normal view just calls it TCP data.
> Transmission Control Protocol, Src Port: 3624 (3624), Dst Port: 8080
> (8080), Seq: 1, Ack: 1, Len: 211
>     Source port: 3624 (3624)
>     Destination port: 8080 (8080)
>     Sequence number: 1    (relative sequence number)
>     [Next sequence number: 212    (relative sequence number)]
>     Acknowledgement number: 1    (relative ack number)
>     Header length: 20 bytes
>     Flags: 0x18 (PSH, ACK)
>         0... .... = Congestion Window Reduced (CWR): Not set
>         .0.. .... = ECN-Echo: Not set
>         ..0. .... = Urgent: Not set
>         ...1 .... = Acknowledgment: Set
>         .... 1... = Push: Set
>         .... .0.. = Reset: Not set
>         .... ..0. = Syn: Not set
>         .... ...0 = Fin: Not set
>     Window size: 65535
>     Checksum: 0x9184 [validation disabled]
>         [Good Checksum: False]
>         [Bad Checksum: False]
>     TCP segment data (211 bytes)

The reason for Wireshark to not dissect this as HTTP is because the HTTP
dissecter only gets called for specific ports. You can edit the ports
that should be interpreted as HTTP in the HTTP protocol preferences
(go to Edit -> Preferences -> Protocol -> HTTP).

> Microsoft's Netmon3 doesn't seem to have any problems with it.
>   Frame:
> + Ethernet: Etype = Internet IP (IPv4)
> + Ipv4: Next Protocol = TCP, Packet ID = 10925, Total IP Length = 251
> + Tcp: Flags=...PA..., SrcPort=3624, DstPort=HTTP Alternate(8080),
> Len=211, Seq=257021146 - 257021357, Ack=938915554, Win=65535 (scale
> factor not found)
> - Http: Request, CONNECT www.laserapp.com:443
>   - Request:
>      Command: CONNECT
>    - URI: www.laserapp.com:443
>     - Uri:
>        Location: www.laserapp.com:443
>      ProtocolVersion: HTTP/1.0
>      ContentLength:  615
>      Pragma:  no-cache
>      Proxy-Connection:  keep-alive
>      Host:  www.laserapp.com:443
>      Accept:  text/html, */*
>      UserAgent:  Mozilla/4.0 (compatible; Laser App)
>      HeaderEnd: CRLF

I think MS netmon just displays the headers, without doing any reassembly.

> Can someone point out what is malformed?

Since Wireshark tries to do reassembly (like the applications at both
endpoints of the tcp session are doing), it tries to collect 615 of 
HTTP data after the HTTP headers. It is told to do so with the
"Content-Length: 615" header.

In the capture file you supplied these 615 bytes never come. Did you
filter them out? If so, please supply the whole tcp session to analyse.
If they were simply not there, than that's why you are having trouble.

The internet draft "Tunneling SSL Through a WWW Proxy" [1] specifies that
after the end of the http headers (ie an empty line), the client should 
wait for a response and then start setting up the SSL session.

The HTTP/1.1 RFC [2] specifies:

"The presence of a message-body in a request is signaled by the 
inclusion of a Content-Length or Transfer-Encoding header field 
in the request's message-headers. A message-body MUST NOT be 
included in a request if the specification of the request 
method (section 5.1.1) does not allow sending an entity-body 
in requests."

So either way, this client is violating the specs by either
sending http data to the proxy while it shouldn't or announcing
http data that it is never sending.

> The only thing I could find after reading through some RFCs was that
> the URI should probably have the "https://"; in front of it.  In other
> words, it should be "CONNECT https://www.laserapp.com:443"; instead of
> "CONNECT www.laserapp.com:443" but I was uncertain if that really
> makes that much of a difference.

Link [1] shows that "CONNECT www.laserapp.com:443" is according to the
specs. So that's not your issue :-)

Hope this helps,
Cheers,
    Sake

[1] http://muffin.doit.org/docs/rfc/tunneling_ssl.html
[2] http://www.faqs.org/rfcs/rfc2616.html