[jira] [Commented] (PROTON-136) Add support for SSL session resumption

["Ken Giusti (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501538#comment-13501538 ] 

Ken Giusti commented on PROTON-136:
-----------------------------------

I've thought a bit about how this can be supported via the existing SSL implementation.  I think we'll have to modify the existing SSL API a bit.  Here are my notes, comments welcome:

Use model, Client side:

After SSL handshake completes, the server saves the master key that resulted from the
handshake in a session context, and sends an identifier for this session to the client.
The application retrieves this session identifier from the client, and saves it.  At some
later point, the client's connection is closed.  After the client connection has terminated, the
application may want to reconnect to the same server.  The application configures a new
client connection, and sets the session identifier that was extracted from the previous
session.  The application then initiates the connection to the server.  The server
recognizes the session identifier, and restores the master key from the previous session.
This avoids some of the overhead of a full handshake.

Use model, server side:

No use model - totally transparent to the application.

Implementation notes:

Current implementation has pn_ssl_t handle scoped to the lifetime of its corresponding
connection.  When the transport is destroyed, the pn_ssl_t context is also destroyed.
This is an blocking issue for the server side implementation of this feature.  In order
for session resume to work, the server side SSL context must be scoped across multiple
connections.  This allows old sessions to be used with new connections.  Also - I believe,
correct me if I am wrong - but the sessions may only be restored for flows using the same
credentials (e.g. certificates).  The current implementation allows (may not be used, but
still allows) each connection to be configured with its own, unique credentials.  This calls 
for redundant configuration work in the case of a server.

Proposal: split the existing pn_ssl_t object into two objects: pn_ssl_t and pn_ssl_link_t.
The pn_ssl_t object becomes the "top level" object that holds the credential
configuration, and is a container for pn_ssl_link_t objects.  The pn_ssl_link_t
corresponds to a single SSL connection, and is associated with the transport.

This would call for modifying the current public SSL api:

// constructors/destructors - note that the pn_ssl_t is now configured to server or client at
// construction:

   pn_ssl_t *pn_ssl( pn_ssl_mode_t );
   void pn_ssl_free(pn_ssl_t *)

   pn_ssl_link_t pn_ssl_link( pn_ssl_t *, pn_transport_t *)
   void pn_ssl_link_free( pn_ssl_link_t * )

// keep all the credential configuration-related APIs to operate on the top level pn_ssl_t
// object.

int pn_ssl_set_credentials( pn_ssl_t *ssl,
                            const char *certificate_file,
                            const char *private_key_file,
                            const char *password);
int pn_ssl_set_trusted_ca_db(pn_ssl_t *ssl,
                             const char *certificate_db);

// move the per-connection management stuff to the pn_ssl_link_t object where it makes
// sense

int pn_ssl_link_allow_unsecured_client(pn_ssl_link_t *ssl);

int pn_ssl_link_set_peer_authentication(pn_ssl_t *ssl,
                                       const pn_ssl_verify_mode_t mode,
                                       const char *trusted_CAs);

In order to support session resume, define an opaque type to represent an SSL session:

   pn_ssl_session_t

And add methods to get/set/free the new SSL session abstraction:

   pn_ssl_session_t *pn_ssl_link_session( pn_ssl_link_t *);
   int pn_ssl_link_resume_session( pn_ssl_link_t *, pn_ssl_session_t * );
   void pn_ssl_session_free( pn_ssl_session_t * );
   bool pn_ssl_link_resumed( pn_ssl_link_t * )

Notes:
 -) The pn_ssl_session_t object is opaque.
 -) It exists on return from pn_ssl_link_session(), and remains available until explicitly
    released by calling pn_ssl_session_free().
 -) sessions can only be resumed on pn_ssl_link_t's that have the SAME parent pn_ssl_t
    instance.
 -) pn_ssl_link_resumed() is a diagnostic - it returns TRUE if the link resumption was
    successful, false if the session was not resumed (a new session was negotiated
    instead)

Opinions?
                
> Add support for SSL session resumption
> --------------------------------------
>
>                 Key: PROTON-136
>                 URL: https://issues.apache.org/jira/browse/PROTON-136
>             Project: Qpid Proton
>          Issue Type: New Feature
>          Components: proton-c
>    Affects Versions: 0.3
>            Reporter: Affan Dar
>            Assignee: Ken Giusti
>              Labels: ssl, sslContext, sslresume
>
> Open SSL supports resumption of SSL sessions which by-pass the heavy SSL handshake process. This is critical for scenarios involving low powered devices especially on cellular data networks where bandwidth is precious.
> It would be great if Proton exposes this ssl resume feature to users. .
> From: rhs [mailto:rschloming@gmail.com] 
> Sent: Tuesday, November 13, 2012 11:34 AM
> To: Affan Dar
> Cc: David Ingham
> Subject: Re: SSL session resumption
> On Tue, Nov 13, 2012 at 8:05 PM, Affan Dar <af...@microsoft.com> wrote:
> >>Serializing/restoring the whole session state for the messenger will work for the scenario I think.
> Ok, let's start with this step then. I'm open to providing something finer grained if there is a need, but my preference is to keep it simple for the moment.
>    
> >>One more thing, RFC 5077 has another flavor of session resumption which openssl supports (original >>implemented as RFC 4057 back in 2007 I think). This allows us to resume sessions without carrying state >>on the server side which as you can imagine is a big deal for service vendors. Probably there is no API >>level impact if messenger handles the session state itself but just wanted to put this on your radar.
> Ok, good to know.
> Could one of you file a JIRA for this upstream? I'm trying to get things a little more organized on the process front and keep everything centralized in JIRA. ;-)
> --Rafael

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira