Hi folks.
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)
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)
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
Can someone point out what is malformed?
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.
Thanks.
-Jason
--
NOTICE: Reading this email message requires root privileges which you
do not appear to possess. Sorry, dude.
Attachment:
WhatIsWrongWithMe.pcap.gz
Description: GNU Zip compressed data
