[
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:rschlom...@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 <affan...@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
