[jira] [Commented] (PROTON-136) Add support for SSL session resumption
[ 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: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 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
Re: Perl language bindings are now pushed...
On Thu, Dec 6, 2012 at 1:35 PM, Andrew Stitcher wrote: > On Thu, 2012-12-06 at 13:24 -0500, Rafael Schloming wrote: > > ... > > > The best way to cater to the developer scenario you mention is to simply > > look at install_manifest.txt. This file is generated whenever you type > make > > install and will provide a much more accurate check on whether the > install > > is behaving as it should, and because this is generated automatically by > > cmake, it will in pretty much any conceivable scheme as long as we don't > > write our own install macro. > > Does it work where "make install" fails? If not it isn't useful in > exactly the cases I care about! > I don't know. (If it doesn't, I'd file a cmake bug.) Either way though I think with what I've suggested you have plenty of good options as a developer, e.g. just override stuff to go where you want it to. True it might be slightly more onerous for you, however at least it's possible. With the current state of things I don't believe it's possible to install properly in the mixed root scenarios I've mentioned, and at a minimum it's way more difficult for our users. --Rafael
Re: Perl language bindings are now pushed...
On Thu, 2012-12-06 at 13:35 -0500, Andrew Stitcher wrote: > On Thu, 2012-12-06 at 13:24 -0500, Rafael Schloming wrote: > > ... > > > The best way to cater to the developer scenario you mention is to simply > > look at install_manifest.txt. This file is generated whenever you type make > > install and will provide a much more accurate check on whether the install > > is behaving as it should, and because this is generated automatically by > > cmake, it will in pretty much any conceivable scheme as long as we don't > > write our own install macro. > > Does it work where "make install" fails? If not it isn't useful in > exactly the cases I care about! To reply to myself: install_manifest.txt is a *result* of a *successful* "make install" so is not useful to the developer case. As that fails in your proposed world stopping the file being created at all. > > Andrew > >
Re: Perl language bindings are now pushed...
On Thu, 2012-12-06 at 13:24 -0500, Rafael Schloming wrote: > ... > The best way to cater to the developer scenario you mention is to simply > look at install_manifest.txt. This file is generated whenever you type make > install and will provide a much more accurate check on whether the install > is behaving as it should, and because this is generated automatically by > cmake, it will in pretty much any conceivable scheme as long as we don't > write our own install macro. Does it work where "make install" fails? If not it isn't useful in exactly the cases I care about! Andrew
Re: Perl language bindings are now pushed...
On Thu, Dec 6, 2012 at 1:05 PM, Andrew Stitcher wrote: > On Wed, 2012-12-05 at 17:51 -0500, Rafael Schloming wrote: > > On Wed, Dec 5, 2012 at 4:38 PM, Darryl L. Pierce > wrote: > > I disagree: > Are you disagreeing with me or Darryl or both? ;-) There are two scenarios that we care about: > > 1. The install prefix of proton is the same as the install prefix of the > perl/php/etc. > > In this case everything just works either way round. No problem with > stripping of the prefix because we just add it back on installation in > any case. Because this is the case I don't understand at all reason why > we wouldn't do this for configuration files as well. > > This is the "user" case that Rafi is concerned about. > No actually, the user case I described is where perl and php have *different* install prefixes, e.g. one is installed in /usr and one is installed in /usr/local. In this case munging with the install prefix of proton is guaranteed to do the wrong thing for at least one of php or perl. 2. The specified install prefix is different from the the installed > prefix of perl/php/etc. > > In this case the reason (for me) of doing "make install" is NOT to try > to run the just produced modules - obviously without some extra work the > language environment won't know where to find the extensions. The > purpose is to get a whole sense of all the artifacts that have been > produced by the build. If they are spread around the file system it > becomes difficult to see at a glance whether something you were > expecting to be there has been left out for instance. > > This case is the "developer" case. > I think you're missing the mixed install root case, of which this is a subset, and I think this is actually the general case, not purely a developer use case. If I have system binaries for perl and php, but had to update ruby to a later build because of some bug fix that hasn't hit the distro yet, then I might well have perl and php in /usr and ruby in /usr/local. As far as I can see allowing the developer case to work has no effect on > whether the "user" case works - since in that case stripping the prefix > is pretty much a null op since it gets added back anyway. > The best way to cater to the developer scenario you mention is to simply look at install_manifest.txt. This file is generated whenever you type make install and will provide a much more accurate check on whether the install is behaving as it should, and because this is generated automatically by cmake, it will in pretty much any conceivable scheme as long as we don't write our own install macro. > I guess this whole discussion hinges on what you think the outcome of a > "make install" is. For a simple "user" I agree it should produce > something that can run and I think that is the case. For a > developer/package builder I'd say that the point is to produce an image > of all the artifacts produced by the build. > I don't think we have a conflict here. The semantics I've described provide users exactly what they want even in the general case mixed install root scenario, and the install_manifest.txt provides us developers exactly what we want (and is also very handy for users who want to be able to uninstall). --Rafael
Re: Perl language bindings are now pushed...
On Wed, 2012-12-05 at 17:51 -0500, Rafael Schloming wrote: > On Wed, Dec 5, 2012 at 4:38 PM, Darryl L. Pierce wrote: I disagree: There are two scenarios that we care about: 1. The install prefix of proton is the same as the install prefix of the perl/php/etc. In this case everything just works either way round. No problem with stripping of the prefix because we just add it back on installation in any case. Because this is the case I don't understand at all reason why we wouldn't do this for configuration files as well. This is the "user" case that Rafi is concerned about. 2. The specified install prefix is different from the the installed prefix of perl/php/etc. In this case the reason (for me) of doing "make install" is NOT to try to run the just produced modules - obviously without some extra work the language environment won't know where to find the extensions. The purpose is to get a whole sense of all the artifacts that have been produced by the build. If they are spread around the file system it becomes difficult to see at a glance whether something you were expecting to be there has been left out for instance. This case is the "developer" case. As far as I can see allowing the developer case to work has no effect on whether the "user" case works - since in that case stripping the prefix is pretty much a null op since it gets added back anyway. I guess this whole discussion hinges on what you think the outcome of a "make install" is. For a simple "user" I agree it should produce something that can run and I think that is the case. For a developer/package builder I'd say that the point is to produce an image of all the artifacts produced by the build. Andrew
[jira] [Commented] (PROTON-136) Add support for SSL session resumption
[ https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511519#comment-13511519 ] 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. See http://docs.oracle.com/javase/6/docs/api/javax/net/ssl/SSLContext.html#createSSLEngine(java.lang.String,%20int) 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 working. > 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 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
