Ian Hickson wrote:
On Wed, 18 Jun 2008, Shannon wrote:
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.
You misunderstand; it's not the ports that are limited, it's just that the
traffic can now pass for HTTP. This would all still work over any
arbitrary port.
The current draft for TCPConnection is quite clear about this. The
unclear part is what a "Security Exception" is (currently undefined).
------------ WHATWG HTML5 Draft --
http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html
-- Section 6.3.4 ------
If either:
* the target host is not a valid host name, or
* the port argument is neither equal to 80, nor equal to 443, nor
greater than or equal to 1024 and less than or equal to 65535,
...then the UA must raise a security exception.
------------
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.
Indeed, we would need to very carefully define exactly what the server
must send back, much like in the original protocol -- it would just look a
lot more like HTTP. This would include at least one custom header or value
that you wouldn't see elsewhere (e.g. the Upgrade: header with the magic
value).
Since the script author can also inject URIs into the handshake this
becomes a potential flaw.
Indeed, we'd have to throw if the URI wasn't a valid URI (e.g. if it
included newlines).
I agree. Since the aim of the URI injection is to get an echo of a
valid header it is important that the server response include illegal
URI components that a server would not otherwise send. Newline could be
part of a legitimate response from a confused server or one that echos
commands automatically, eg:
tcp = new
TCPConnection('http://mail.domain.ext/Upgrade:TCPConnection/1.0' )
server>>
Upgrade:TCPConnection/1.0
Error: Unrecognized command.
Unlike my previous example this is a perfectly valid URI. Whatever the
magic ends up being it should aim to include illegal URI characters, ie:
angle-brackets, white-space, control characters, etc.. in an arrangement
that couldn't happen accidentally or through clever tricks. ie:
Magic: <tcp allow>\r\n
This example magic includes at least three characters that cannot be
sent in a valid URI (space, left angle bracket, right angle-bracket) in
addition to the newline and carriage returns.
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?
That's basically what TLS is, right? The simple solution would be to just
tunnel everything through TLS when you hit an uncooperative proxy.
Not with a few lines of perl you don't.
Shannnon
