- // The first byte of an rpcapd request is the version
- // number; the first byte of a TLS handshake message
- // is 22. We permanently reserve an rpcapd version
- // number of 22, so that we can distinguish between
- // rpcapd messages and TLS handshake messages; if we
- // ever get to rpcapd version 21, and want to introduce
- // a new version after that, we'll jump to version 23.
- //
- // If this is a TLS handshake message, the second
- // octet is the SSL/TLS (legacy) major version number.
- // For SSL, that's a number <= 3, as the last SSL
- // version was 3.x; TLS continues those version
- // numbers, but, as of TLS 1.3, it's a "legacy" version
- // field, which must have a major version of 3.
- //
- // If this is a non-TLS rpcapd message, the second octet
- // is the message type; only error, "find all interfaces",
- // and open messages have types <= 3, and the first
- // message we receive should be an authentication request,
- // with a type of 8.
- //
- // So if the first octet is 22 and the second octet is <= 3,
- // we assume it's a TLS handshake message, otherwise we
- // assume it's an rpcapd message. (That way, if some
- // client decides to request protocol version 22, we can
- // tell them we don't support it - we never will support
- // that version, for the reasons described above.)