OpenSSL - Session Resumption on an On-going Connection

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenSSL - Session Resumption on an On-going Connection

Filipe Fernandes

I'm developing a specific SSL Server, in which it's supposed to have an always-on socket connection. So, to be on the safe side, there's specific needs that need to be filled on this implementation. One of the needs is that the server must send a resumption request (ServerHello) to the client on a cyclic manner. I've tried everything I could, but it seems that the server does not send the ServerHello to the Client.

My question: How can I make LibOpenSSL-1.0.2g to send a ServerHello to the Client on demand? The socket should not close, nor perform a renegotiation.

Thanks!


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL - Session Resumption on an On-going Connection

OpenSSL - User mailing list

>My question: How can I make LibOpenSSL-1.0.2g to send a ServerHello to the Client on demand? The socket should not close, nor perform a renegotiation.

 

You have to shutdown and restart the TLS layer.  You cannot send arbitrary ServerHello messages, it’s a protocol violation.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL - Session Resumption on an On-going Connection

Viktor Dukhovni
In reply to this post by Filipe Fernandes
On Mon, Nov 19, 2018 at 04:01:35PM +0000, Filipe Fernandes wrote:

> I'm developing a specific SSL Server, in which it's supposed to have an
> always-on socket connection. So, to be on the safe side, there's specific
> needs that need to be filled on this implementation. One of the needs is
> that the server must send a resumption request (ServerHello) to the client
> on a cyclic manner. I've tried everything I could, but it seems that the
> server does not send the ServerHello to the Client.

This is only possible with TLS <= 1.2, TLS 1.3 eliminated renegotiation.

> My question: How can I make LibOpenSSL-1.0.2g to send a ServerHello to the
> Client *on demand*? The socket should not close, nor perform a
> renegotiation.

The relevant code in apps/s_server.c is:

        SSL_renegotiate(con);
        i = SSL_do_handshake(con);

this implements the handling of the 'r' magic character, see s_server(1):

    CONNECTED COMMANDS

       If a connection request is established with an SSL client and neither
       the -www nor the -WWW option has been used then normally any data
       received from the client is displayed and any key presses will be sent
       to the client.

       Certain commands are also recognized which perform special operations.
       These commands are a letter which must appear at the start of a line.
       They are listed below.

       [...]

       r   Renegotiate the SSL session (TLSv1.2 and below only).

       R   Renegotiate the SSL session and request a client certificate
           (TLSv1.2 and below only).

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL - Session Resumption on an On-going Connection

Filipe Fernandes
Hi Viktor,

I've followed your example, and it looks like the server is doing what it's supposed to, however, I'm getting a disconnect from the server when the session expires. Which should not happen, and I can't seem to find a reason for this to be happening.

As previously said, I'm developing a server that handles always-on TLS connections, and I'm trying to perform a session resumption.


Thanks!



On Mon, 19 Nov 2018 at 21:02, Viktor Dukhovni <[hidden email]> wrote:
On Mon, Nov 19, 2018 at 04:01:35PM +0000, Filipe Fernandes wrote:

> I'm developing a specific SSL Server, in which it's supposed to have an
> always-on socket connection. So, to be on the safe side, there's specific
> needs that need to be filled on this implementation. One of the needs is
> that the server must send a resumption request (ServerHello) to the client
> on a cyclic manner. I've tried everything I could, but it seems that the
> server does not send the ServerHello to the Client.

This is only possible with TLS <= 1.2, TLS 1.3 eliminated renegotiation.

> My question: How can I make LibOpenSSL-1.0.2g to send a ServerHello to the
> Client *on demand*? The socket should not close, nor perform a
> renegotiation.

The relevant code in apps/s_server.c is:

        SSL_renegotiate(con);
        i = SSL_do_handshake(con);

this implements the handling of the 'r' magic character, see s_server(1):

    CONNECTED COMMANDS

       If a connection request is established with an SSL client and neither
       the -www nor the -WWW option has been used then normally any data
       received from the client is displayed and any key presses will be sent
       to the client.

       Certain commands are also recognized which perform special operations.
       These commands are a letter which must appear at the start of a line.
       They are listed below.

       [...]

       r   Renegotiate the SSL session (TLSv1.2 and below only).

       R   Renegotiate the SSL session and request a client certificate
           (TLSv1.2 and below only).

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL - Session Resumption on an On-going Connection

Filipe Fernandes
I've misjudged. The socket is closed even if the session has not ended (I've set the session timeout to 10 times the resumption cycle).

You can check the tcpdump here:


I'm doing exactly what is on the s_server example, without avail.

        if (SSL_renegotiate(GetSSL()) <= 0) {
            CSyException Ex("SocketSSL", "SSL_renegotiate() failed. Stopping communication.");
            Ex.PrintError();
            SetShouldClose(TRUE);
            GetSSLConfig()->uiLastTLSRenegotiation = time1sVal;
            return FALSE;
        }

        if (SSL_do_handshake(GetSSL()) <= 0) {
            CSyException Ex("SocketSSL", "SSL_do_handshake() has failed. Stopping communication.");
            Ex.PrintError();
            SetShouldClose(TRUE);
            GetSSLConfig()->uiLastTLSRenegotiation = time1sVal;
            return FALSE;
        }

Thanks!





On Wed, 21 Nov 2018 at 17:45, Filipe Fernandes <[hidden email]> wrote:
Hi Viktor,

I've followed your example, and it looks like the server is doing what it's supposed to, however, I'm getting a disconnect from the server when the session expires. Which should not happen, and I can't seem to find a reason for this to be happening.

As previously said, I'm developing a server that handles always-on TLS connections, and I'm trying to perform a session resumption.


Thanks!



On Mon, 19 Nov 2018 at 21:02, Viktor Dukhovni <[hidden email]> wrote:
On Mon, Nov 19, 2018 at 04:01:35PM +0000, Filipe Fernandes wrote:

> I'm developing a specific SSL Server, in which it's supposed to have an
> always-on socket connection. So, to be on the safe side, there's specific
> needs that need to be filled on this implementation. One of the needs is
> that the server must send a resumption request (ServerHello) to the client
> on a cyclic manner. I've tried everything I could, but it seems that the
> server does not send the ServerHello to the Client.

This is only possible with TLS <= 1.2, TLS 1.3 eliminated renegotiation.

> My question: How can I make LibOpenSSL-1.0.2g to send a ServerHello to the
> Client *on demand*? The socket should not close, nor perform a
> renegotiation.

The relevant code in apps/s_server.c is:

        SSL_renegotiate(con);
        i = SSL_do_handshake(con);

this implements the handling of the 'r' magic character, see s_server(1):

    CONNECTED COMMANDS

       If a connection request is established with an SSL client and neither
       the -www nor the -WWW option has been used then normally any data
       received from the client is displayed and any key presses will be sent
       to the client.

       Certain commands are also recognized which perform special operations.
       These commands are a letter which must appear at the start of a line.
       They are listed below.

       [...]

       r   Renegotiate the SSL session (TLSv1.2 and below only).

       R   Renegotiate the SSL session and request a client certificate
           (TLSv1.2 and below only).

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL - Session Resumption on an On-going Connection

Viktor Dukhovni
In reply to this post by Filipe Fernandes
On Wed, Nov 21, 2018 at 05:45:19PM +0000, Filipe Fernandes wrote:

> I've followed your example, and it looks like the server is doing what it's
> supposed to, however, I'm getting a disconnect from the server when the
> session expires. Which should not happen, and I can't seem to find a reason
> for this to be happening.
>
> As previously said, I'm developing a server that handles always-on TLS
> connections, and I'm trying to perform a session resumption.

I thought you wanted renegotiation, not resumption, servers can't
do "resumption", because resumption is what you do to avoid a full
handshake on a *new* connection, and only the client can reconnect.

You seem to be confused, and have not explained your requirements
clearly.  What is your *goal*?

What does "always on" mean to you?  Only clients can resume previous
sessions, when reconnecting to a server.  Is that what you're trying
to do? (Implement a server with a session cache for client resumption?
Support session tickets? Is there just one server or a server "farm"?
Do the clients support resumption?)

Or are you trying to periodically rekey a long-running connection?

Or something else?

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL - Session Resumption on an On-going Connection

Filipe Fernandes
>   I thought you wanted renegotiation, not resumption, servers can't
>   do "resumption", because resumption is what you do to avoid a full
>   handshake on a *new* connection, and only the client can reconnect.

Ok. Agreed.

>   You seem to be confused, and have not explained your requirements
>   clearly.  What is your *goal*?

My goal is to have the Openssl to "perform the TLS Resumption (initiated by the Hello Request message from the server or
the Client Hello message from the client), in an ongoing TLS Session." (it's specifically stated on the spec, like this).

>   What does "always on" mean to you?  

Always on, means that the socket connection is up for as long as it is possible, meaning that the socket is not closed and it keeps exchanging information all the time (server<->client)

>   Only clients can resume previous
>   sessions, when reconnecting to a server.  Is that what you're trying
>   to do? (Implement a server with a session cache for client resumption?

I'm developing the server side with OpenSSL 1.0.2. And it supports cache (I've activated it on the method SSL_CTX_set_session_cache_mode).   

>   Support session tickets? Is there just one server or a server "farm"?
>   Do the clients support resumption?)

There's only 1 server, not a farm.

How can I tell if the client supports resumption?


>   Or are you trying to periodically rekey a long-running connection?

Maybe this is it. 

For me, Renegotiation is request "everything" (new pubkey, certificates, etc)
Resumption, is just to refresh the keys? I'm a little confused here.

>   
>   Or something else?  

I think this is it :)


On Wed, 21 Nov 2018 at 23:12, Viktor Dukhovni <[hidden email]> wrote:
On Wed, Nov 21, 2018 at 05:45:19PM +0000, Filipe Fernandes wrote:

> I've followed your example, and it looks like the server is doing what it's
> supposed to, however, I'm getting a disconnect from the server when the
> session expires. Which should not happen, and I can't seem to find a reason
> for this to be happening.
>
> As previously said, I'm developing a server that handles always-on TLS
> connections, and I'm trying to perform a session resumption.

I thought you wanted renegotiation, not resumption, servers can't
do "resumption", because resumption is what you do to avoid a full
handshake on a *new* connection, and only the client can reconnect.

You seem to be confused, and have not explained your requirements
clearly.  What is your *goal*?

What does "always on" mean to you?  Only clients can resume previous
sessions, when reconnecting to a server.  Is that what you're trying
to do? (Implement a server with a session cache for client resumption?
Support session tickets? Is there just one server or a server "farm"?
Do the clients support resumption?)

Or are you trying to periodically rekey a long-running connection?

Or something else?

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: OpenSSL - Session Resumption on an On-going Connection

Matt Caswell-2


On 22/11/2018 11:15, Filipe Fernandes wrote:
>>   You seem to be confused, and have not explained your requirements
>>   clearly.  What is your *goal*?
>
> My goal is to have the Openssl to "perform the TLS Resumption (initiated by the
> Hello Request message from the server or
> the Client Hello message from the client), in an ongoing TLS Session." (it's
> specifically stated on the spec, like this).

I think you need to get this spec clarified. It makes no sense. It seems to be
describing renegotiation, but uses the term resumption for it which has a
different meaning.

A handshake occurs between a client and a server at the start of a connection
and establishes the cryptographic parameters to be used for that connection
(including certificates/keys etc). Resumption refers to a type of handshake.
Resumptions handshakes are abbreviated forms of a full handshake. They are based
on the parameters established during a previous connection. So for example a
certificate is not exchanged because the same cert is used from the previous
connection.

Renegotiation refers to the process of starting a new handshake over an existing
TLS connection between a client and a server. Typically the objective is usually
either to update the keys, or to request a client certificate. Like any other
handshake it may be a full one or a resumption one.

Only a client can ever initiate a handshake. A server can *request* a
renegotiation by sending a HelloRequest message, but the client does not have to
honour it. A server cannot request a resumption.


>
>>   What does "always on" mean to you?  
>
> Always on, means that the socket connection is up for as long as it is possible,
> meaning that the socket is not closed and it keeps exchanging information all
> the time (server<->client)

Resumption does not give you this. Renegotiation does.

>
>>   Only clients can resume previous
>>   sessions, when reconnecting to a server.  Is that what you're trying
>>   to do? (Implement a server with a session cache for client resumption?
>
> I'm developing the server side with OpenSSL 1.0.2. And it supports cache (I've
> activated it on the method SSL_CTX_set_session_cache_mode).   
>
>>   Support session tickets? Is there just one server or a server "farm"?
>>   Do the clients support resumption?)
>
> There's only 1 server, not a farm.
>
> How can I tell if the client supports resumption?
>
>
>>   Or are you trying to periodically rekey a long-running connection?
>
> Maybe this is it. 
>
> For me, Renegotiation is request "everything" (new pubkey, certificates, etc)

A renegotiation is a new handshake over an existing connection. It may use a
full handshake (certificates exchanged etc), or an abbreviated resumption
handshake (e.g. doesn't exchange certificates again). Only the client gets to
decide whether to attempt a resumption.


> Resumption, is just to refresh the keys? I'm a little confused here.

No. Resumption is an abbreviated handshake. It may be used at the start of a new
connection or as part of a renegotiation handshake. In either case it is
abbreviated because it is based on the parameters established during an earlier
connection.

Matt


>
>>   
>>   Or something else?  
>
> I think this is it :)
>
>
> On Wed, 21 Nov 2018 at 23:12, Viktor Dukhovni <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On Wed, Nov 21, 2018 at 05:45:19PM +0000, Filipe Fernandes wrote:
>
>     > I've followed your example, and it looks like the server is doing what it's
>     > supposed to, however, I'm getting a disconnect from the server when the
>     > session expires. Which should not happen, and I can't seem to find a reason
>     > for this to be happening.
>     >
>     > As previously said, I'm developing a server that handles always-on TLS
>     > connections, and I'm trying to perform a session resumption.
>
>     I thought you wanted renegotiation, not resumption, servers can't
>     do "resumption", because resumption is what you do to avoid a full
>     handshake on a *new* connection, and only the client can reconnect.
>
>     You seem to be confused, and have not explained your requirements
>     clearly.  What is your *goal*?
>
>     What does "always on" mean to you?  Only clients can resume previous
>     sessions, when reconnecting to a server.  Is that what you're trying
>     to do? (Implement a server with a session cache for client resumption?
>     Support session tickets? Is there just one server or a server "farm"?
>     Do the clients support resumption?)
>
>     Or are you trying to periodically rekey a long-running connection?
>
>     Or something else?
>
>     --
>             Viktor.
>     --
>     openssl-users mailing list
>     To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users