Subject: [hybi] Websocket and TLS activation after connection setup

From: Francis Brosnan Blazquez <[email-masked]>
Date: Thu, 03 Dec 2009 13:45:05 +0100

Hi,

It seems current WebSocket API do not allows an user to first connect
and then negotiate TLS (SSL) to secure its session. Is there any plan to
include such feature in the API and the websocket protocol?

Cheers!
-- 
Francis Brosnan Blazquez <[email-masked]>
ASPL

---

From: Ian Hickson <[email-masked]>
Date: Fri, 4 Dec 2009 02:08:15 +0000 (UTC)

> include such feature in the API and the websocket protocol?

What is the use case?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 3 Dec 2009 18:32:01 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ian Hickson
> Sent: Thursday, December 03, 2009 6:08 PM
> To: Francis Brosnan Blazquez
> Cc: Hybi
> Subject: Re: [hybi] Websocket and TLS activation after 
> connection setup
> 
> > and then negotiate TLS (SSL) to secure its session. Is 
> > there any plan to include such feature in the API and 
> > the websocket protocol?
> 
> What is the use case?

STARTTLS, as used by IMAP, SMTP, and probably other protocols.

-d

---

From: Ian Hickson <[email-masked]>
Date: Fri, 4 Dec 2009 02:38:04 +0000 (UTC)

On Thu, 3 Dec 2009, Dan Wing wrote:
> > > It seems current WebSocket API do not allows an user to first 
> > > connect and then negotiate TLS (SSL) to secure its session. Is there 
> > > any plan to include such feature in the API and the websocket 
> > > protocol?
> > 
> > What is the use case?
> 

Could you elaborate on that? I don't understand how STARTTLS is a use 
case. I mean, what is the concrete end-user experience that requires this 
feature, and which cannot be done using a straight wss: TLS Web Socket?

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 4 Dec 2009 10:40:49 +0800

> STARTTLS, as used by IMAP, SMTP, and probably other protocols.

I don't believe that answer's Ian's question. That's just a list of other protocols that use the function.  

There was a brief period where it was fashionable in the IETF and it was added to some very useful protocols.  That doesn't mean that negotiating the use of TLS inline is easier or more efficient than directing the client to re-establish with TLS from the start.  I've not seen a use case.

Even in the mature implementations of this that I'm familiar with, such as Java's JNDI implementation of LDAP, StartTLS comes with its own problems.  We use it because that's the standard mechanism for getting to TLS, but I have to say that the TLS-from-the-start option is far more attractive.

--Martin

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 3 Dec 2009 18:58:21 -0800

> From: Ian Hickson [mailto:[email-masked]] 
> Sent: Thursday, December 03, 2009 6:38 PM
> To: Dan Wing
> Cc: 'Francis Brosnan Blazquez'; 'Hybi'
> Subject: RE: [hybi] Websocket and TLS activation after 
> connection setup
> 

Mail user agent connecting to TCP/587, does EHLO, then STARTTLS,
starts TLS, and inside the TLS-encrypted session does AUTH PLAIN
(or AUTH LOGIN) which sends plaintext username and password.

Can't connect to TCP/587 and immediately start TLS, at least
not on the Postfix configuration I'm using at the moment; I 
don't know if it could be configured to expect a TLS handshake
immediately -- is that what you're suggesting?

-d

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Dec 2009 20:00:26 -0700

>> include such feature in the API and the websocket protocol?

Not sharing my application data with Mallory, Justin, Isaac, and all
those other men in the middle. Seems like a pretty compelling use case
to me.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 3 Dec 2009 19:04:35 -0800

> There was a brief period where it was fashionable in the IETF and it was added to some very useful protocols.  That doesn't mean that negotiating the use of TLS inline is easier or more efficient t…

Umm, IIRC, the use case is for name-based selection of server
certificates on a shared host IP (e.g., a cloud).  The normal
TLS handshake assumes there is only one host per IP address,
which substantially increases the cost and complexity of using
TLS for things like secure auth.

....Roy

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Dec 2009 20:18:10 -0700

On 12/3/09 8:04 PM, Roy T. Fielding wrote:
>>>>> connect and then negotiate TLS (SSL) to secure its session.
>>>>> Is there any plan to include such feature in the API and the
>>>>> websocket protocol?
>>>> What is the use case?
>> There was a brief period where it was fashionable in the IETF and
>> it was added to some very useful protocols.  That doesn't mean that
>> negotiating the use of TLS inline is easier or more efficient than
>> directing the client to re-establish with TLS from the start.  I've
>> not seen a use case.
> 
> certificates on a shared host IP (e.g., a cloud).  The normal TLS
> handshake assumes there is only one host per IP address, which
> substantially increases the cost and complexity of using TLS for
> things like secure auth.

Today's Internet Forecast: mostly cloudy.

So, yes, STARTTLS seems like it might be quite useful, especially to
large hosting providers such as the employer of the WebSocket document
editor. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 4 Dec 2009 04:04:23 +0000

> TLS for things like secure auth.

That has already been addressed in TLS, in the form of the Server Name
Indication Extension:

        http://www.ietf.org/rfc/rfc4366.txt
        http://en.wikipedia.org/wiki/Server_Name_Indication

There are some compatibility issues with using it for HTTP and other
established protocols already using SSL/TLS, but when a new protocol
is being specified it could require compatibiliy with SNI.

-- Jamie

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 4 Dec 2009 12:15:14 +0800

Exactly what I would have said ;)

StartTLS only seems useful if you have one of the following:

 a) you need to establish a clear-text connection to exchange some information before upgrading to TLS (the pre-handshake negotiation argument)

 b) you have a good reason to have clear-text and encrypted communications coming to the same port (the port saving argument)

The cost in either case is complexity - you have to negotiate use of TLS in-band, which means control messages and clear cut-over points.

I'm sure that this is a large part of why RFC 2817 is almost entirely unheard of today.  It's just so much easier to start with TLS at port 443.

With the HTTP bootstrap on WS, I see no reason that you can't just start with TLS if it's needed.

--Martin

> From: Jamie Lokier [mailto:[email-masked]]
> Sent: Friday, 4 December 2009 3:04 PM
> To: Roy T. Fielding
> Cc: Thomson, Martin; Hybi
> Subject: Re: [hybi] Websocket and TLS activation after connection setup
> 
> Roy T. Fielding wrote:

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Dec 2009 21:21:09 -0700

> Exactly what I would have said ;)

It's not clear to me exactly how the SNI solves the virtual hosting problem.

> a) you need to establish a clear-text connection to exchange some
> information before upgrading to TLS (the pre-handshake negotiation
> argument)
> 
> b) you have a good reason to have clear-text and encrypted
> communications coming to the same port (the port saving argument)
> 
> The cost in either case is complexity - you have to negotiate use of
> TLS in-band, which means control messages and clear cut-over points.

Aw, it's not *that* hard. Even those of us who work on XMPP (that
horrible technology with absolutely no framing!) could figure it out.

> I'm sure that this is a large part of why RFC 2817 is almost entirely
> unheard of today.  It's just so much easier to start with TLS at port
> 443.

Isn't that just legacy technology? Back in the stone ages, everyone
though you needed a separate port for SSL. Now we're older and wiser.

> start with TLS if it's needed.

Well, I grant you that might be true in this case. Since we're
bootstrapping from HTTP, we can invoke a TLS-encrypted port right from
the start. Although I do wonder if channel binding is going to rear its
ugly head here before too much longer...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 3 Dec 2009 20:22:55 -0800

> is being specified it could require compatibiliy with SNI.

Thanks Jamie -- SNI does address the same issue, though I
mistakenly thought it was still using the upgrade mechanism
instead of a new TLS negotiation extension.  Makes sense.

OTOH, if a client can make a TLS connection to a server,
then why does it need Websocket?

....Roy

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 4 Dec 2009 12:30:28 +0800

> It's not clear to me exactly how the SNI solves the virtual hosting

It solves the problem just like the Host: header did for HTTP.

During the handshake, before the server sends its credentials, the client includes the name of the server that it thinks it's connecting to.  The server uses this to select the appropriate cert, if it needs to.

> horrible technology with absolutely no framing!) could figure it out.

XMPP has framing. It's just really bad framing.  I use XMPP framing as an exemplar proof that you don't have to get everything right if you get most things right.  ;)

Seriously, the complexity bar has been set _really_ low for WS.  Gut instinct says that this is way over that bar.

> though you needed a separate port for SSL. Now we're older and wiser.

Just because we can save on ports, doesn't mean that we should.

> ugly head here before too much longer...

Then we play whack-a-mole, methinks.

--Martin

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Dec 2009 21:42:49 -0700

On 12/3/09 9:30 PM, Thomson, Martin wrote:

> Seriously, the complexity bar has been set _really_ low for WS.  Gut
> instinct says that this is way over that bar.

Oh yeah, I forgot, WebSocket is something that a high-school student
must be able to implement in JavaScript over the course of a single
weekend without missing any parties.

I retract my objection, then. ;-)

/psa

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 4 Dec 2009 13:01:23 +0800

> weekend without missing any parties.

Can we put that in the WG charter? :)

That high-school student makes me feel a little inadequate.  I haven't tried, but I don't think that I'd be able to write a WS implementation between my weekend parties.  It's those late night coding sessions after the drinking.  My code just doesn't seem quite as beautiful the morning after.

---

From: Ian Hickson <[email-masked]>
Date: Fri, 4 Dec 2009 05:30:13 +0000 (UTC)

On Thu, 3 Dec 2009, Dan Wing wrote:
> > > > > connect and then negotiate TLS (SSL) to secure its session. Is 
> > > > > there any plan to include such feature in the API and the 
> > > > > websocket protocol?
> >
> > [...] I mean, what is the concrete end-user experience that requires 
> > this feature, and which cannot be done using a straight wss: TLS Web 
> > Socket?
> 
> Mail user agent connecting to TCP/587, does EHLO, then STARTTLS, starts 
> TLS, and inside the TLS-encrypted session does AUTH PLAIN (or AUTH 
> LOGIN) which sends plaintext username and password.
> 
> Can't connect to TCP/587 and immediately start TLS, at least not on the 
> Postfix configuration I'm using at the moment; I don't know if it could 
> be configured to expect a TLS handshake immediately -- is that what 
> you're suggesting?

I don't understand the relevance of this to WebSocket.

> those other men in the middle. Seems like a pretty compelling use case 

WebSocket supports TLS encryption, you just start with it and then tunnel 
WebSocket over it, instead of starting with WebSocket and then upgrading 
to TLS and then tunneling WebSocket over it.

---

From: Jamie Lokier <[email-masked]>
Date: Fri, 4 Dec 2009 07:03:44 +0000

> then why does it need Websocket?

+1 insightful!

-- Jamie

---

From: Francis Brosnan Blazquez <[email-masked]>
Date: Fri, 04 Dec 2009 11:31:33 +0100

Hi Ian,

> What is the use case?

This is used to provide true virtual hosting for TLS over the same IP
and the same port. 

For example, BEEP uses this to first connect and then start TLS profile,
configuring the desired serverName which is then used at server side to
choose the appropriate certificates...

For example, AFAIK web servers do not allow setting for the same IP
different certificates for different domains because at the time the
HTTP protocol is in place and the Host header can be sent, TLS session
is already activated...

---

From: Francis Brosnan Blazquez <[email-masked]>
Date: Fri, 04 Dec 2009 11:34:18 +0100

Hi,

> I mean, what is the concrete end-user experience that requires this 

More than user experience this will allow server side administrators to
set different certificates according to client connected which is useful
(rather allocating a new IP and telling users to use different IPS for
different services on the same host).
-- 
Francis Brosnan Blazquez <[email-masked]>
ASPL

---

From: Francis Brosnan Blazquez <[email-masked]>
Date: Fri, 04 Dec 2009 12:17:55 +0100

Hi Martin,

As pointed Jamie, SNI is still not practical because its fallback nature
(clients not supporting SNI will hit first virtual hosting defined on
that ssl port) and because, and maybe the most important, currently some
browsers do not include support for this (notably IE).

In the other hand it seems SNI is just a HTTP-fix because it only
provides certificate selection based on host name. 

Protocols that can implement STARTLS feature can select the certificate
based on many conditions like user name authenticated, IP location...

> TLS in-band, which means control messages and clear cut-over points.

These are general terms, however I'm talking about real protocols
already defined (BEEP) that supports this in a simple manner. 

I agree there are more control messages if you would have to start from
the *scratch* but I find this is not the case since many people is
looking at Websocket as a real possibility to implement in an native
manner already existing protocols on top of the web...

---

From: Ian Hickson <[email-masked]>
Date: Fri, 4 Dec 2009 12:09:29 +0000 (UTC)

> HTTP protocol is in place and the Host header can be sent, TLS session 

I think the Server Name Indication TLS extended handshake feature of 
RFC4366 is a much better solution to this particular problem.

> browsers do not include support for this (notably IE).

IE doesn't support WebSocket either.

I've made the WebSocket spec explicitly state that SNI must be supported 
by clients and servers.

> based on many conditions like user name authenticated, IP location...

There's no user name in the WebSocket protocol handshake. Nothing stops 
the server from using the IP location to pick a certificate, with or 
without SNI.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 04 Dec 2009 07:40:23 -0700

> to TLS and then tunneling WebSocket over it.

Right, I was being dense after a 14-hour day. Plus I was thinking about
interdomain federation, when you really might want the ability to
negotiate multiple domain pairs over the same TLS channel. But that's a
separate discussion...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/