<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ian Hickson wrote:
<blockquote
cite="mid:Pine.LNX.4.62.0806180430460.13974@hixie.dreamhostps.com"
type="cite">
<pre wrap="">On Wed, 18 Jun 2008, Shannon wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">ISSUE.2) We now only send valid HTTP(s) over HTTP(s) ports.
</pre>
</blockquote>
<pre wrap="">I understand the reasoning but I do not believe this should be limited
to ports 80 and 443.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
The current draft for TCPConnection is quite clear about this. The
unclear part is what a "Security Exception" is (currently undefined).<br>
<br>
------------ WHATWG HTML5 Draft --
<a class="moz-txt-link-freetext" href="http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html">http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html</a>
-- Section 6.3.4 ------<br>
If either:<br>
<br>
* the target host is not a valid host name, or<br>
* 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, <br>
<br>
...then the UA must raise a security exception.<br>
------------<br>
<br>
<blockquote
cite="mid:Pine.LNX.4.62.0806180430460.13974@hixie.dreamhostps.com"
type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">HIXIE.3) No existing SMTP server (or any non-TCPConnection server) is
going to send back the appropriate handshake response.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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).
</pre>
</blockquote>
<blockquote
cite="mid:Pine.LNX.4.62.0806180430460.13974@hixie.dreamhostps.com"
type="cite">
<blockquote type="cite">
<pre wrap="">Since the script author can also inject URIs into the handshake this
becomes a potential flaw.
</pre>
</blockquote>
<pre wrap=""><!---->
Indeed, we'd have to throw if the URI wasn't a valid URI (e.g. if it
included newlines).
</pre>
</blockquote>
<br>
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:<br>
<br>
tcp = new TCPConnection('<a class="moz-txt-link-freetext"
href="http://mail.domain.ext/%5C%5Cr%5C%5CnHELO">http://mail.domain.ext/Upgrade:TCPConnection/1.0</a>'
)
<br>
<br>
server>><br>
Upgrade:TCPConnection/1.0<br>
Error: Unrecognized command.<br>
<br>
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:<br>
<br>
Magic: <tcp allow>\r\n<br>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:Pine.LNX.4.62.0806180430460.13974@hixie.dreamhostps.com"
type="cite">
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap=""><!---->
That's basically what TLS is, right? The simple solution would be to just
tunnel everything through TLS when you hit an uncooperative proxy.
</pre>
</blockquote>
<br>
Not with a few lines of perl you don't.<br>
<br>
Shannnon<br>
<br>
</body>
</html>