[
https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505139#comment-13505139
]
Rafael H. Schloming commented on PROTON-136:
--------------------------------------------
I'm not sure I totally understand your scenario. When you say endpoint do you
mean TCP endpoint or AMQP endpoint?
Either way I would hope we could make this scenario work relatively
transparently without requiring direct manipulation of connection level stuff.
Isn't it pretty common that the physical host/ip is different from the
"logical" endpoint you're authentication to in your TLS session? I would assume
that if you're reusing the same TLS session against these two distinct
endpoints they must have some common identity, and we'll need to have access to
that somehow in order to properly validate the TLS session. Wouldn't it be
sufficient to simply key off of that identity either instead of or in addition
to the physical host/ip?
To be clear I'm not totally ruling out opening up a back door to this kind of
stuff if it proves necessary, but given the messenger interface is message
oriented rather than connection oriented, and the messenger internals are free
to create/destroy connections as needed, such a back door would really be more
of an SPI style interface to allow users to customize our implementation, and
I'm hoping that's not needed except in extreme cases.
> 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
