How can I extend TLS session timeout?

[Chaitanya Gupta]

I need to support TLS session resumption in my node.js app. I am
creating a TLS server usingrequire('tls').createServer(). By default,
the server has a session ticket lifetime of 300 seconds (as seen with
OpenSSL's s_client).

I need the session timeout to be beyond 300 seconds. How can I do
this? I couldn't find anything in node's API docs that could help.

Thanks,
Chaitanya

[Ben Noordhuis]

Node doesn't let you do that. If you have a convincing use case,
please open an issue and we'll add it.

[Satyam Shekhar]

Hi,

I want to contribute this.

I was thinking of implementing it in one of the following ways -

1.

i) Take sessionTimeout as an option to createServer

ii) Expose a method setTimeout on SecureContext in node_crypto.cc which calls SSL_CTX_set_timeout, and use that to set default session timeout for the context, from the "connection" event callback inside createServer.

2.

i) Expose setSessionTimeout on CryptoStream in tls.js which again calls setSessionTimeout exposed by Connection in node_crypto.cc. This calls SSL_SESSION_set_timeout to set the timeout for that session. Now, the user can call setSessionTimeout on the exposed CleartextStream to set the timeout.

What do you think?

-- satyam

 

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Mark Hahn]

What is the "convincing use case"?

[Fedor Indutny]

Please take a look at this pull request: https://github.com/joyent/node/pull/3661

If it'll get landed into node's core - you'll be able to control session storage manually from js land.

Cheers,

Fedor.

[Chaitanya Gupta]

On Aug 25, 11:38 pm, Mark Hahn <m...@hahnca.com> wrote:
> What is the "convincing use case"?

The objective is to reduce latency. Assume that you have a simple
request-response protocol where the client sends a message "Ping" in
response to which the server sends a response "Pong". If client
doesn't have a prior socket open with the server, how many round-trips
does it take before the user can see the response "Pong"?

For plain TCP sockets, it takes about two round trips:

Client Server

SYN -------->
<-------- SYN-ACK
ACK -------->
Ping -------->
<-------- Pong

For a full TLS handshake, it takes about four round trips:

Client Server

SYN -------->
<-------- SYN-ACK
ACK -------->
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec] -------->
NewSessionTicket
<-------- [ChangeCipherSpec]
Ping -------->
<-------- Pong

For TLS with session resumption, it is three round-trips:

Client Server

SYN -------->
<-------- SYN-ACK
ACK -------->
(SessionTicket extension) -------->
ServerHello
(empty SessionTicket extension)
NewSessionTicket
<-------- [ChangeCipherSpec]
[ChangeCipherSpec] -------->
Ping -------->
<-------- Pong

Now, assume that this ping-pong protocol that you have invented is for
a mobile app. Which means that a lot of your users will be accessing
the app from slow wireless networks like EDGE. From where I live, the
round-trip time (RTT) on an EDGE network to a server in the US varied
between 800-900 ms last morning. This works out to the following
costs just taking into account the RTTs:

Plain TCP: 1.6-1.8s
TLS with handshake: 3.2-3.6s
TLS with resumption: 2.4-2.7s

Nothing beats plain TCP but since we don't want anyone snooping in on
this traffic we have to use TLS. TLS with session resumption is not
great but it is still atleast 800-900 ms faster than TLS with full
handshake. And we haven't even taken into account the bandwidth costs
yet: assuming ~1500 bytes per certificate and a chain of three certs,
on a 70 kbps connection you can add another 0.5 seconds to the cost
for a full TLS handshake (and we have still not looked at
retransmission costs -- 2.5G/3G networks are quite lossy).

Now, the first time a user connects we will have go through the
complete TLS handshake -- we can't avoid it. But subsequently, the
costs reduce greatly. You may ask, instead of trying to reconnect, can
we keep the socket open indefinitely? Sure we can, but if the user is
on an iOS device, the moment he takes the app into background, two
things will happen:

1. Your app gets suspended
2. Your socket can be torn down by the OS at any time

This means that, whenever the user brings your app to the foreground
again, its quite possible that we will need to establish a new socket.
And here we would like to reduce the latency as much as possible.
While the typical user might bring the app into the foreground several
times a day, he would not do so every five minutes.

That is why it would be great if we can extend TLS session timeout.
While the latency costs are not so visible on a fast fixed line
connection, they are very much so on slow wireless networks.

Thanks,
Chaitanya

>
> On Sat, Aug 25, 2012 at 11:18 AM, Satyam Shekhar <satyamshek...@gmail.com>wrote:
>
>
>
>
>
>
>
> > Hi,
>

[Mark Hahn]

I understand your concerns.  I'm just surprised that extending the timeout beyond five minutes would make any difference.  Surely your app can refresh the connection within 5 mins.

[Dan Shaw]

We hope to get Fedor's patch tested under load at Voxer soon.
Unfortunately, we're still probably a couple weeks out from that.

Daniel Shaw
@dshaw

[Chaitanya Gupta]

On Aug 27, 10:06 pm, Mark Hahn <m...@hahnca.com> wrote:
> I understand your concerns.  I'm just surprised that extending the timeout
> beyond five minutes would make any difference.  Surely your app can refresh
> the connection within 5 mins.
>

No, we can't do that. As I mentioned, once the app goes into
background, it is suspended -- there's absolutely nothing it can do.
And there's a good chance that the OS will disconnect the socket.

So typically, when the user brings the app into the foreground, we
have no choice but to establish a new socket -- and this is where
anything that can cut down latency will help.

Chaitanya

[Chaitanya Gupta]

Hi Fedor,

On Aug 25, 11:45 pm, Fedor Indutny <fe...@indutny.com> wrote:
> Please take a look at this pull request:https://github.com/joyent/node/pull/3661
>
> If it'll get landed into node's core - you'll be able to control session
> storage manually from js land.
>

Thanks for pointing me to the patch. Any particular reason you want to
store sessions on the server instead of using RFC 4507 (TLS resumption
without server-side state -- using session tickets)?

Chaitanya

>
>
>
> On Sun, Aug 26, 2012 at 1:38 AM, Mark Hahn <m...@hahnca.com> wrote:
> > What is the "convincing use case"?
>

> > On Sat, Aug 25, 2012 at 11:18 AM, Satyam Shekhar <satyamshek...@gmail.com>wrote:
>
> >> Hi,
>

[Fedor Indutny]

TLS Session tickets should already work with node's embedded openssl library. Though, many clients still use old server-side sessions.

Cheers,

Fedor.