- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 18 Jun 2008 04:35:32 +0000 (UTC)
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. > > 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). > 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. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 17 June 2008 21:35:32 UTC