[
https://issues.apache.org/jira/browse/PROTON-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14663247#comment-14663247
]
Andrew Stitcher commented on PROTON-975:
I've looked into this a bit now:
*Good news* The bug won't occur if you are talking to Proton-C at the other end.
*Bad News* it is an interop bug!
Essentially the issue occurs because the qpidd broker has it's own
implementation of the SASL layers and AMQP header reading. Once it has
authorised a connection with SASL it will immediately send the AMQP header,
this triggers the Proton-C bug.
However the Proton-C header reading code is a bit different on the server side:
It will wait for the client to sent the AMQP header before doing anyting
further (this is a consequence of the protocol auto detection - it is possible
that we actually get AMQPTLS at this point not AMQP, although Proton-C won't
currently handle that). This means that encryption is turned on by the time we
next get to do any reads.
crash occurs if buffer containing outcome and first encrypted frame is
received
---
Key: PROTON-975
URL: https://issues.apache.org/jira/browse/PROTON-975
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.10
Reporter: Ken Giusti
Assignee: Andrew Stitcher
Priority: Blocker
Fix For: 0.10
Attachments: send.py
I'm hitting an occasional client crash when using an DIGEST-MD5 SASL mech to
talk to the qpidd broker.
I've built the broker using the 0.10rc1 as the proton library.
I'm using a pyngus based client. I will upload this reproducer.
Best I can tell, the client pushes a single buffer to the transport that
contains both the SASL outcome frame from qpidd and the first encrypted
frame. SASL does not handle this case correctly and attempts to parse the
encrypted frame as cleartext.
I will open another bug against the frame decode to prevent parsing invalid
frames.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
