On Wed, 5 Aug 2009, Amos Jeffries wrote:
On Wed, 5 Aug 2009 00:57:18 + (UTC), Ian Hickson i...@hixie.ch wrote:
On Thu, 30 Jul 2009, Robert Collins wrote:
On Wed, 2009-07-29 at 23:48 +, Ian Hickson wrote:
Surely once the HTTP server has decided that it can Upgrade, it
Ian Hickson wrote:
On Wed, 5 Aug 2009, Amos Jeffries wrote:
On Wed, 5 Aug 2009 00:57:18 + (UTC), Ian Hickson i...@hixie.ch wrote:
On Thu, 30 Jul 2009, Robert Collins wrote:
On Wed, 2009-07-29 at 23:48 +, Ian Hickson wrote:
Surely once the HTTP server has decided that it can Upgrade,
On Thu, 30 Jul 2009, Robert Collins wrote:
On Wed, 2009-07-29 at 23:48 +, Ian Hickson wrote:
Surely once the HTTP server has decided that it can Upgrade, it
doesn't actually need to worry about sending back something HTTP-valid
at all, since we can just say the entire connection
On Wed, 5 Aug 2009 00:57:18 + (UTC), Ian Hickson i...@hixie.ch wrote:
On Thu, 30 Jul 2009, Robert Collins wrote:
On Wed, 2009-07-29 at 23:48 +, Ian Hickson wrote:
Surely once the HTTP server has decided that it can Upgrade, it
doesn't actually need to worry about sending back
tor 2009-07-30 klockan 10:26 +1000 skrev Robert Collins:
In corporate networking, TLS MITM is a 'feature': company signed
certificates are used to sign the TLS connection to the corporate
firewall, and the firewall validate the SSL connection to the outside
world. I haven't personally used
On Sat, 18 Jul 2009, Amos Jeffries wrote:
But per HTTP specifications such body data is part of the HTTP Upgrade
request and should be ignored if switching protocols as part of
ignoring the HTTP request which contained the Upgrade request.
Consider for example if the request is a
On Wed, 2009-07-15 at 00:51 +, Ian Hickson wrote:
If there are any bytes allowed from the client or the server before
the
handshake starts, then it is no longer secure. The idea is to make
sure
you can't smuggle though payloads from other protocols, since
otherwise
you could use
On Wed, 2009-07-29 at 23:48 +, Ian Hickson wrote:
Surely once the HTTP server has decided that it can Upgrade, it
doesn't
actually need to worry about sending back something HTTP-valid at
all,
since we can just say the entire connection was always using the
WebSocket
protocol, and
On Thu, 30 Jul 2009, Robert Collins wrote:
What drives the desire to live on port 80?
Nothing. WebSocket will be on ports 81 and 815. The desire to share a port
with HTTP comes from port 443 being the only port that is usable in some
settings due to firewalls and mitm proxies.
--
Ian
On Thu, 2009-07-30 at 00:00 +, Ian Hickson wrote:
On Thu, 30 Jul 2009, Robert Collins wrote:
What drives the desire to live on port 80?
Nothing. WebSocket will be on ports 81 and 815. The desire to share a port
with HTTP comes from port 443 being the only port that is usable in some
On Fri, 2009-07-17 at 10:00 +, Ian Hickson wrote:
On Fri, 17 Jul 2009, Adrian Chadd wrote:
2009/7/17 Ian Hickson i...@hixie.ch:
That way you are still speaking HTTP right until the protocol
change occurs, so any and all HTTP compatible changes in the path(s)
will occur.
As
I missed that Ian was still talking about using port 80. I think
that's broken / more trouble than it's worth, for the reasons Adri is
going through.
If you have to tunnel using an existing port, use 443 (with null
encryption if you're worried about overhead, but still want to
fre 2009-07-17 klockan 16:32 +1200 skrev Amos Jeffries:
3.1.5.1
Connect to the server given by /host/ on port 80 and ask it to
upgrade from HTTP to WebSockets.
The client must send only the following lines:
GET /thepath/ HTTP/1.1
Host:
On Fri, 17 Jul 2009, Amos Jeffries wrote:
Um, okay. Have a read of this alternate Spec and see if you can stil
find the security hole you are woried about:
I don't understand in what way it substantially differs from what the spec
says today. There are minor differences in wording, but
On Fri, 17 Jul 2009, Adrian Chadd wrote:
2009/7/17 Ian Hickson i...@hixie.ch:
That way you are still speaking HTTP right until the protocol
change occurs, so any and all HTTP compatible changes in the path(s)
will occur.
As mentioned earlier, we need the handshake to be very precisely
On Fri, 17 Jul 2009, Mark Nottingham wrote:
I missed that Ian was still talking about using port 80. I think that's
broken / more trouble than it's worth, for the reasons Adri is going
through.
If you have to tunnel using an existing port, use 443 (with null
encryption if you're worried
fre 2009-07-17 klockan 10:00 + skrev Ian Hickson:
HTTP servers aren't the only concern, of course; we want the handshake to
be as secure as possible against any other protocol that may exist on any
server that may be deployed. We don't know what's out there (especially in
intranets),
Henrik Nordstrom wrote:
fre 2009-07-17 klockan 16:32 +1200 skrev Amos Jeffries:
3.1.5.1
Connect to the server given by /host/ on port 80 and ask it to
upgrade from HTTP to WebSockets.
The client must send only the following lines:
GET /thepath/ HTTP/1.1
Ian Hickson wrote:
On Fri, 17 Jul 2009, Amos Jeffries wrote:
Um, okay. Have a read of this alternate Spec and see if you can stil
find the security hole you are woried about:
I don't understand in what way it substantially differs from what the spec
says today. There are minor differences in
ons 2009-07-15 klockan 04:26 + skrev Ian Hickson:
On Tue, 14 Jul 2009, Alex Rousskov wrote:
WebSocket made the handshake bytes look like something Squid thinks it
understands. That is the whole point of the argument. You are sending an
HTTP-looking message that is not really an
ons 2009-07-15 klockan 07:34 + skrev Ian Hickson:
On Wed, 15 Jul 2009, Mark Nottingham wrote:
Upgrade is hop-by-hop, so it's pretty limiting.
Do man-in-the-middle proxies count as a hop for the purposes of HTTP?
When used as a surrogate it does.
The transparently interceping case is
tor 2009-07-16 klockan 01:44 + skrev Ian Hickson:
So Squid when used as a man-in-the-middle proxy will allow arbitrary
traffic through port 80 if it isn't HTTP traffic?
No, but support for tunneling WebSockets can be added, but not when it
looks and feels like a HTTP message.
This
ons 2009-07-15 klockan 07:18 + skrev Ian Hickson:
The reason we have a very strict handshake is because we don't want it to
be possible to trick a non-WebSocket-aware server into accepting a
connection (or similarly, having the client be tricked by the script into
accepting a
ons 2009-07-15 klockan 18:39 +1200 skrev Amos Jeffries:
Byte 5 through to the first of: two CRLF or one NULL byte. Specified as
step 1 through 11 by the looks of it.
Correctly operating:
* MUST remove the Upgrade: WebSocket\r\n bytes.
Yes/No depending on the context. If a normal forward
tor 2009-07-16 klockan 23:11 +1200 skrev Amos Jeffries:
The faux-request begins with: GET /path-bytes HTTP/1.1
It also contains Connection: Upgrade.
Only when not talking to a proxy. If a proxy is configured CONNECT is
used for setting up a tunnel first. See 3.1 Handshake, step 3.
For peers
Realise that server-side infrastructure often includes things like
CDNs (even when the content is uncacheable), reverse proxies and L7
load balancers -- all of which can make the changes we're talking about.
While it's true that these things are under control of the people who
own the
Yep. Just think it's worth pointing out in the draft, since you go to
such efforts to make this possible.
Cheers,
On 17/07/2009, at 10:28 AM, Ian Hickson wrote:
On Fri, 17 Jul 2009, Mark Nottingham wrote:
Realise that server-side infrastructure often includes things like
CDNs
(even
On Fri, 17 Jul 2009, Mark Nottingham wrote:
On 17/07/2009, at 10:28 AM, Ian Hickson wrote:
On Fri, 17 Jul 2009, Mark Nottingham wrote:
Realise that server-side infrastructure often includes things like
CDNs (even when the content is uncacheable), reverse proxies and L7
load
2009/7/17 Ian Hickson i...@hixie.ch:
That way you are still speaking HTTP right until the protocol change
occurs, so any and all HTTP compatible changes in the path(s) will
occur.
As mentioned earlier, we need the handshake to be very precisely defined
because otherwise people could trick
2009/7/15 Ian Hickson i...@hixie.ch:
On Tue, 14 Jul 2009, Alex Rousskov wrote:
WebSocket made the handshake bytes look like something Squid thinks it
understands. That is the whole point of the argument. You are sending an
HTTP-looking message that is not really an HTTP message. I think this
Upgrade is hop-by-hop, so it's pretty limiting.
Ian, an example:
An intermediary (transparent, intercepting or whatever) can and often
does add arbitrary headers; e.g., x-forwarded-for. This is completely
legal in HTTP, where headers that are not understood are ignored, and
additionally
On Wed, 15 Jul 2009 04:26:42 + (UTC), Ian Hickson i...@hixie.ch wrote:
On Tue, 14 Jul 2009, Alex Rousskov wrote:
WebSocket made the handshake bytes look like something Squid thinks it
understands. That is the whole point of the argument. You are sending an
HTTP-looking message that is
On Wed, 15 Jul 2009, Adrian Chadd wrote:
2009/7/15 Ian Hickson i...@hixie.ch:
On Tue, 14 Jul 2009, Alex Rousskov wrote:
WebSocket made the handshake bytes look like something Squid thinks it
understands. That is the whole point of the argument. You are sending an
HTTP-looking message
On Wed, 15 Jul 2009, Mark Nottingham wrote:
Upgrade is hop-by-hop, so it's pretty limiting.
Do man-in-the-middle proxies count as a hop for the purposes of HTTP? As
far as I can tell from the HTTP spec, the client is supposed to know
whether it is speaking to a proxy or not, so
On Wed, 15 Jul 2009, Amos Jeffries wrote:
Could you elaborate on what bytes Squid thinks it should change in the
WebSocket handshake?
Byte 5 through to the first of: two CRLF or one NULL byte. Specified as
step 1 through 11 by the looks of it.
Correctly operating:
* MUST remove
On 15/07/2009, at 5:34 PM, Ian Hickson wrote:
On Wed, 15 Jul 2009, Mark Nottingham wrote:
Upgrade is hop-by-hop, so it's pretty limiting.
Do man-in-the-middle proxies count as a hop for the purposes of
HTTP? As
far as I can tell from the HTTP spec, the client is supposed to know
whether
On Wed, 15 Jul 2009, Mark Nottingham wrote:
Can you remind me why you need the handshake to look like valid HTTP
again? I think that's the crux here.
Because in some cases, people will want to share the same port for their
HTTP server as for their WebSocket server. For example, if they want
Ian Hickson wrote:
On Wed, 15 Jul 2009, Amos Jeffries wrote:
Could you elaborate on what bytes Squid thinks it should change in the
WebSocket handshake?
Byte 5 through to the first of: two CRLF or one NULL byte. Specified as
step 1 through 11 by the looks of it.
Correctly operating:
* MUST
2009/7/15 Amos Jeffries squ...@treenet.co.nz:
a) Getting a dedicated WebSocket port assigned.
* You and the client needing it have an argument to get that port opened
through the firewall.
* Squid and other proxies can be altered to allow CONNECT through to safe
defined ports (80 is not
On 07/15/2009 01:59 AM, Ian Hickson wrote:
On Wed, 15 Jul 2009, Mark Nottingham wrote:
Can you remind me why you need the handshake to look like valid HTTP
again? I think that's the crux here.
Because in some cases, people will want to share the same port for their
HTTP server as for
On Thu, 16 Jul 2009, Amos Jeffries wrote:
What solution would you recommend for such a case?
a) Getting a dedicated WebSocket port assigned.
The plan is to ask for ports 81 and 815.
* You and the client needing it have an argument to get that port opened
through the firewall.
*
On Wed, 15 Jul 2009, Adrian Chadd wrote:
I think the fundamental mistake being made here by Ian (and potentially
others) is breaking the assumption that specific protocols exist on the
well-known ports. Suddenly treating stuff on port 80 as almost but not
quite HTTP is bound to cause
On Wed, 15 Jul 2009, Alex Rousskov wrote:
On 07/15/2009 01:59 AM, Ian Hickson wrote:
On Wed, 15 Jul 2009, Mark Nottingham wrote:
Can you remind me why you need the handshake to look like valid HTTP
again? I think that's the crux here.
Because in some cases, people will want to share
On Thu, 16 Jul 2009, Mark Nottingham wrote:
As an alternative, why not:
1) specify a new port for normal WebSocket operation, and
2) specify that if there's a proxy configured, ask the proxy to CONNECT to
your new port, and
3) specify that if #2 fails, they can CONNECT to 443 and ask for
On 16/07/2009, at 12:28 PM, Ian Hickson wrote:
On Thu, 16 Jul 2009, Mark Nottingham wrote:
As an alternative, why not:
1) specify a new port for normal WebSocket operation, and
2) specify that if there's a proxy configured, ask the proxy to
CONNECT to
your new port, and
3) specify that
On Thu, 16 Jul 2009, Mark Nottingham wrote:
So, to be clear, the only time the byte-for-byte HTTP handshake is used
is when it's over a TLS tunnel via CONNECT (i.e., it's not used to set
up the tunnel, but only once it's established)?
It's used whenever the client thinks it has a
tor 2009-07-02 klockan 17:59 -0700 skrev Jason Duell:
1) I have a quick question about the limitations that you put by
default on the CONNECT method. squid.conf contains
# Deny CONNECT to other than SSL ports
http_access deny CONNECT !SSL_ports
So squid by default only allows CONNECT to
tis 2009-07-14 klockan 23:35 +0200 skrev Henrik Nordstrom:
For what it's worth neither 81 or 815 is registered with IANA, and the
web-sockets draft you referenced has expired.
Correction, the draft is not expired as it was recently resubmitted to
IETF, but very much a work in progress.
The
ons 2009-07-08 klockan 07:00 + skrev Ian Hickson:
Well, the client is a WebSocket client, so it can always generate the
exact byte sequence specified in the spec almost by definition. The server
side is restrictive, but should be implementable without too much trouble
so long as there
On 07/14/2009 04:38 PM, Henrik Nordstrom wrote:
ons 2009-07-08 klockan 07:00 + skrev Ian Hickson:
Well, the client is a WebSocket client, so it can always generate the
exact byte sequence specified in the spec almost by definition. The server
side is restrictive, but should be
On Tue, 14 Jul 2009, Alex Rousskov wrote:
If you think your approach is the right one, I would suggest openly
discussing it with the right IETF folks as early as possible, to avoid
wasting your time on an idea they will be blocked later.
WebSocket is being discussed in the hybi IETF list.
On 07/14/2009 06:01 PM, Ian Hickson wrote:
On Tue, 14 Jul 2009, Alex Rousskov wrote:
HTTP hard-coding seems to be a small, albeit critical, part of
WebSocket so changing it to avoid conflicts with HTTP may be possible
without significant negative effects on the rest of the draft.
The
On Tue, 14 Jul 2009, Alex Rousskov wrote:
On 07/14/2009 06:01 PM, Ian Hickson wrote:
On Tue, 14 Jul 2009, Alex Rousskov wrote:
HTTP hard-coding seems to be a small, albeit critical, part of
WebSocket so changing it to avoid conflicts with HTTP may be possible
without significant
ons 2009-07-15 klockan 00:51 + skrev Ian Hickson:
Right -- and those things will prevent the connection, exactly as
intended. The idea is to make sure that if there is anything in between
that _isn't_ WebSocket-aware, the connection be dropped before the author
has any chance of sending
On 07/14/2009 06:51 PM, Ian Hickson wrote:
I want to avoid the following Squid bug report 5 years from now:
Title: Squid breaks FooBar
Comment1: FooBar, a WebSocket application, works fine unless there is a
transparent Squid proxy in the way. I have attached a packet trace.
Comment2:
On Tue, 14 Jul 2009, Alex Rousskov wrote:
WebSocket made the handshake bytes look like something Squid thinks it
understands. That is the whole point of the argument. You are sending an
HTTP-looking message that is not really an HTTP message. I think this is
a recipe for trouble, even
On Tue, 7 Jul 2009, Alex Rousskov wrote:
What is the motivation behind adding more ports?
WebSocket is its own protocol, so the right thing to do is to use new
ports. However, WebSocket can be sent over 80 or 443 quite happily.
Can websocket use port 80 (without CONNECT) and port 443 (with
ons 2009-07-08 klockan 15:16 +1200 skrev Amos Jeffries:
CONNECT to port-80 by default is IMO not an option. It pretty much
defeats all the other HTTP-level security measures.
For what it's worth, RFC2817 Upgrading to TLS Within HTTP/1.1 requires
CONNECT to be accepted to port 80.
Not that I
On Tue, 7 Jul 2009, Alex Rousskov wrote:
If WebSocket is a new protocol on top of TCP, new TCP ports are
appropriate.
Right.
Like virtually any protocol on top of TCP, WebSocket can then rely on
HTTP CONNECT tunneling mechanism without trying to redefine or narrow it
down.
Right.
On 07/02/2009 06:59 PM, Jason Duell wrote:
Hi there! I'm doing some work for Mozilla on the network stack for
Firefox, and there are a couple of items I wanted to run by the Squid
development team.
Hello Jason,
I am forwarding your email to squid-dev mailing list where it will
receive
On Tue, 2009-07-07 at 17:01 -0600, Alex Rousskov wrote:
The reason I ask is because we're looking to take a patch that
implements the IETF websockets protocol:
http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-17
I noticed that in section 3.1.3 the spec relies
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Collins wrote:
P.S. So every time that I set up squid on my machine to test something,
it always denies access to me out of the box. I finally figured out
it's because you don't allow localhost connections by default. Should
you be
Robert Collins wrote:
On Tue, 2009-07-07 at 17:01 -0600, Alex Rousskov wrote:
The reason I ask is because we're looking to take a patch that
implements the IETF websockets protocol:
http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-17
I noticed that in section 3.1.3 the spec
On 07/07/2009 05:39 PM, Ian Hickson wrote:
On Tue, 7 Jul 2009, Alex Rousskov wrote:
What is the motivation behind adding more ports?
WebSocket is its own protocol, so the right thing to do is to use new
ports. However, WebSocket can be sent over 80 or 443 quite happily.
If WebSocket is a
On Tue, 2009-07-07 at 22:28 -0400, Tres Seaver wrote:
I would argue that enabling only localhost for the default forward
proxy configuration is a sane default: people configuring things like
bastions ought not to expect to use out-of-the box configs without
review / tweakage, while people
Robert Collins wrote:
On Tue, 2009-07-07 at 22:28 -0400, Tres Seaver wrote:
I would argue that enabling only localhost for the default forward
proxy configuration is a sane default: people configuring things like
bastions ought not to expect to use out-of-the box configs without
review /
66 matches
Mail list logo
