[whatwg] TCPConnection feedback

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080618/c1184f2f/attachment.htm>

Received on Tuesday, 17 June 2008 23:23:55 UTC