<!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>