Philip Harvey commented on PROTON-136:

I've started implementing the corresponding Java changes and will commit them 
to the branch when they're in a sane state.

At the moment it's not clear to me what will be in the Java implementation's 
equivalent of the SSL state object.  Java's SSL-related objects are:

* SSLContext, which may be long-lived, and which creates...
** SSLEngine, which is the stateful, short-lived object whose lifetime is that 
of the SSL session.

I believe that Java exposes no detailed SSL session state (eg the master 
secret) that you could use for explicitly resuming an interrupted session.  
Instead, when an SSLEngine is created, the developer hints that it should 
attempt resumption by providing a hostname and port, which presumably are 
internally checked against previously used values.

 if you're interested.

I am currently experimenting with how this works in practice, since the API 
documentation is rather vague.

I don't yet know how the hostname/port should be provided to Proton.  I won't 
worry too much about such niceties until I've got my rough proof-of-concept 

> 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

Reply via email to