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
