Closed jeffRTC closed 3 years ago
Can you attach the pcap? Sending server hello done before server hello makes no sense
The previous messages (Server Hello, KEX, etc.) of server handshake sequence might be overridden in tls_emit_data
, only the last message (Server Hello Done) being sent. There is no support for coalescing records in Botan yet so you should ensure consecutive calls to tls_emit_data
preserve their original order.
@nametoolong
I think what you described is exactly the issue. I've modified the code and push messages into a vector on tls_emit_data event. It seems it sends Server Hello but nowhere to find Sever Hello Done.
What could be causing that?
The vector only has 1 message when I inspect it which is Server Hello.
@randombit Please see the pcap file.
@randombit Things are different from original issue now. Now it sends Server Hello but never Sever Hello Done.
Is the buffer fully copied into the vector? Only saving the pointer is pointless per the doc. Concatenating multiple messages is fine though.
After this function returns, the buffer containing data will be overwritten, so a copy of the input must be made if the callback cannot send the data immediately.
If you still cannot locate the issue, try counting how many times tls_emit_data
is called. The difference between invocation count and on-wire message count indicates an issue.
@nametoolong
I convert buffer to std::string then emplace back to vector.
encodedMessages.emplace_back(std::string(data, data + size));
The reason I do so is because ZeroMQ Stream Socket type doesn't accept raw buffer so I have to pass a String.
Passing an already-constructed std::string
to emplace_back
kind of defeats the whole point.
I'm unsure why other messages disappear but counting tls_emit_data
invocations might help. Botan 2 always sends one record per invocation. If there is only one call to tls_emit_data
on the server side then it is a Botan bug.
@nametoolong
I did count.
The callbacks get invoked 5 times and the vector only has two messages...
Not sure what you mean by defats whole point. I need to access messages outside of callback so I use emplace back
I am going to try with push back now and see if anything change
It's crazy, even with push_back, the result is same
@nametoolong
Strange....
It appear to be bug within C++ Ranged Loops
int counter = 0;
std::cout << existingConnection->second->tlsCallbacks.encodedMessages.size() << "\n";
// Logs 4
for(const auto &i : existingConnection->second->tlsCallbacks.encodedMessages) {
std::cout << "MESSAGE :" << counter << "\n";
// Logs 1,2 then stop
// Send Response
socket.send(frames[0], zmq::send_flags::sndmore);
socket.send(zmq::buffer(i), zmq::send_flags::sndmore);
counter++;
}
@nametoolong
Posted this one Stackoverflow. They suggested this behavior could happen if callbacks are from another thread or whatever..
They closed the question because they can't reproduce due to not giving them full code...
@nametoolong
I tried with raw loop, same behavior, it doesn't loop over all elements.
Strange ..
This is weird... Not a Botan bug. I have no idea either. :shrug:
What I mean by defeats the whole point is that emplace_back(std::string(data, data + size))
does not emplace. It actually constructs a temporary string first and then copies it into the end of the array. You should doemplace_back(data, data + size)
to emplace directly.
@nametoolong
I tried but nothing has changed. It only loop over two elements
@randombit Do you have any idea either? Is this happen because some sort of threading in your library?
@randombit
Wired but this is what happen when I inspect traffic on Wireshark.
Please see my code,
Socket part,
I know Botan has it own send method but I'm not sure what its. I use Botan's received_data method to pass the data the socket received