[whatwg] TCPConnection feedback

[Shannon]

>
> ISSUE.2) We now only send valid HTTP(s) over HTTP(s) ports.
>   

I understand the reasoning but I do not believe this should be limited 
to ports 80 and 443. By doing so we render the protocol difficult to use 
as many (if not most) custom services would need to run on another port 
to avoid conflict with the primary webserver. I understand the logic for 
large public sites where "fascist firewalls" might prohibit other ports 
but for custom services (ie, remote-control, telnet emulation or 
accounting access) used within a company network this would be a real 
pain (requiring setup of reverse proxy or dedicated server). This would 
make a mockery of the whole premise of implementing services using "a 
few lines of perl".

Limiting to ports 80 and 443 doesn't really solve the security issues 
anyway. Many firewall/routers can be configured on this port and 
denial-of-service is just as effective (or more) against port 80 as any 
other port. The new proposal to use HTTP headers effectively allows 
arbitrary (in length and content) strings to be sent to any port 80 
device without informing the user. This would allow a popular page (say 
a facebook profile or banner ad) to perform massive DOS against web 
servers using visitors browsers without any noticeable feedback (though 
I guess this is also true of current HTTPXMLRequestObjects).

I propose that there be requirements that limit the amount and type of 
data a client can send before receiving a valid server response. The 
requirements should limit:
* Length of initial client handshake
* Encoding of characters to those valid in URIs (ie, no arbitrary binary 
data)
* Number or retries per URI
* Number of simultaneous connections
* Total number of connection attempts per script domain  (to all URIs)

There should also be a recommendation that UAs display some form of 
status feedback to indicate a background connection is occurring.

> HIXIE.3) No existing SMTP server (or any non-TCPConnection server) is going
> to send back the appropriate handshake response.
>   

It is always possible that non-http services are running on port 80. One 
logical reason would be as a workaround for strict firewalls. So the 
main defense against abuse is not the port number but the handshake. The 
original TCP Connection spec required the client to send only "Hello\n" 
and the server to send only "Welcome\n". The new proposal complicates 
things since the server/proxy could send any valid HTTP headers and it 
would be up to the UA to determine their validity. Since the script 
author can also inject URIs into the handshake this becomes a potential 
flaw. Consider the code:

tcp = TCPConnection('http://mail.domain.ext/\\r\\nHELO HTTP/1.1 101 
Switching Protocols\\r\\n' )

client>>
OPTIONS \r\n
HELO HTTP/1.1 101 Switching Protocols\r\n
HTTP/1.1\r\n

server>>
250 mail.domain.ext Hello \r\n
HTTP/1.1 101 Switching Protocols\r\n
 [111.111.111.111], pleased to meet you

As far as a naive UA and mail server is concerned we have now issued a 
valid challenge and received a valid response (albeit with some 
unrecognised/malformed headers). The parsing rules will need to be very 
strict to prevent this kind of attack. Limiting to port 80 reduces the 
number of target servers but does not prevent the attack (or others like 
it).

It may be that simply stripping newlines and non-ascii from URIs is all 
that's required since most text-based protocols are line oriented 
anyway. It depends largely on how OPTIONS and CONNECT are interpreted.

One last thing. Does anybody know how async communication would affect 
common proxies (forward and reverse)? I imagine they can handle large 
amounts of POST data but how do they feel about a forcibly held-open 
by-directional communication that never calls POST or GET? How would 
caches respond without expires or max-age headers? Would this hog 
threads causing apache/squid to stop serving requests? Would this work 
through Tor?

Shannon