[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-tabpanel&focusedCommentId=13528527#comment-13528527 ] Affan Dar commented on PROTON-161: -- A couple of quick comments: 1) The HTTP/TLS verification uses subjectAltName if present in the cert instead of commonName: http://tools.ietf.org/html/rfc2818#section-3.1 "If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead." In the code I see that we are using the commonName itself. I think it would be better to follow the same logic as HTTPS for this. 2) Is it possible to add an option to disable hostname validation? We could set the pn_ssl_verify_mode_t to PN_SSL_ANONYMOUS_PEER but that would skip even the cert validation I think. Btw if we expect the wildcard support to land soon then this can become a subset of that (*). > 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] [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=13528506#comment-13528506 ] Affan Dar commented on PROTON-136: -- Is it straightforward to allow SSL resume to span process restarts? E.g., for resource constrained devices a process might be killed and then recreated when required. In this case if the app code is able to serialize the ssl resume state to some durable storage then it would be possible to resume an ssl connection from disk theoretically. If there is an API that can hand back a cookie for the app code to serialize and then later pass in then this should be do-able. Of course if openssl does not support a 'cold' resume like this (e.g. if it has other in-memory state) then this request is moot :) > 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 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-160) Allow open.hostname to be configured independently of network hostname
[ https://issues.apache.org/jira/browse/PROTON-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505706#comment-13505706 ] Affan Dar commented on PROTON-160: -- I think the assumption behind option (1) was that adding a connection level setting (such as an alias) may not be appropriate for the level that the messenger API is operating it. Seems like that is not a big issue which is great. Connection aliasing is a good solution and will work for all scenarios (reconnect, redirect etc). It will also make the receive side more symmetric with the send side which is goodness. > Allow open.hostname to be configured independently of network hostname > -- > > Key: PROTON-160 > URL: https://issues.apache.org/jira/browse/PROTON-160 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.1, 0.2 >Reporter: David Ingham > > In a scaled-out, multi-tenant broker environment, the host on which the > container is running is often different from the host to which a client is > establishing the tcp connection. The 'hostname' field in the connection open > performative was added to support this scenario. Currently there's no way to > control this from the Messenger API. > Options include: > (1) (preferred) add a new 'networkhost' field to Message to allow the network > address to be specified. If provided, this information would be used when > establishing the network connection and the data in the 'address' field would > be used in the connection open hostname field. This is somewhat in line with > the way that connection redirect (amqp:connection:redirect) is specified. > (2) extend the syntax of address with query string to supply hostname, e.g., > username:password@tcpaddress:tcpport/entityname?hostname=foo where 'foo' > would become the hostname used in the connection open frame. This is the > approach used by the current Qpid AMQP 1.0 JMS client. -- 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-160) Allow open.hostname to be configured independently of network hostname
[ https://issues.apache.org/jira/browse/PROTON-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13505243#comment-13505243 ] Affan Dar commented on PROTON-160: -- Regarding the messenger resolution process, the following semantic is one possibility and seems to reflect what you are thinking as well: - message.network_host, if specified, is the physical address of the host. I.e. this is the destination end point for the TCP connection. - message.address is the "TLS endpoint" of the host which is used in open.hostname and SASL etc. Furthermore, if message.network_host is not specified then this will also be used as the destination end point for the TCP connection, i.e. the easy default that you mentioned. - Messages with the same message.address can have different values in message.network_host and the connections associated with the respective networkhosts would be used to send these messages. I think PROTON-136 can benefit from this by using the message.address as the key for the session cache. Furthermore, are there plans on adding auto-redirect to the resolution process? I think it raises some other questions. If there is a JIRA tracking that work then I can add some comments to it. > Allow open.hostname to be configured independently of network hostname > -- > > Key: PROTON-160 > URL: https://issues.apache.org/jira/browse/PROTON-160 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.1, 0.2 >Reporter: David Ingham > > In a scaled-out, multi-tenant broker environment, the host on which the > container is running is often different from the host to which a client is > establishing the tcp connection. The 'hostname' field in the connection open > performative was added to support this scenario. Currently there's no way to > control this from the Messenger API. > Options include: > (1) (preferred) add a new 'networkhost' field to Message to allow the network > address to be specified. If provided, this information would be used when > establishing the network connection and the data in the 'address' field would > be used in the connection open hostname field. This is somewhat in line with > the way that connection redirect (amqp:connection:redirect) is specified. > (2) extend the syntax of address with query string to supply hostname, e.g., > username:password@tcpaddress:tcpport/entityname?hostname=foo where 'foo' > would become the hostname used in the connection open frame. This is the > approach used by the current Qpid AMQP 1.0 JMS client. -- 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-tabpanel&focusedCommentId=13504844#comment-13504844 ] Affan Dar commented on PROTON-161: -- I think that works fine. I.e, these three modes for hostname verification should cover most of the cases IMO: none, exact (subjectAltName or commonName must match the destination hostname) or custom (user provides hostname to match, hostname might contain wildcards). > 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] [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=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: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
[jira] [Created] (PROTON-164) Messenger not handling connection errors properly
Affan Dar created PROTON-164:
Summary: Messenger not handling connection errors properly
Key: PROTON-164
URL: https://issues.apache.org/jira/browse/PROTON-164
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.2
Reporter: Affan Dar
Fix For: 0.3
There seems to be an issue with redirects and maybe connection level errors in
general where the client seems to get stuck.
E.g. in the following scenario where the server sends back a CLOSE frame to the
proton client with the ‘redirect’ error. The client should sent back a CLOSE
frame but instead it gets stuck (the send sample app does not proceed and
eventually you have to Ctrl+C it).
Connected to INT7-SN1-008-23257-0-9.servicebus.int7.windows-int.net:5671
-> SASL
[0x25dd720:0] -> SASL-INIT @65 [:PLAIN, b""]
<- SASL
[0x25dd720:0] <- SASL-MECHANISMS @64 [@PN_SYMBOL[:PLAIN, :EXTERNAL]]
[0x25dd720:0] <- SASL-OUTCOME @68 [0, b"Welcome!"]
-> AMQP
[0x25d7e60:0] -> OPEN @16 ["0c753746-89de-4c4c-bd17-fb6d6e36a081",
"INT7-SN1-008-23257-0-9.servicebus.int7.windows-int.net", null, null, null,
null, null, null, null]
[0x25d7e60:1] -> BEGIN @17 [null, 0, 1024, 1024]
[0x25d7e60:1] -> ATTACH @18 ["sender-xxx", 1, false, null, null, @40 ["q1", 0,
null, 0, false, null, null, null, null, null, null], @41 ["q1", 0, null, 0,
false, null, null], null, null, 0]
<- AMQP
[0x25d7e60:0] <- CLOSE @24 [@29 [:"amqp:connection:redirect", "Exception of
type 'Microsoft.ServiceBus.Messaging.Amqp.AmqpException' was
thrown..TrackingId:eb33c8f31c9f4b0c9a2c8aa7c2622ca7_G3,TimeStamp:11/27/2012
6:06:24 AM",
{:hostname="INT7-SN1-008-23257-0-9.servicebus.int7.windows-int.net",
:"network-host"="70.37.116.39", :port=5671}]]
Debugging through the code a little bit, it seems like the client is expecting
to receive more data from the socket and keeps on waiting since the default
timeout is infinite.
Please let me know if more details are required.
--
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-tabpanel&focusedCommentId=13504185#comment-13504185 ] Affan Dar commented on PROTON-161: -- A quick thought/requirement on the user model for the implementation: it would be great if the hostname verification is pluggable so apps can skip it completely if required or do a more lax verification. E.g. accept all certificates with an subjectAltName that has a suffix *.domain.com. I.e., allow this part of the RFC2818, sec 3.1: "If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. (For instance, a client may be connecting to a machine whose address and hostname are dynamic but the client knows the certificate that the server will present.) In such cases, it is important to narrow the scope of acceptable certificates as much as possible in order to prevent man in the middle attacks. In special cases, it may be appropriate for the client to simply ignore the server's identity, but it must be understood that this leaves the connection open to active attack." > 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] [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=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: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
[jira] [Created] (PROTON-144) Reduce byte overhead for small payloads
Affan Dar created PROTON-144:
Summary: Reduce byte overhead for small payloads
Key: PROTON-144
URL: https://issues.apache.org/jira/browse/PROTON-144
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.2, 0.3
Reporter: Affan Dar
Fix For: 0.2
In constrained bandwidth scenarios (e.g. on a cellular data network) any byte
overhead is very costly.
>From the traces for a simple app, we are seeing a large overhead (>100 bytes)
>in the message payload for sending a two byte message. It seems like there are
>some default properties like the to and reply-to addresses that the proton
>client stamps onto a message and also there is padding on the actual two byte
>payload itself.
To be able to successfully embed the proton lib in such resource constrained
devices the byte overhead needs to be trimmed down as much as the protocol
allows.
---
Details of test app
---
The testing environment is OpenSUSE 11.4 64bit, the AMQP library is from SVN
updated usually once a day although commits have slowed since the push for 0.2
and libopenssl version 1.0.0e-34.17.1.
The debugging output is all from proton, to get the debugging output set the
Env variable "PN_TRACE_FRM=1"
The test is done connecting to localhost and sending a message across as simply
as possible:
client:
pn_messenger_t *messenger = pn_messenger("b");
pn_messenger_start(messenger);
pn_message_t *message = pn_message();
pn_message_set_address(message, "amqps://0.0.0.0/a");
char data[2] = {(unsigned char)0xff, (unsigned char)0xff};
pn_message_load_data(message, data, 2);
pn_messenger_put(messenger, message);
pn_messenger_send(messenger);
server code:
pn_messenger_t *messenger = pn_messenger("a");
pn_messenger_start(messenger);
pn_messenger_subscribe(messenger, "amqps://~0.0.0.0");
pn_message_t *message = pn_message();
pn_messenger_recv(messenger, 1);
pn_messenger_get(messenger, message);
size_t size = 2;
char data[2];
pn_message_save_data(message, data, &size);
server output:
Accepted from localhost.localdomain:36331
-> SASL
[0x622180:0] -> SASL-MECHANISMS @64 [@PN_SYMBOL[:ANONYMOUS]]
[0x622180:0] -> SASL-OUTCOME @68 [0]
-> AMQP
[0x61c7c0:0] -> OPEN @16 ["a", null, null, null, null, null, null, null, null]
<- SASL
[0x622180:0] <- SASL-INIT @65 [:ANONYMOUS, b""]
<- AMQP
[0x61c7c0:0] <- OPEN @16 ["b", "0.0.0.0", null, null, null, null, null, null,
null]
[0x61c7c0:1] <- BEGIN @17 [null, 0, 1024, 1024]
[0x61c7c0:1] <- ATTACH @18 ["sender-xxx", 1, false, null, null, @40 ["a", 0,
null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0,
false, null, null], null, null, 0]
[0x61c7c0:1] -> BEGIN @17 [1, 0, 1024, 1024]
[0x61c7c0:1] -> ATTACH @18 ["sender-xxx", 1, true, null, null, @40 ["a", 0,
null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0,
false, null, null], null, null, 0]
[0x61c7c0:1] -> FLOW @19 [0, 1024, 0, 1024, 1, 0, 1, null, false]
[0x61c7c0:1] <- TRANSFER @20 [1, 0, b"\x00\x00\x00\x00\x00\x00\x00\x00", 0,
true, false] (133)
"\x00\x80\x00\x00\x00\x00\x00\x00\x00p\xd0\x00\x00\x00\x10\x00\x00\x00\x05V\x00P\x04@V\x00p\x00\x00\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00s\xd0\x00\x00\x00F\x00\x00\x00\x0d@@\xb1\x00\x00\x00\x11amqps://0.0.0.0/a@\xb1\x00\x00\x00\x08amqp://b@@@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@p\x00\x00\x00\x00@\x00\x80\x00\x00\x00\x00\x00\x00\x00w\xb0\x00\x00\x00\x02\xff\xff"
client output:
Connected to 0.0.0.0:5671
-> SASL
[0x620020:0] -> SASL-INIT @65 [:ANONYMOUS, b""]
<- SASL
[0x620020:0] <- SASL-MECHANISMS @64 [@PN_SYMBOL[:ANONYMOUS]]
[0x620020:0] <- SASL-OUTCOME @68 [0]
<- AMQP
[0x61a840:0] <- OPEN @16 ["a", null, null, null, null, null, null, null, null]
-> AMQP
[0x61a840:0] -> OPEN @16 ["b", "0.0.0.0", null, null, null, null, null, null,
null]
[0x61a840:1] -> BEGIN @17 [null, 0, 1024, 1024]
[0x61a840:1] -> ATTACH @18 ["sender-xxx", 1, false, null, null, @40 ["a", 0,
null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0,
false, null, null], null, null, 0]
[0x61a840:1] <- BEGIN @17 [1, 0, 1024, 1024]
[0x61a840:1] <- ATTACH @18 ["sender-xxx", 1, true, null, null, @40 ["a", 0,
null, 0, false, null, null, null, null, null, null], @41 ["a", 0, null, 0,
false, null, null], null, null, 0]
[0x61a840:1] <- FLOW @19 [0, 1024, 0, 1024, 1, 0, 1, null, false]
[0x61a840:1] -> TRANSFER @20 [1, 0, b"\x00\x00\x00\x00\x00\x00\x00\x00", 0,
true, false] (133)
"\x00\x80\x00\x00\x00\x00\x00\x00\x00p\xd0\x00\x00\x00\x10\x00\x00\x00\x05V\x00P\x04@V\x00p\x00\x00\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00s\xd0\x00\x00\x00F\x00\x00\x00\x0d@@\xb1\x00\x00\x00\x11amqps://0.0.0.0/a@\xb1\x00\x00\x00\x08amqp://b@@@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@p\x00\x00\x00\
[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: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
