Subject: [hybi] Criteria for evaluating handshake proposals

From: Alexey Melnikov <[email-masked]>
Date: Wed, 08 Dec 2010 20:23:31 +0000

I hope this is not going to turn into a lengthy debate, but I would like 
to understand what people care about when comparing different handshake 
proposals.
"Should use the minimal number of round trips" is one thing I've heard 
on the mailing list.
What are other things people care about?

Best Regards,
Alexey

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 8 Dec 2010 21:30:55 +0100

> What are other things people care about?

- Security
- Protocol compliance
- Compatibility with existing infrastructure, including the ability to
  route a request through various levels of reverse-proxies.

Regards,
Willy

---

From: Scott Ferguson <[email-masked]>
Date: Wed, 08 Dec 2010 13:21:22 -0800

>   route a request through various levels of reverse-proxies.

 - non-impact on pure HTTP server processing (primarily as performance). 
Adding WebSockets support shouldn't harm the non-websocket HTTP processing.

 - compatibility with existing configuration, management, security 
policy, access logging frameworks on the server/proxy end (minimal 
admin/management impacts, and not requiring an entire new management model)

If WebSockets is a separate port, the 2nd point can be modified or weakened.

-- Scott

> Regards,
> Willy
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>
>
>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 08 Dec 2010 22:45:01 +0100

>What are other things people care about?

Generally speaking it's a matter of minimizing disruption of deployed
infrastructure, minimizing resource consumption, and maximizing successs
rates, with some disagreements about the tradeoffs and the extent to
which one or the other should be done. At the moment we have questions
such as "Must the protocol prevent cache poisoning attacks", "Must the
protocol prevent attacks on shared hosting systems" and the constraints
must first be agreed upon before we can apply criteria that help us 
evaluate the many handshake proposals we've seen (which is in part due
to "handshake" and "framing" being not entirely seperable issues; some
framing methods make the handshake largely irrelevant, for instance).
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Zhong Yu <[email-masked]>
Date: Wed, 8 Dec 2010 15:55:20 -0600

It's ironic that nobody emphasizes on success rate now. At least I
haven't heard any recently. Yet that was the reason that current
WebSocket proposals are contained in HTTP connections on port 80.

If we are happy with the 70-80% success rate with a "raw" WebSocket
protocol over today's internet infrastructure, and if we are in a
hopeless gridlock if we try to improve the success rate by dressing
WebSocket in HTTP's clothes, maybe we should just abandon HTTP and go
with a "raw" WebSocket on a new port.

At least, we deserve a new trial after such a long time. The original
proponents of building WebSocket in HTTP should examine the new
evidences and discussions and remake the case.

The success rate is only an initial problem anyway. After WebSocket is
widely deployed, the obstacles that prevent successful WebSocket
connections will be under great pressure to correct themselves. People
are dying to have WebSocket. It's hard to see why this little initial
problem can have any significant impact on adoption rate. As far as
success rate is concerned, everyday WebSocket isn't deployed is a day
it has 0% success rate.

- Zhong Yu

---

From: Zhong Yu <[email-masked]>
Date: Wed, 8 Dec 2010 16:18:10 -0600

> connections will be under great pressure to correct themselves. People

And if today's firewalls block WebSocket connections, we should not
count that as failure. The firewalls are doing what they are supposed
to do. Whether they should be modified to allow WebSocket is up to the
firewall admins. We should not make that decision for them. What gives
WebSocket the right to *cheat* these firewalls? If the cheating is
successful, aren't we designing something that *breaks* security?

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 9 Dec 2010 09:20:18 +0100

> What are other things people care about?

Making some progress of some kind in some direction

---

From: Zhong Yu <[email-masked]>
Date: Thu, 9 Dec 2010 03:41:02 -0600

> Making some progress of some kind in some direction

Is it also possible that people made too much progress and got lost?

I think we should go back to basic, starting from a "pure" WS
protocol. People who want HTTP head for WS connection should remake
their case. Now we have more experience after much contemplation and
discussion, we are in a better position to value its worth.

- Zhong Yu

---

From: Bruce Atherton <[email-masked]>
Date: Fri, 10 Dec 2010 11:02:46 -0800

> with a "raw" WebSocket on a new port.

Maybe I'm just being dense, but if you decide to abandon port 80 I 
really don't understand why hybi exists at all. There are plenty of 
bidirectional protocols around. Why not just adopt one of those into 
browsers and servers. Use XMPP. Or SIP. Both of those are widely 
deployed and have a significant amount of infrastructure supporting them.

> success rate is concerned, everyday WebSocket isn't deployed is a day

I don't agree that opening up a Websocket port is a temporary problem. I 
think that examining the adoption rates of XMPP and SIP can be 
instructive on this point.

With the large enterprises I deal with, at least, opening a port to the 
public for XMPP has a fairly low uptake. While there are obvious 
benefits to opening it, the increase in perceived risk by doing so 
combined with the the cost of doing a complete security audit on 
software to run on that port keeps it from happening.

In contrast, there is a clear business case to be made regarding SIP. 
The savings in telecommunications costs can be substantial. So the 
adoption of SIP is progressing, but slowly. Once they finally decide to 
take the plunge, large enterprises are taking between 2 to 5 years to 
roll out SIP. The budgets involved are large.

What would the business case be for websockets that would justify the 
cost and perceived risk of opening a port in these environments? Anyone 
who wanted to sell software into Fortune 500 companies would have to 
make sure that their software could fall back to non-websocket use, 
since initially there would be no port available. And since none of the 
software they want to buy will actually require websockets, there will 
never be a compelling case for large organizations to open the port. It 
would require an absolutely-must-have killer app that could only be 
deployed using websockets  to motivate them to do it. Good luck finding 
one of those.

Now, you may say you don't care about the large enterprises, that 
websockets is a proletariat protocol. Unfortunately many of the people 
who write web applications (who are presumably one of the targets of the 
websockets spec) would rather like a chance to sell into those 
companies. That means they will have to write their applications to run 
both with and without websockets.

Consider the problems there have been dealing with IE6, where the large 
organizations have been the worst holdouts in keeping IE6 compatibility 
a requirement in web applications. Fortunately we are finally coming to 
the point where that is no longer necessary. It would be nice if we 
could see the same path forward where we could eventually drop having to 
support a lack of web sockets in applications. If a special port is 
required for websockets, I'm not sure we'll ever see it. If it is a 
matter of upgrading HTTP infrastructure so that it is websocket aware, 
eventually enough equipment will be upgraded that we can make the 
assumption that websockets are available.

That is my perspective, anyway.

---

From: Jack Moffitt <[email-masked]>
Date: Fri, 10 Dec 2010 13:43:21 -0700

> Maybe I'm just being dense, but if you decide to abandon port 80 I really don't understand why hybi exists at all. There are plenty of bidirectional protocols around. Why not just adopt one of those into browsers and servers. Use XMPP. Or SIP. Both of those are widely deployed and have a significant amount of infrastructure supporting them.

The message based framing makes it usable by JavaScript. Neither SIP
nor XMPP can help with that problem.

jack.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 10 Dec 2010 21:54:04 +0100

> nor XMPP can help with that problem.

?

The Javascript is supposed to get the *contents* of the frames.

Best regards, Julian

---

From: John Tamplin <[email-masked]>
Date: Fri, 10 Dec 2010 15:56:24 -0500

On Fri, Dec 10, 2010 at 2:02 PM, Bruce Atherton <[email-masked]> wrote:

> think that examining the adoption rates of XMPP and SIP can be instructive
> on this point.
>
> public for XMPP has a fairly low uptake. While there are obvious benefits to
> opening it, the increase in perceived risk by doing so combined with the the
> cost of doing a complete security audit on software to run on that port
> keeps it from happening.
>
> In contrast, there is a clear business case to be made regarding SIP. The
> savings in telecommunications costs can be substantial. So the adoption of
> SIP is progressing, but slowly. Once they finally decide to take the plunge,
> large enterprises are taking between 2 to 5 years to roll out SIP. The
> budgets involved are large.
>
> What would the business case be for websockets that would justify the cost
> and perceived risk of opening a port in these environments? Anyone who
> wanted to sell software into Fortune 500 companies would have to make sure
> that their software could fall back to non-websocket use, since initially
> there would be no port available. And since none of the software they want
> to buy will actually require websockets, there will never be a compelling
> case for large organizations to open the port. It would require an
> absolutely-must-have killer app that could only be deployed using websockets
>  to motivate them to do it. Good luck finding one of those.
>
> websockets is a proletariat protocol. Unfortunately many of the people who
> write web applications (who are presumably one of the targets of the
> websockets spec) would rather like a chance to sell into those companies.
> That means they will have to write their applications to run both with and
> without websockets.
>
> organizations have been the worst holdouts in keeping IE6 compatibility a
> requirement in web applications. Fortunately we are finally coming to the
> point where that is no longer necessary. It would be nice if we could see
> the same path forward where we could eventually drop having to support a
> lack of web sockets in applications. If a special port is required for
> websockets, I'm not sure we'll ever see it. If it is a matter of upgrading
> HTTP infrastructure so that it is websocket aware, eventually enough
> equipment will be upgraded that we can make the assumption that websockets
> are available.
>

The problem with this comparison is that none of the currently proposed
handshakes are going to transit typical enterprise firewall/proxy setups on
port 80 anyway, as they require a CONNECT to the proxy and then give the URL
of the target server.  However, most such proxies are configured out of the
box to allow only connections to 443 via CONNECT, requiring GET/PUT
http://full/url ... instead for non-encrypted traffic.

So, WebSocket is not likely to pass those proxies as-is on port 80 anyway,
and will require software upgrades and/or reconfiguration to do so.  Of
course, wss on port 443 would likely transit cleanly, so servers that want
to be able to reach those users will likely have to use wss instead.  Still,
that at least does give a way through the deployed firewalls, rather than a
dedicated port having no chance.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 10 Dec 2010 22:21:04 +0100

> dedicated port having no chance.

Indeed, and that also means that instead of reinventing every combination
of proxy/non-proxy + secure/non-secure protocol, we'd better stick to plain
HTTP standards. For the time it takes for various components to be fixed to
implement them, the WSS fallback will likely be used a lot. Admins who are
not comfortable with WSS will pressure their vendors to fix their HTTP
implementations. Sticking to standards is better than defining new ones
because for vendors, there's always an established base on which to improve
through small incremental fixes, instead of writing everything from scratch
and leaving bugs and interoperability issues everywhere for the next 10 years.

We could have an upgrade-based handshake both for direct connections and
proxied connections and the connect for proxied WSS connections. Some
products will definitely fail the first one but this will be due to an
implementation bug which will eventually get fixed.

Willy

---

From: Zhong Yu <[email-masked]>
Date: Fri, 10 Dec 2010 19:28:07 -0600

On Fri, Dec 10, 2010 at 1:02 PM, Bruce Atherton <[email-masked]> wrote:
> Maybe I'm just being dense, but if you decide to abandon port 80 I really
> don't understand why hybi exists at all. There are plenty of bidirectional

Bruce, I think the main goal is to have a socket-like messaging system
available to javascript on web pages. HTTP is certainly in the
background, but it's not a priori that WS protocol should be HTTP
like.

That goal itself is quite simple. However people are demanding more
features, and these tangential features are hurting the progress of
achieving the main goal.

> protocols around. Why not just adopt one of those into browsers and servers.
> Use XMPP. Or SIP. Both of those are widely deployed and have a significant
> amount of infrastructure supporting them.
>
> Now, you may say you don't care about the large enterprises, that websockets
> is a proletariat protocol. Unfortunately many of the people who write web

I agree we must respect all interests from all parties, even big evil
corporations:)

I guess the WSS:433 fallback is the best trick we have now for
connectivity. With that trick available, we can remove the concern of
connectivity from WS protocol design, and we may focus more on
semantics, and end up with something that doesn't smell hackish.

> applications (who are presumably one of the targets of the websockets spec)
> would rather like a chance to sell into those companies. That means they
> will have to write their applications to run both with and without
> websockets.
>

---

From: Bruce Atherton <[email-masked]>
Date: Fri, 10 Dec 2010 18:46:11 -0800

Sorry, I'm not quite clear on what you are saying. Are you saying that 
the protocol needs to support message semantics rather than stream in 
order to be used by Javascript?

Anytime you open a socket you get a stream interface and have to apply 
message semantics to that. Both XMPP and SIP have defined ways of doing 
so, XMPP with the XML Stanza, SIP based on the protocol of the session 
it is setting up, for example RFC 4571 or RFC 4975 (MSRP).

In any case, I was offering these as examples only. There are plenty of 
other bidirectional protocols around.

---

From: Bruce Atherton <[email-masked]>
Date: Fri, 10 Dec 2010 18:55:47 -0800

On 10/12/2010 12:56 PM, John Tamplin wrote:
> So, WebSocket is not likely to pass those proxies as-is on port 80 
> anyway, and will require software upgrades and/or reconfiguration to 
> do so.

Right. It will take a while, but I can foresee a time when Apache HTTP 
Server and IIS support websockets (including in reverse proxy mode), the 
more popular load balancers support it, some of the more common proxy 
servers also. Once that happens and upgrades have rolled out for a 
while, it will be safe to rely on websockets being present. Say in 7 to 
10 years we can stop testing our applications against a websocketless 
environment. But I cannot see much of a chance that a websocket port is 
going to be commonly opened up in these environments. There are too many 
barriers and not enough incentives.

---

From: Bruce Atherton <[email-masked]>
Date: Fri, 10 Dec 2010 19:12:01 -0800

Ok, so let me see if I can paraphrase you correctly to make sure I am 
understanding. You want a session-oriented message based protocol that 
is lighter and simpler than any of the ones that currently exist. It can 
run on its own port and look nothing like HTTP in its unsecured form, 
but in its secured form it has to be HTTP compliant until it is 
upgraded/tunneled, so that a secure server running on port 443 can 
distinguish between HTTPS and Secure Websockets.

Is that it?

> background, but it's not a priori that WS protocol should be HTTP
...

---

From: Zhong Yu <[email-masked]>
Date: Fri, 10 Dec 2010 22:04:54 -0600

Bruce, let's say the current GET+Upgrade draft becomes the official
design. For anyone criticizing its low success rate, we can give the
stock answer: use it on TLS on port 443.

This solution shouldn't be a problem for any "serious" applications.
But for the interest of low budget applications, we should allow
self-signed certificates, so that TLS on 443 is a cheap solution to
everyone. If TLS is too heavy for server CPU, app can first attempt
with WS, which has a 80%(?) chance of success.

This solution achieves the highest success rate(~95%), one that we
cannot achieve with plain WS connection, no matter how the protocol is
designed.

- Zhong Yu

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 11 Dec 2010 13:02:19 +0100

> think that examining the adoption rates of XMPP and SIP can be instructive

Bruce,

this is indeed an interesting perspective.

But what I think is different here is that we have the browser vendors
interested in deploying a new protocol in their browsers.    If SIP or
XMPP was built into the browsers and an API provided in HTML-5, then
the driver for adoption of their ports might well be stronger.

I don't think we should underestimate the significance of the interest
from the browser vendors to accept a new protocol.

cheers

---

From: Maciej Stachowiak <[email-masked]>
Date: Sat, 11 Dec 2010 20:46:32 -0800

> from the browser vendors to accept a new protocol.

My expectation is that shipping a feature in multiple browsers is likely to increase the interest level among Web application authors, and among server software implementors, but is quite unlikely to have the effect of making firewall rules more permissive. The organizations that maintain restrictive firewalls have already decided that the restrictions are worth more to them than convenience of their users.

Regards,
Maciej

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 12 Dec 2010 21:18:11 +1100

> My expectation is that shipping a feature in multiple browsers is likely to increase the interest level among Web application authors, and among server software implementors, but is quite unlikely…

You're painting with an awfully broad brush there; how ever can you hold it?

I've helped administer firewalls for ISPs, a University, quite a few mid-sized companies and a Fortune 25 company. IME people running firewalls are under enormous pressure to make sure that things don't break, because they have to deal with the support load.

IME new applications using new ports are evaluated and opened when the risk is quantified. Applications that smuggle traffic on existing ports tend to have be blocked outright until an inspection layer can be put in (in your more paranoid deployments).

You're sad (to use Adam's terminology) because a bank employee won't be able to use WebSockets from their terminal until their firewall administrator approves it and opens a port. From the perspective of that bank's network people, risk management folks, indemnity folks, compliance folks and shareholders, that's a feature, not a bug.

--
Mark Nottingham   http://www.mnot.net/

---

From: Bruce Atherton <[email-masked]>
Date: Sun, 12 Dec 2010 13:18:13 -0800

You may be right. I may be overly pessimistic.

I can't help thinking, though, about the billions of dollars the 
industry has spent in order to adopt SOAP to run RPC calls over the 
magic port 80, rather than just opening a separate port for each RPC 
service or running CORBA as used to be done. This despite the fact that 
the exact same code runs in each case, with the exception of marshalling 
and intermediaries being passed through.

Opening public ports is just that difficult.

But perhaps browser support and all the added incremental benefits 
available from webapps will provide a tipping point, as you say. We can 
always hope.

---

From: Bruce Atherton <[email-masked]>
Date: Sun, 12 Dec 2010 13:31:49 -0800

All I can say is that your experience is vastly, utterly unlike my own.

Most of my customers are Fortune 500, and many are Fortune 25. The 
problem with opening another port is that the risk is so very difficult 
to quantify. And the costs if someone gets it wrong are so devastating. 
The general attitude I have run into has been, "Nobody ever got fired 
for keeping a port closed."

It isn't a matter of just doing a security audit on the software 
involved. System administrators have to become utterly convinced that 
they have a complete handle on all the security implications of all 
aspects of configuring a program or piece of equipment. Needless to say, 
this requires considerable effort on their part, and they are not 
looking to expand their workload by adding to the list of programs they 
need to support. That is why although my web application includes a 
perfectly good web server (Greg's Jetty server) virtually all my 
enterprise customers front that with an instance of Apache HTTP Server 
or IIS. Those are pieces of software that they completely grok.

---

From: John Tamplin <[email-masked]>
Date: Sun, 12 Dec 2010 20:52:21 -0500

> with WS, which has a 80%(?) chance of success.

If we allow self-signed certificates with no warning or having to
install a certificate, then we allow arbitrary man-in-the-middle
attacks against any WSS services.

All you have to do is get your server in the victim's DNS through some
exploit, then use your self-signed cert for the target server and you
can freely impersonate it.

The only way you can allow self-signed certs without a warning is if
we were to use encryption even for ws to protect against passive
eavesdropping or to prevent attacker control of payload bytes, in
which case you can relax protections against MITM attacks there.

---

From: John Tamplin <[email-masked]>
Date: Sun, 12 Dec 2010 20:54:46 -0500

> evidences and discussions and remake the case.

Note that unless you disallow use of WebSocket/dedicated port over
ports 80/443, then you still have to worry about it being used to
attack the existing HTTP infrastructure.

---

From: Roberto Peon <[email-masked]>
Date: Sun, 12 Dec 2010 18:04:56 -0800

> can freely impersonate it.

This is no more or less true than it is for HTTP or anything in the clear
and without crypto verification.
When we have 'secure websockets', this would become more interesting-- in
that case, self-signed certs would be silly.

> which case you can relax protections against MITM attacks there.

I think that is the idea behind the :443 proposals, no?
-=R

---

From: Zhong Yu <[email-masked]>
Date: Sun, 12 Dec 2010 21:21:30 -0600

> attacks against any WSS services.

We allow that attack in plain WS already, without any warning. What
I'm saying is, encryption without authentication does not necessarily
deserve more warning than no encryption at all.

By default we should still assume that a WSS app intends to have
authentication checked. However we should allow the app to express
another intention - encryption without authentication. This option can
be provided by WS API
    WebSocket.allowSelfSignedCertificate()

It is used by low budge webapps that don't want to deal with
certificate authorities. The security aspect is weaker, but it is
still very useful. I don't see why we should deprive app developers
this useful tool(unless I'm a CA).

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 13 Dec 2010 01:18:26 -0800

> IME new applications using new ports are evaluated and opened when the risk is quantified. Applications that smuggle traffic on existing ports tend to have be blocked outright until an inspection l…

That sounds contrary to what Bruce said about XMPP. He reports that uptake of a custom port for XMPP in firewall configurations has been very slow, but it seems running XMPP over port 80 is not frequently blocked.

> You're sad (to use Adam's terminology) because a bank employee won't be able to use WebSockets from their terminal until their firewall administrator approves it and opens a port. From the perspect…

I'm not happy or sad about any given state of affairs here, I am just making my prediction. 

To be clear about what I'm claiming: WebSocket on a custom port is not going to be any more successful at getting that port opened than a protocol like XMPP. Just the fact that it is present in the browser isn't likely to be a key driver. 

To create any pressure to open the port, it needs killer apps. But the killer apps are much less to happen so long as a significant percentage of users can't make use of them. This pushes towards some sort of fallback strategy (smuggle on port 80, fall back to "COMET"). But if all meaningful apps have a good-enough fallback, that reduces any pressure to open a port.

Realistically, to offer any new network capabilities in a form that Web applications can rely on, it has to be on tcp port 80 or tcp port 443. Claims otherwise seem to be based on wishful thinking, not a realistic assessment of the state of play and the historical record.

Regards,
Maciej

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 13 Dec 2010 20:38:10 +1100

> That sounds contrary to what Bruce said about XMPP. He reports that uptake of a custom port for XMPP in firewall configurations has been very slow, but it seems running XMPP over port 80 is not fre…

No offence intended to our XMPPing bretheren, but I think that has more to do with the uptake of XMPP than anything else. Most of that market is still tied up in proprietary protocols...

It also may be a touch of observer bias; as someone pushing a protocol, you do tend to hear about the problems people have, which distorts how common they seem vs. how common they actually are.

> To create any pressure to open the port, it needs killer apps. But the killer apps are much less to happen so long as a significant percentage of users can't make use of them. This pushes towards s…

I agree, but come to a different place. You say a 'significant percentage' of connections won't be able to use WebSockets if it doesn't use port 80, but Adam's work as well as discussion and experience suggest that interception proxies and inspecting firewalls mean a 'significant percentage' of people won't be able to use port 80. Catch-22.

It would be nice to have real numbers behind those percentages, but until someone does an exhaustive, peer-reviewed study (or more than one, followed by a longitudinal study), we'll have to spit-ball it.

Regardless, I'd suggest that however WebSockets negotiates, and whatever port it runs on, people are going to either have to use fallback strategies, or accept that not 100% -- probably not even 90% -- of people will be able to use them. Does anyone dispute that?

And, it makes me ask again: what's wrong with 443? It avoids the interception proxy issues (anyone intercepting 443 -- and it does happen! -- is expecting SSL/TLS traffic, so there are ways to reliably jam that). Not that it'll get you 100%, of course.

> Realistically, to offer any new network capabilities in a form that Web applications can rely on, it has to be on tcp port 80 or tcp port 443. Claims otherwise seem to be based on wishful thinking,…

Please, technical arguments, not rhetoric.

Regards,

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 13 Dec 2010 11:10:56 +0100

I don't think this is an either/or question about another port.

If we get a WS port, then it is indeed naive to expect 100% of
firewalls will open it.  But some/many will and in those cases it will
work well (the way the internet was intended to work).

We can then have a fall back to try something over port 80.   This
could be a fall back all the way to some long polling solution or it
could be a CONNECT to the dedicated websocket port.

Yes I know fallbacks add complexity - but there is no 100% solution,
so it's not good an advocate of proposal X saying to those advocating
proposal Y: "your proposal only works 80% of the time".  I think we
are all living in that particular glass house.

regards

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 13 Dec 2010 02:25:30 -0800

> And, it makes me ask again: what's wrong with 443? It avoids the interception proxy issues (anyone intercepting 443 -- and it does happen! -- is expecting SSL/TLS traffic, so there are ways to reli…

I like port 443. It seems likely to have a higher success rate than any of the proposed port 80 solutions.

For purpose of clarity, do you mean WebSocket protocol over TLS over port 443, or just running anon-TLS protocol over 443? I think the former is likely to be more effective, but some WG members are concerned about the performance impact.

Regards,
Maciej

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Dec 2010 06:21:56 -0800

On Mon, Dec 13, 2010 at 2:25 AM, Maciej Stachowiak <[email-masked]> wrote:

> > And, it makes me ask again: what's wrong with 443? It avoids the
> interception proxy issues (anyone intercepting 443 -- and it does happen! --
> is expecting SSL/TLS traffic, so there are ways to reliably jam that). Not
> that it'll get you 100%, of course.
>
> For purpose of clarity, do you mean WebSocket protocol over TLS over port
> 443,

I'm fine with this.

> or just running anon-TLS protocol over 443? I think the former is likely to
> be more effective, but some WG members are concerned about the performance
> impact.
>
>
If "anon-TLS" is a typo for "a non-TLS" as opposed to some TLS variant where
we don't check the cert,
I'm very un-fine with this. Surely, one will often want to run WS over TLS,
and it's not reasonable
to expect the TLS stack to demux based on the leading bytes from the client.

-Ekr

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 13 Dec 2010 15:50:21 +0100

On Mon, Dec 13, 2010 at 08:38:10PM +1100, Mark Nottingham wrote:
> You say a 'significant percentage' of connections won't be able to use WebSockets if it doesn't use port 80, but Adam's work as well as discussion and experience suggest that interception proxies and inspecting firewalls mean a 'significant percentage' of people won't be able to use port 80. Catch-22.

If I were picky, I'd say that Adam's experiment was meant to try to make
intermediaries fail, not to help them pass. That said, other experiments
in the past have shown limited success (though we must not forget that
draft-76 is not HTTP-compliant).

> And, it makes me ask again: what's wrong with 443? It avoids the interception proxy issues (anyone intercepting 443 -- and it does happen! -- is expecting SSL/TLS traffic, so there are ways to reli…

There's something I like with using port 443 : websocket represents the same
risk level as HTTPS for companies : if you let it pass, you assume the risk
that anyone could run remote shells or the like over it. So it is possible
that both HTTPS and WS will be filtered the same way, based on a white-list.
Also, having them share the same port means that it's easier to ensure
cross-protocol protection. Thus we can safely fall back to the simple HTTP
Upgrade-based handshake (GET+101) which has the advantage of not conflicting
with HTTPS and of being easily parsable by the same components when filtering
is required.

That's something we should seriously consider IMHO.

Cheers,
Willy

---

From: John Tamplin <[email-masked]>
Date: Mon, 13 Dec 2010 10:05:20 -0500

> That's something we should seriously consider IMHO.

Are you suggesting we only support 443?  If not, we still have to have
a handshake for use on port 80, and it doesn't seem useful to have
different handshakes in those cases.

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 13 Dec 2010 16:31:56 +0100

> different handshakes in those cases.

I think that port 80 would be the best one, but let's face it, we've
stayed at the same point for a few months just to sort out the security
VS routing VS accessibility issues. Opening a new port can take a long
time at some places (months/years in some companies). Reusing an existing
one which is compatible with that usage and processed by the same components
makes sense, thus we could attempt to use 443 exclusively. I'm not sure how
the server-side infrastructure is ready to accept this though. Some components
can automatically detect HTTP vs HTTPS on a given port, but others might
probably not, thus causing a new issue.

Willy

---

From: Bruce Atherton <[email-masked]>
Date: Mon, 13 Dec 2010 09:40:04 -0800

> It also may be a touch of observer bias; as someone pushing a protocol, you do tend to hear about the problems people have, which distorts how common they seem vs. how common they actually are.

I'm not quite sure what gave you that impression. My application speaks 
12 different communications protocols, XMPP and SIP are just two of 
them. I'm completely neutral as to which ones a customer uses. My 
indifferent observation is that SIP is slowly but surely being rolled 
out because there is a very strong business case that can be made for 
doing so. XMPP just isn't penetrating to any large degree in those 
environments.

---

From: Andrew Miadowicz <[email-masked]>
Date: Mon, 13 Dec 2010 18:25:32 +0000

In all the discussion about tunneling WebSockets through TLS over port 443 to increase the success rate I haven't heard any mention of the "HTTPS inspection" feature now sported by some corporate proxies (some references below).  The basic idea is to insert a local CA into the list of browser's trusted CAs, effectively terminate the SSL connection at the proxy by auto-generating a certificate, and then inspect the traffic in clear text as it crosses the proxy.  Clearly, if such a proxy is not designed to understand WebSockets, it will simply reject WebSocket traffic.  Certain organizations (it's hard to determine what proportion) are under pressure to deploy such solutions due to various laws and government regulations.

There is also the question of existing L7 routers or load balancers, which terminate SSL connections specifically to examine the traffic at the HTTP level to make their decisions.  Here again, WebSocket connections will fail unless these intermediaries learn to handle the protocol correctly.

In my mind at least, tunneling over 443 is not a panacea.

Andrew

Microsoft TMG HTTPS Inspection: 
 - http://www.microsoft.com/forefront/threat-management-gateway/en/us/features.aspx
 - http://technet.microsoft.com/en-us/magazine/ff472472.aspx
Blue Coat SSL Proxy: 
 - http://www.bluecoat.com/news/pr/202 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Willy Tarreau
Sent: Monday, December 13, 2010 7:32 AM
To: John Tamplin
Cc: [email-masked]
Subject: Re: [hybi] Criteria for evaluating handshake proposals

On Mon, Dec 13, 2010 at 10:05:20AM -0500, John Tamplin wrote:
> > There's something I like with using port 443 : websocket represents 
> > the same risk level as HTTPS for companies : if you let it pass, you 
> > assume the risk that anyone could run remote shells or the like over 
> > it. So it is possible that both HTTPS and WS will be filtered the same way, based on a white-list.
> > Also, having them share the same port means that it's easier to 
> > ensure cross-protocol protection. Thus we can safely fall back to 
> > the simple HTTP Upgrade-based handshake (GET+101) which has the 
> > advantage of not conflicting with HTTPS and of being easily parsable 
> > by the same components when filtering is required.
> >

I think that port 80 would be the best one, but let's face it, we've stayed at the same point for a few months just to sort out the security VS routing VS accessibility issues. Opening a new port can take a long time at some places (months/years in some companies). Reusing an existing one which is compatible with that usage and processed by the same components makes sense, thus we could attempt to use 443 exclusively. I'm not sure how the server-side infrastructure is ready to accept this though. Some components can automatically detect HTTP vs HTTPS on a given port, but others might probably not, thus causing a new issue.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 13 Dec 2010 20:46:11 +0100

> In all the discussion about tunneling WebSockets through TLS over port 443 to increase the success rate I haven't heard any mention of the "HTTPS inspection" feature now sported by some corporate p…

I've seen this method massively rejected in field because it hides SSL issues,
because it does not give the choice to the user. Either you configure them to
reject SSL sites that do not present a valid certificate, and users complain
that many sites cannot be accessed, or you configure them to accept those bad
certificates, and SSL becomes useless because many sites can now easily be
spoofed since the appliance will replace a bad certificate with a good one.

Anyway, your comment makes a good point about how SSL components will have
to handle non-SSL traffic on port 443. My point was that it's easier to
*reliably* distinguish SSL from WS than it is to *reliably* distinguish
HTTP from WS.

> There is also the question of existing L7 routers or load balancers, which terminate SSL connections specifically to examine the traffic at the HTTP level to make their decisions.  Here again, WebS…

Which will also be true for all components designed to inspect contents and
that don't expect to find WS there (eg: CONNECT on port 80, etc...).

> In my mind at least, tunneling over 443 is not a panacea.

I'm not saying it's the panacea but that it could solve a wide number of
issues that have been raised till now without introducing many new ones,
thus my comment about the fact that we should consider it. Maybe we'll
find that it's a completely stupid idea but we'll then know why !

Thank you for sharing your analysis and opinion on the subject !

Regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 14 Dec 2010 08:11:42 +1100

Yes; these came up on-list a while back, IIRC.

The important thing is that they'll reject the traffic, not provide an opportunity for the payload to affect routing (as is the case on port 80).

Agreed regarding load balancers as well; AIUI the answer to that concern is that the server deploying them can move them out of the way. Of course, they are sometimes deployed in front of proxies...

But this raises a pertinent question. Do some people here believe that it's a goal for WebSockets to bypass ANY firewall or other restrictions, to the point of actively working against network policies?

Regards,

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 13 Dec 2010 23:42:00 +0100

> Agreed regarding load balancers as well; AIUI the answer to that concern is that the server deploying them can move them out of the way. Of course, they are sometimes deployed in front of proxies...

LBs installed in front of proxies are not a problem, they'll see
CONNECT requests to pass through the proxy anyway.

> But this raises a pertinent question. Do some people here believe that it's a goal for WebSockets to bypass ANY firewall or other restrictions, to the point of actively working against network poli…

No, in my opinion for wide adoption, it should respect existing network
policies and integrate smoothly. That's one advantage of being HTTP
compliant, network policies are mostly applied to HTTP and reusing the
existing components that are already trusted is very appealing and
reassuring for admins.

You never heard about admins being worry about enabling comet or such
mechanisms ? Simply because they did not have anything to do. However,
you very rarely find IRC, NNTP or the like, in part because there is
little control over them.

In my opinion, for admins there are 3 main degrees when judging if
anything new can be deployed :
  - "it will obviously work, it's the same as what we have"
  - "it should work in theory, but we need to test it first"
  - "no way do I want to be responsible if that crap does not work
     as advertised"

The closest we stay to existing standards, the closest we can get
to first degree and get a quick adoption. That means leaving it to
the admins to decide what should pass and what should be blocked.
Reinventing the wheel will bring us closer to the third degree where
admins will be reluctant in deploying the solution or even new unknown
products from unknown vendors.

Just my 2 cents,
Willy