You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by "Affan Dar (JIRA)" <ji...@apache.org> on 2012/11/14 20:42:12 UTC
[jira] [Created] (PROTON-136) Add support for SSL session
resumption
Affan Dar created PROTON-136:
--------------------------------
Summary: 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
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:rschloming@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 <af...@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
[jira] [Commented] (PROTON-136) Add support for SSL session
resumption
Posted by "Philip Harvey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509870#comment-13509870 ]
Philip Harvey commented on PROTON-136:
--------------------------------------
Hi Ken,
I'm keen to explore what corresponding Java changes will need to be made. To allow me to do this, is it possible you could commit your work so far to a branch? That would give us a chance to get the tests passing against both proton-c and proton-j before merging to trunk.
How does that sound to you?
> 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:rschloming@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 <af...@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
[jira] [Commented] (PROTON-136) Add support for SSL session
resumption
Posted by "Rafael H. Schloming (JIRA)" <ji...@apache.org>.
[ 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:rschloming@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 <af...@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
[jira] [Commented] (PROTON-136) Add support for SSL session
resumption
Posted by "Affan Dar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504838#comment-13504838 ]
Affan Dar commented on PROTON-136:
----------------------------------
Here is a scenario that might not work if the notion of ssl context is not exposed in the messenger API:
+ Client attempts to send a message to endpoint ep1 and as a result the SSL negotiation happens but at the end the server redirects it to endpoing ep2
+ Client now needs to resend the same message to ep2 but wants to reuse the session id from above since
If the session cache in the messenger api is keyed off of the endpoint name then this won't work. Also the knowledge that the session for ep1 should be reused for ep2 is very app specific.
This is very handy in cases when i) the session cache is shared between a server farm OR ii) the server is redirecting to itself (e.g. to bypass a load balancer).
> 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:rschloming@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 <af...@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
[jira] [Commented] (PROTON-136) Add support for SSL session
resumption
Posted by "Philip Harvey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510620#comment-13510620 ]
Philip Harvey commented on PROTON-136:
--------------------------------------
Thanks Ken, I was planning to look at this today but got delayed by some proton-c / Swig / Python problems. Will take a look tomorrow.
> 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:rschloming@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 <af...@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
[jira] [Commented] (PROTON-136) Add support for SSL session
resumption
Posted by "Rafael H. Schloming (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504682#comment-13504682 ]
Rafael H. Schloming commented on PROTON-136:
--------------------------------------------
Ken: A couple comments on the API proposal.
I think given the fact that we have pn_session_t and pn_link_t elsewhere in the API, the pn_ssl_session_t and pn_ssl_link_t names are somewhat unfortunate. ;-) I'd also suggest that we can probably do what you're suggesting while preserving compatibility with the current API if we split the other way, i.e. introduce a new object for the top level and keep pn_ssl_t as the per transport thing. For example we could introduce pn_ssl_config_t that can encapsulate all the credential config stuff that you can currently do directly on pn_ssl_t. We could then provide the option to configure a pn_ssl_t by supplying a pn_ssl_config_t wholesale. We could then deprecate and later remove the credential related stuff on pn_ssl_t also, or just leave it as convenience API if we wish.
Affan: To answer your question, my intention would be to use this in messenger, but probably not expose it directly as messenger doesn't provide users direct control over or access to connections.
> 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:rschloming@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 <af...@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
[jira] [Commented] (PROTON-136) Add support for SSL session
resumption
Posted by "Rafael H. Schloming (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506780#comment-13506780 ]
Rafael H. Schloming commented on PROTON-136:
--------------------------------------------
Looks good to me, it would be good if the Java guys could comment on whether this will fit with proton-j.
> 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:rschloming@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 <af...@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
[jira] [Commented] (PROTON-136) Add support for SSL session
resumption
Posted by "Ken Giusti (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501538#comment-13501538 ]
Ken Giusti commented on PROTON-136:
-----------------------------------
I've thought a bit about how this can be supported via the existing SSL implementation. I think we'll have to modify the existing SSL API a bit. Here are my notes, comments welcome:
Use model, Client side:
After SSL handshake completes, the server saves the master key that resulted from the
handshake in a session context, and sends an identifier for this session to the client.
The application retrieves this session identifier from the client, and saves it. At some
later point, the client's connection is closed. After the client connection has terminated, the
application may want to reconnect to the same server. The application configures a new
client connection, and sets the session identifier that was extracted from the previous
session. The application then initiates the connection to the server. The server
recognizes the session identifier, and restores the master key from the previous session.
This avoids some of the overhead of a full handshake.
Use model, server side:
No use model - totally transparent to the application.
Implementation notes:
Current implementation has pn_ssl_t handle scoped to the lifetime of its corresponding
connection. When the transport is destroyed, the pn_ssl_t context is also destroyed.
This is an blocking issue for the server side implementation of this feature. In order
for session resume to work, the server side SSL context must be scoped across multiple
connections. This allows old sessions to be used with new connections. Also - I believe,
correct me if I am wrong - but the sessions may only be restored for flows using the same
credentials (e.g. certificates). The current implementation allows (may not be used, but
still allows) each connection to be configured with its own, unique credentials. This calls
for redundant configuration work in the case of a server.
Proposal: split the existing pn_ssl_t object into two objects: pn_ssl_t and pn_ssl_link_t.
The pn_ssl_t object becomes the "top level" object that holds the credential
configuration, and is a container for pn_ssl_link_t objects. The pn_ssl_link_t
corresponds to a single SSL connection, and is associated with the transport.
This would call for modifying the current public SSL api:
// constructors/destructors - note that the pn_ssl_t is now configured to server or client at
// construction:
pn_ssl_t *pn_ssl( pn_ssl_mode_t );
void pn_ssl_free(pn_ssl_t *)
pn_ssl_link_t pn_ssl_link( pn_ssl_t *, pn_transport_t *)
void pn_ssl_link_free( pn_ssl_link_t * )
// keep all the credential configuration-related APIs to operate on the top level pn_ssl_t
// object.
int pn_ssl_set_credentials( pn_ssl_t *ssl,
const char *certificate_file,
const char *private_key_file,
const char *password);
int pn_ssl_set_trusted_ca_db(pn_ssl_t *ssl,
const char *certificate_db);
// move the per-connection management stuff to the pn_ssl_link_t object where it makes
// sense
int pn_ssl_link_allow_unsecured_client(pn_ssl_link_t *ssl);
int pn_ssl_link_set_peer_authentication(pn_ssl_t *ssl,
const pn_ssl_verify_mode_t mode,
const char *trusted_CAs);
In order to support session resume, define an opaque type to represent an SSL session:
pn_ssl_session_t
And add methods to get/set/free the new SSL session abstraction:
pn_ssl_session_t *pn_ssl_link_session( pn_ssl_link_t *);
int pn_ssl_link_resume_session( pn_ssl_link_t *, pn_ssl_session_t * );
void pn_ssl_session_free( pn_ssl_session_t * );
bool pn_ssl_link_resumed( pn_ssl_link_t * )
Notes:
-) The pn_ssl_session_t object is opaque.
-) It exists on return from pn_ssl_link_session(), and remains available until explicitly
released by calling pn_ssl_session_free().
-) sessions can only be resumed on pn_ssl_link_t's that have the SAME parent pn_ssl_t
instance.
-) pn_ssl_link_resumed() is a diagnostic - it returns TRUE if the link resumption was
successful, false if the session was not resumed (a new session was negotiated
instead)
Opinions?
> 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:rschloming@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 <af...@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
[jira] [Commented] (PROTON-136) Add support for SSL session
resumption
Posted by "Ken Giusti (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506775#comment-13506775 ]
Ken Giusti commented on PROTON-136:
-----------------------------------
Rafi,
Re: the api naming - yes, I totally agree that "link" and "session" are bad choices for this new api. And now that you mention it - yes, we certainly can preserve the 'old' api and just extend the api model a bit to support a top level "container" for SSL connections (and thus, SSL sessions).
Not 100% sure I like the "config" name - there may be other non-config-y things we could do with the top level object, like query it for state or statistics, which really isn't "config" like. And I don't want to use 'context', which is perfect but conflicts with the existing conventions for user-supplied context.
How about "domain"?
In any case, let's leave the existing API in place, and extend it as follows:
// 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 *)
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(....)
// new object to represent the state of a single SSL connection
//
pn_ssl_state_t;
pn_ssl_state_t *pn_ssl_get_state( pn_ssl_t *);
int pn_ssl_resume_state( pn_ssl_t *, pn_ssl_state_t * );
void pn_ssl_state_free( pn_ssl_state_t * );
bool pn_ssl_state_resumed_ok( pn_ssl_t * )
better?
> 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:rschloming@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 <af...@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
[jira] [Commented] (PROTON-136) Add support for SSL session
resumption
Posted by "Affan Dar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502557#comment-13502557 ]
Affan Dar commented on PROTON-136:
----------------------------------
The client side user model looks good to me and furthermore I think if/when support for RFC 5077 is added then the same user model will continue to work which is great.
Is this going to be available for messenger API consumers as well?
> 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:rschloming@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 <af...@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
[jira] [Commented] (PROTON-136) Add support for SSL session
resumption
Posted by "Ken Giusti (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509922#comment-13509922 ]
Ken Giusti commented on PROTON-136:
-----------------------------------
Philip - that's a fine idea. I've just pushed up to this branch:
origin/kgiusti-proton-136
You'll also be interested in the reviewboard posting:
https://reviews.apache.org/r/8331/
This is a good resource for discussing the proposed API. I'd certainly be interested in anything you can add from the Java point of view.
As things currently stand in the branch:
As you're probably aware, I haven't gotten the Java unit tests working with these changes.
I still need to document the new API in the header file.
I'm cutting over the tests in ssl.py to use the new interfaces. I've add new SSLDomain and SSLState objects to the proton.py wrappers for use by these tests.
> 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:rschloming@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 <af...@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
[jira] [Updated] (PROTON-136) Add support for SSL session
resumption
Posted by "Rafael H. Schloming (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rafael H. Schloming updated PROTON-136:
---------------------------------------
Assignee: Ken Giusti
> 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:rschloming@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 <af...@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