[jira] [Resolved] (PROTON-118) Add support for Messenger API
[ https://issues.apache.org/jira/browse/PROTON-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-118. --- Resolution: Fixed Driver changes committed as http://svn.apache.org/viewvc?rev=1419837view=rev, initial implementation of messenger committed as http://svn.apache.org/viewvc?rev=1420140view=rev. Add support for Messenger API - Key: PROTON-118 URL: https://issues.apache.org/jira/browse/PROTON-118 Project: Qpid Proton Issue Type: New Feature Components: proton-j Affects Versions: 0.1, 0.2 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.3 -- 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
[ https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13528996#comment-13528996 ] Ken Giusti commented on PROTON-136: --- Hi Affan, As far as I can tell my current version of OpenSSL (1.0.0j) does provide serialization/deserialization of the SSL_SESSION object. Whether that can be used to restore SSL sessions across a cold restart would need to be investigated. The other factor is whether or not Java's SSL implementation supports such a feature - assuming we mandate feature parity between the two implementations. I'll have to ask the Java folks to weight in here. 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 Attachments: PROTON-136-initial-Java-and-Python.tgz 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
[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-tabpanelfocusedCommentId=13529126#comment-13529126 ] Philip Harvey commented on PROTON-136: -- There's no easy way of achieving session resumption across process restarts in Java, so this won't be supported in proton-j for now. However, that doesn't rule out proton-c supporting it if it's consdered important enough. Depending on how it's implemented, I don't expect that it would cause the APIs of proton-c and proton-j to diverge. 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 Attachments: PROTON-136-initial-Java-and-Python.tgz 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
[jira] [Resolved] (PROTON-134) pn_connector makes a blocking call to socket::connect
[ https://issues.apache.org/jira/browse/PROTON-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved PROTON-134. - Resolution: Fixed pn_connector makes a blocking call to socket::connect - Key: PROTON-134 URL: https://issues.apache.org/jira/browse/PROTON-134 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.2 Reporter: Ted Ross Assignee: Ted Ross Priority: Blocker Fix For: 0.3 The proton-c driver makes a blocking call to 'connect' when establishing outgoing connections via pn_connector. This breaks the asynchronous nature of the proton driver which should block only on pn_driver_wait. To work properly, pn_connector should return immediately and the connector should then appear in the driver's work list later when the transport connection is either successfully established or it fails for some reason. -- 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-161) SSL impl does not allow verification of the peer's identity
[ https://issues.apache.org/jira/browse/PROTON-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13529256#comment-13529256 ] Ken Giusti commented on PROTON-161: --- Affan, As we used to say: Busted! You're entirely correct: the current patch only checks the CommonName fields. I do need to add support for properly checking the subjectAltName fields as per rfc2818. The problem is I'm having a hard time finding a way of getting at that information in the certificate. The OpenSSL documentation is very sparse on the subject, and the only code examples I can find are internal to OpenSSL or use API calls that won't be supported on older platforms. I'm still looking, but until I can get something that works I'd recommend we go with the CommonName approach at minimum. While it may be deprecated, it plugs a security hole. SSL impl does not allow verification of the peer's identity --- Key: PROTON-161 URL: https://issues.apache.org/jira/browse/PROTON-161 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.3 Reporter: Ken Giusti Assignee: Ken Giusti Priority: Blocker The current SSL implementation validates the peer's certificate, and will not permit the connection to come up if the certificate is invalid. However - it does not provide a way to check if the peer's identity as provided in the certificate is the expected identity (eg, the same hostname used to set up the TCP connection). While a certificate may be valid (that is, signed by a CA trusted by the client), it may not belong to the intended destination. RFC2818 explains how this should be done - see section 3.1 Server Identity. -- 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] [Created] (PROTON-182) [proton-j] SSL tests fail with org.bouncycastle.openssl.PEMException: problem parsing ENCRYPTED PRIVATE KEY: java.security.InvalidKeyException: Illegal key size
Hiram Chirino created PROTON-182: Summary: [proton-j] SSL tests fail with org.bouncycastle.openssl.PEMException: problem parsing ENCRYPTED PRIVATE KEY: java.security.InvalidKeyException: Illegal key size Key: PROTON-182 URL: https://issues.apache.org/jira/browse/PROTON-182 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Reporter: Hiram Chirino Seems ssl keys used in the tests are too strong for the default Java impl. -- 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-182) [proton-j] SSL tests fail with org.bouncycastle.openssl.PEMException: problem parsing ENCRYPTED PRIVATE KEY: java.security.InvalidKeyException: Illegal key size
[ https://issues.apache.org/jira/browse/PROTON-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated PROTON-182: - Attachment: PROTON-182.patch Attaching patch which generates the keys using java so that they are more compatible. [proton-j] SSL tests fail with org.bouncycastle.openssl.PEMException: problem parsing ENCRYPTED PRIVATE KEY: java.security.InvalidKeyException: Illegal key size Key: PROTON-182 URL: https://issues.apache.org/jira/browse/PROTON-182 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Reporter: Hiram Chirino Attachments: PROTON-182.patch Seems ssl keys used in the tests are too strong for the default Java impl. -- 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-182) [proton-j] SSL tests fail with org.bouncycastle.openssl.PEMException: problem parsing ENCRYPTED PRIVATE KEY: java.security.InvalidKeyException: Illegal key size
[ https://issues.apache.org/jira/browse/PROTON-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti updated PROTON-182: -- Attachment: PROTON-182-II.patch Fixed a typo in the script for creating the PEM files. Verified this patch against proton-c. [proton-j] SSL tests fail with org.bouncycastle.openssl.PEMException: problem parsing ENCRYPTED PRIVATE KEY: java.security.InvalidKeyException: Illegal key size Key: PROTON-182 URL: https://issues.apache.org/jira/browse/PROTON-182 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Reporter: Hiram Chirino Attachments: PROTON-182-II.patch, PROTON-182.patch Seems ssl keys used in the tests are too strong for the default Java impl. -- 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-121) Platform specific code is mixed in with platform independent code
[ https://issues.apache.org/jira/browse/PROTON-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13529345#comment-13529345 ] Andrew Stitcher commented on PROTON-121: Another example is the use of strerror_r() which is also not part of ANSI C Platform specific code is mixed in with platform independent code - Key: PROTON-121 URL: https://issues.apache.org/jira/browse/PROTON-121 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Andrew Stitcher the function pn_error_from errno() is platform specific and so should not be in error.c which is (everywhere else) purely platform independent. It should be moved to a platform (POSIX) specific file (perhaps a file with only this single function). [The clue for this is the #define POSIX_C_SOURCE at the top of error.c] -- 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
