[openssl-users] How to handle DTLS Certificate Reassembly Error
Chad Phillips
chad at apartmentlines.com
Sat Sep 17 15:11:02 UTC 2016
Matt, thanks for the reply, very helpful so far! Answers to your questions
below:
You don't say what version of OpenSSL.
>
The support library I’m using is Licode:
http://lynckia.com/licode/index.html
The version of openssl I have compiled into it is 1.0.2h.
> The packet trace you sent is quite confusing, as there appears to be
> two separate handshakes going on at the same time that are interleaved.
>
Yes, apologies for that, I’ll do a better job of filtering the next time.
:) Those were two separate handshakes pulled from a packet capture of a
group video chat, filtered through Wireshark using the ‘dtls’ filter.
> It seems quite clear that this is a retransmit of the earlier message
> from client to server. Retransmits are a normal part of DTLS and are
> there to handle packet loss. If a retransmitted packet is received by
> one of the peers, and it has seen that packet before, then it is simply
> ignored. Wireshark isn't ignoring it, and is reporting it as an "error"
> simply because it has seen it before.
>
Thanks for that clarification.
> Was this packet capture done on the client side or the server side or
> somewhere in the middle? There appears to be some messages missing.
> In particular I don’t see any CCS or Finished messages being exchanged.
> Is the network this is over potentially noisy that might explain packet
> loss?
>
>From the perspective of the DTLS handshake, my server hosting the Licode
library is the client, and latest stable Chrome browser is the server, if I
understand the terminology correctly. The packet capture was taken from the
client (Licode) side.
Would the CCS or Finished messages have gotten filtered out by the ’dtls’
filter I applied to the packet capture? I do have the full trace and can
re-filter to just one complete connection over a specific UDP port as you
suggested, let me know if that would be helpful
I see these failures only in situations where browser users with slow
and/or lossy internet are joining, and usually when the group size gets to
be six or more participants. The particular testing scenario that generated
the packets you saw was a user with 225kbps upload, 5120kbps down, 70ms
delay, 0% packet loss.
I’ll grant you those network conditions aren’t the best for group video
chat, but if Google Hangouts can pull it off, I’d like to as well.
> On receiving that the client should respond with a retransmit of
> the Certificate/ClientKeyExchange/CertificateVerify/CCS/Finished
> flight of messages. But it does not appear to do so…the retransmit does
> not happen until after the encrypted alert.
>
This sounds like it might be a bug in the Licode library, not resending the
retransmit properly?
> Are both ends of the communication using OpenSSL and if so what versions?
>
>From my research, I believe Chrome uses borringssl?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160917/a14da7e1/attachment.html>
More information about the openssl-users
mailing list