[
https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13534937#comment-13534937
]
Philip Harvey commented on PROTON-136:
--------------------------------------
It's not clear to me whether I need to make corresponding changes to the Java
Transport and Ssl interfaces.
I had been assuming that Transport.ssl(..) would be called only once on a given
Transport instance, therefore the ambiguity Ken mentioned wouldn't arise. I
had therefore intended to JavaDoc this expectation in Transport.java and leave
the implementation code unchanged.
It's surprisingly hard to swap in alternative Java Ssl instances on a Transport
instance because, for example, they cache both encrypted/cleartext data that
the input/output methods have not yet fully accepted, respectively. I can't
see an easy way for a new Ssl object to reliably inherit this in-flight data,
particularly if the encryption key of the new Ssl session is different to the
old one.
If this is a vital use case that needs to be supported now, then there *may* be
a way for us to implement it. But, if not, then I'd prefer to leave the Java
code functionally unchanged, in which case my only doubt is how
Transport.ssl(..) should behave when called twice with different SslDomains.
I'd actually like to throw an IllegalStateException in this case.
> 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: Philip Harvey
> Labels: ssl, sslContext, sslresume
> Attachments: PROTON-136-initial-Java-and-Python.tgz,
> ssl-patches-20121212.tar.gz
>
>
> 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
