[
https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526521#comment-13526521
]
Ken Giusti commented on PROTON-136:
-----------------------------------
Rafi raises a very good point - why should every external app that needs to use
this API be forced to implement its own session caching strategy, esp. when a
perfectly good one exists on the Java side? Makes sense to move this into the
SSL layer (albeit a bit more work would be needed on the c-side, but not too
much).
So, after a brief IM with Rafi and Phil, I'd like to propose the following:
On the proton-c side, instead of the api proposed here:
https://issues.apache.org/jira/browse/PROTON-136?focusedCommentId=13506775&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13506775
we do this:
// new top level object - container for related SSL connections:
//
pn_ssl_domain_t;
pn_ssl_domain_t *pn_ssl_domain( pn_ssl_mode_t );
pn_ssl_domain_free( pn_ssl_domain_t * );
// create a new SSL connection "owned" by the domain:
pn_ssl_t *pn_ssl_new( pn_ssl_domain_t *, pn_transport_t *, const char
*session_key); <------ ***
pn_ssl_free( pn_ssl_t * ) // no change here
// new domain-based configuration api:
//
pn_ssl_domain_set_credentials(....)
pn_ssl_domain_set_trusted_ca_db(....)
int pn_ssl_domain_set_peer_authentication(....)
// and, optionally:
int pn_ssl_resumed_status( pn_ssl_t * )
This gets rid of the whole "get"/"set" model that would be used by the
application. Instead, when creating an SSL session, the app would provide a
key value (see *** above). This key is used by the SSL layer as a hint for
session resume. The key (if supplied) is used by the SSL layer like this:
When creating the new SSL connection object, the SSL layer uses the key as an
index into an internal session cache. If there is no match in the cache,
session restore does not take place: a new SSL session is negotiated. When the
app closes that SSL connection, the negotiated session credentials are then
added to the cache, indexed by the given key. Later, should the app create a
new SSL connection object using the *same key*, the session will be found in
the cache and used to perform session restore.
The actual format of the session_key parameter is unknown to the SSL layer - it
only uses it to find a match. The application is free to use whatever it likes
as a key - for example, "host:port" would be a good candidate. On the Java
side, any object that supports "compare" could be used as a key.
The pn_ssl_resumed_status is optional, but could come in handy for testing and
management. Instead of a bool, it would return an integer status, with:
0 = a new session was negotiated (no restore occurred)
1 = using a restored session
-1 = session resume unknown/not supported
The internal session cache management would be up to the implementation: maybe
limit it to a max # of outstanding LRU sessions, assign lifetime/evict stale
sessions, etc.
Thoughts?
> 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
> Attachments: PROTON-136-initial-Java-and-Python.tgz
>
>
> 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
