How to handle DTLS Certificate Reassembly Error

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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>


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux