* STUN attributes in general: their type and order.
* DTLS: client ciphersuites (type and order).
* DTLS: client extensions (type and order).
* DTLS: server extensions (type and order).
* DTLS: certificate validity period.
DNS seems like no big deal? Other layers to look at?
Data channels use DTLS while non-data (media, video) use SRTP.
[https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/?include_text=1 WebRTC Data Channels]:"In the WebRTC framework, communication between the parties consists of media (for example audio and video) and non-media data. Media is sent using SRTP, and is not specified further here. Non-media data is handled by using SCTP [RFC4960] encapsulated in DTLS."
[https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/?include_text=1 Web Real-Time Communication (WebRTC): Media Transport and Use of RTP]
== Bro script to fingerprint DTLS
https://github.com/miagilepner/DTLS-fingerprint
== Snowflake Dissections
=== DTLS
The unknown (0x0017) extension is present in all DTLS communication and is concerning. Looks like 0x0017 is [https://tools.ietf.org/html/rfc7627 extended master secret].
{{{
#!html
<pre>
Datagram Transport Layer Security
DTLSv1.0 Record Layer: Handshake Protocol: Client Hello
And then another client hello happened, with a different DTLS version (DTLSv1.2) and different cipher suites and hash algorithms. The APN extension also reveals WebRTC.
{{{
#!html
<pre>
Datagram Transport Layer Security
DTLSv1.0 Record Layer: Handshake Protocol: Client Hello
Second client hello. Weirdly, the first part of the packet says DTLS 1.0, second part says DTLS 1.2. Notice how extensions are different than the Firefox client hello.;
{{{
#!html
<pre>
Datagram Transport Layer Security
DTLSv1.0 Record Layer: Handshake Protocol: Client Hello
