[
https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512047#comment-13512047
]
Ken Giusti commented on PROTON-136:
-----------------------------------
Hi Philip,
Thanks for that link - I agree with your explanation: session resumption is
basically automatic under Java. The hostname/port parameters passed in the
SSLEngine's constructor are about the only control we're given, and seem to be
necessary if you want the SSLEngine to have any possibility to resume (may be
wrong there, but the docs seem to suggest that).
One hack would be to have the Java equivalent of pn_ssl_get_state() get the
SSLSession for the SSLEngine, extract the peer host and port, and then return
them in the pn_ssl_state_t object. The problem is on restore: it appears you
can only provide the host/port hint on SSLEngine construction, which means
you'd have to delay or recreate the SSLEngine, depending on your
implementation. Perhaps we're better off changing the API definition a bit to
better suit both implementations. How about we remove pn_ssl_resume_state(),
and instead add an extra parameter to the pn_ssl_new() constructor for the
resume state (NULL if not used)? In other words:
pn_ssl_t *pn_ssl_new( pn_ssl_domain_t *, pn_transport_t *, pn_ssl_state_t *);
Assuming this is where you want to create your underlying SSLEngine, and that
the java variant of pn_ssl_state_t has hostname and port, it could work. And I
think the API change is a bit nicer than what we've currently got.
What do you think?
Other thoughts: perhaps we could get pn_ssl_state_resumed_ok() working under
java this way:
In addition to saving host and port in java's pn_ssl_state_t object, also store
the Id of the session and perhaps the creation time (see SSLSession). After
the new SSLEngine comes up, extract it's SSLSession, and compare's id and
creation time to the Session that was to be resumed? A bit hacky - totally
untested, of course.
What do you think?
> 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:[email protected]]
> 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 <[email protected]> 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
