feat(application): implement TLS/SSL and DTLS record layer + handshake framing

pcapkit.protocols.application.ssl.SSL is the shared record-layer base over
the part TLS and DTLS genuinely share (RFC 9846 §5.1 / RFC 9147 §4):
ContentType/legacy-version/length and content-type dispatch. tls.py and
dtls.py are the two concrete subclasses; DTLS alone carries the epoch +
sequence number in its record header and the message_seq/fragment_offset/
fragment_length header each of its handshake messages adds (RFC 6347
§4.2.2), plus a cookie field in its ClientHello that TLS's does not carry
(RFC 6347 §4.2.1 / RFC 9147 §5.3).

- ClientHello/ServerHello decode to their version, random, session ID,
  cipher suite(s), compression method(s) and extension list (TYPE+LENGTH
  framed, extension bodies undecoded); every other handshake type is
  message-TYPE-level framing only. Alert and ChangeCipherSpec decode in
  full only when cleartext (see below); application_data, heartbeat, ack
  and return_routability_check always stay opaque bytes. tls12_cid (25,
  RFC 9146) is excluded from the wire allowlist entirely and falls back to
  Raw: its record format puts the connection ID before length, at an
  offset only the out-of-band negotiated CID length can resolve, which
  this dissector's stateless, per-packet schema read has no way to track.
- SSL._validate_tls_record rejects a content type outside IANA's assigned
  20-27, a legacy version outside TLS's/DTLS's range, or a declared length
  that runs past the buffer, so dispatch falls back to Raw instead of
  fabricating a record from unrelated bytes. The content-type test is an
  allowlist rather than "did the registry name this value": invalid(0) is
  named -- RFC 9846 §5.1 defines it so a record carrying it can be
  rejected -- and a name-based test accepted `00 03 03 00 04 deadbeef` on
  port 443 as a TLS record.
- handshake, alert and change_cipher_spec records are decoded structurally
  only when cleartext -- the same discipline for all three, generalised in
  SSL._tls_content_is_cleartext. Past the handshake, TLS 1.2's Finished and
  any renegotiation handshake/alert/ChangeCipherSpec travel as ciphertext
  under the same content type, with nothing in the cleartext header to say
  so (an encrypted alert includes the close_notify that ends nearly every
  TLS 1.2 connection); TLS 1.3's post-handshake NewSessionTicket/KeyUpdate
  are not under content type 22 at all, since TLS 1.3's outer record type
  is always application_data once encryption starts. DTLS decodes all
  three only at epoch 0 (the epoch counts cipher changes, RFC 9147 §4.2);
  TLS has no such field, so handshake falls back to whether the 4-octet
  message headers tile the fragment exactly, and alert/change_cipher_spec
  to whether the fragment is exactly 2/1 octets -- an encrypted one can
  never land on either exactly, given MAC/tag overhead. Otherwise the
  octets are kept as-is rather than mis-decoded or dropped to Raw.
- New const registries pcapkit.const.tls.{content_type,handshake_type},
  following the generated-shape convention (EnumRegistry + IntEnum). Both
  name every value IANA assigns, ContentType through RFC 9853's
  return_routability_check(27) and HandshakeType through RFC 9147's
  connection-ID messages (9, 10), RFC 8879's compressed_certificate and
  RFC 8870's ekt_key.
- TCP port 443 (https) and UDP port 5684 (coaps) are bound to TLS/DTLS;
  5684 is not CoAP's only fixed DTLS-borne port, just the one bound here.
- Out of scope, each documented where it bites: reassembling a DTLS
  handshake message fragmented across records (#2440), reassembling a TLS
  record split across TCP segments (decodes as Raw until the record
  arrives whole), and CID-aware offset parsing for tls12_cid records.

Every message shape implemented has a hand-crafted byte fixture proven
byte-exact both ways (parse-then-rebuild and make-then-parse), including a
genuine DTLS ClientHello with a cookie, both encrypted-handshake cases, and
encrypted-alert cases for both protocols (a 26-octet AES-GCM-shaped
close_notify, a 48-octet CBC alert, and a DTLS epoch-1 alert). tls.py and
dtls.py are at 100% statement and branch coverage; ssl.py is at 99%, the
one miss being an unreachable defensive branch. Build/test: mypy reports
nothing on any changed file and isort is clean; pylint shows only the
pre-existing schema-DSL and duplicate-code classes. tests/protocols,
tests/project and tests/const all pass.

Refs #2437

Author: JarryShaw

CHANGELOG.md

@@ -2,6 +2,12 @@
 
 Wave 2 of the roadmap, per the contributing docs' enhancement-proposal page: the protocol pairs that wanted a shared abstract base, and the two that simply had no dissector at all.
 
+### pcapkit.protocols
+
+#### Added
+
+- TLS and DTLS record-layer and handshake-message framing [[RFC 5246](https://datatracker.ietf.org/doc/html/rfc5246), [RFC 9846](https://datatracker.ietf.org/doc/html/rfc9846), [RFC 6347](https://datatracker.ietf.org/doc/html/rfc6347), [RFC 9147](https://datatracker.ietf.org/doc/html/rfc9147)] ([#2437](https://github.com/JarryShaw/PyPCAPKit/issues/2437), [#2441](https://github.com/JarryShaw/PyPCAPKit/pull/2441)). `SSL` is a shared base over the record header and content-type dispatch TLS and DTLS hold in common; `TLS` and `DTLS` are the two concrete subclasses, DTLS alone carrying the epoch/sequence-number pair and the fragment header each handshake message adds. `ClientHello`/`ServerHello` decode to their version, random, session ID, DTLS's `cookie`, cipher suite(s), compression method(s) and extension list (TYPE+LENGTH framed, extension bodies undecoded); every other handshake message is message-TYPE-level framing only. TCP port 443 (`https`) and UDP port 5684 (`coaps`) are bound to TLS and DTLS respectively. Reassembling a handshake message DTLS has fragmented across several records is left to its own follow-up ([#2440](https://github.com/JarryShaw/PyPCAPKit/issues/2440)).
+
 ---
 
 Full changelog: <https://jarryshaw.github.io/PyPCAPKit/changelog.html>

docs/source/changelog/1.6.0.rst

@@ -4,3 +4,25 @@
 Wave 2 of the roadmap, per the contributing docs' enhancement-proposal page: the
 protocol pairs that wanted a shared abstract base, and the two that simply had
 no dissector at all.
+
+pcapkit.protocols
+-----------------
+
+Added
+~~~~~
+
+* TLS and DTLS record-layer and handshake-message framing [:rfc:`5246`,
+  :rfc:`9846`, :rfc:`6347`, :rfc:`9147`] (:issue:`2437`, :pr:`2441`).
+  :class:`~pcapkit.protocols.application.ssl.SSL` is a shared base over the
+  record header and content-type dispatch TLS and DTLS hold in common;
+  :class:`~pcapkit.protocols.application.tls.TLS` and
+  :class:`~pcapkit.protocols.application.dtls.DTLS` are the two concrete
+  subclasses, DTLS alone carrying the epoch/sequence-number pair and the
+  fragment header each handshake message adds. ``ClientHello``/``ServerHello``
+  decode to their version, random, session ID, DTLS's ``cookie``, cipher
+  suite(s), compression method(s) and extension list (TYPE+LENGTH framed,
+  extension bodies undecoded); every other handshake message is
+  message-TYPE-level framing only. TCP port 443 (``https``) and UDP port 5684
+  (``coaps``) are bound to TLS and DTLS respectively. Reassembling a
+  handshake message DTLS has fragmented across several records is left to its
+  own follow-up (:issue:`2440`).

docs/source/contributing/pep.rst

@@ -43,14 +43,19 @@ the ones outstanding are,
 * Link Layer: DSL, EAPOL, FDDI, ISDN, LINUX_SLL, LINUX_SLL2, NDP, PPP
 * Internet Layer: ECN, ICMP, ICMPv6, IGMP, Shim6
 * Transport Layer: DCCP, RSVP
-* Application Layer: BGP, DHCP, DHCPv6, DNS, DTLS, IMAP, LDAP, MQTT, NNTP,
-  NTP, ONC/RPC, POP, QUIC, RIP, RTP, SIP, SMTP, SNMP, SSH, Telnet, TLS/SSL,
+* Application Layer: BGP, DHCP, DHCPv6, DNS, IMAP, LDAP, MQTT, NNTP,
+  NTP, ONC/RPC, POP, QUIC, RIP, RTP, SIP, SMTP, SNMP, SSH, Telnet,
   XMPP
 
 Several of these come in pairs that want a shared abstract base rather than two
 independent implementations, in the way
 :class:`~pcapkit.protocols.internet.ip.IP` already covers its family: ICMP with
-ICMPv6, TLS/SSL with DTLS, and ``LINUX_SLL`` with ``LINUX_SLL2``.
+ICMPv6, and ``LINUX_SLL`` with ``LINUX_SLL2``. **Done** for the third such
+pair, TLS/SSL with DTLS: :class:`~pcapkit.protocols.application.ssl.SSL` is
+the shared record-layer base, with
+:class:`~pcapkit.protocols.application.tls.TLS` and
+:class:`~pcapkit.protocols.application.dtls.DTLS` as its two concrete
+implementations -- see the `DTLS`_ section below.
 :class:`~pcapkit.protocols.link.vlan.VLAN` is the closer precedent for a pair
 whose *layout* is identical -- it holds the whole of the tag, and
 :class:`~pcapkit.protocols.link.c_tag.C_Tag` and
@@ -62,7 +67,7 @@ whose *layout* is identical -- it holds the whole of the tag, and
    ``NotImplemented`` folder. **Those files are not a roadmap.** They are
    scratch reminders, so a stub's presence does not mean a protocol is planned or
    claimed, and its absence does not mean the protocol is unwanted:
-   ``LINUX_SLL``, ``LINUX_SLL2``, ``QUIC`` and **DTLS** have no stub and are on the
+   ``LINUX_SLL``, ``LINUX_SLL2`` and ``QUIC`` have no stub and are on the
    list above,
    while **NGAP** has none either and is implemented. Take this page as the
    record and ignore the folder.
@@ -222,35 +227,43 @@ looks like an ordinary field and is not:
 DTLS
 ~~~~
 
-**Not started**, and it has no stub in the tree -- of the TLS/SSL and DTLS pair,
-only TLS/SSL does. It earns its own entry because the registries
-have moved ahead of it, and a growing part of SCTP's surface names a protocol
-that does not exist:
-
-* the DTLS chunk, type 65 of :class:`~pcapkit.const.sctp.chunk.Chunk`, and the
-  DTLS Key Management chunk parameter, ``0x8006`` of
-  :class:`~pcapkit.const.sctp.parameter.Parameter` -- both fall through to the
-  generic handlers, so they parse as opaque;
-* its error causes, 100 to 103 of
-  :class:`~pcapkit.const.sctp.cause_code.CauseCode`;
-* payload protocol identifiers -- 47 (Diameter over DTLS/SCTP), 66 to 69
-  (NGAP, XnAP, F1AP and E1AP, each over DTLS over SCTP) and 4242 (DTLS chunk
-  key management).
-
-That last group is the one that bites. NGAP over DTLS over SCTP is PPID 66, and
-even with an NGAP dissector registered against it the bytes arriving are a DTLS
-record rather than an NGAP PDU, so they can only degrade to
-:class:`~pcapkit.protocols.misc.raw.Raw`. DTLS therefore blocks NGAP over DTLS,
+**Done** for the record layer and handshake message framing:
+:class:`~pcapkit.protocols.application.tls.TLS` (TLS 1.2, :rfc:`5246`; TLS
+1.3, :rfc:`9846`) and :class:`~pcapkit.protocols.application.dtls.DTLS`
+(DTLS 1.2, :rfc:`6347`; DTLS 1.3, :rfc:`9147`) share
+:class:`~pcapkit.protocols.application.ssl.SSL` as their record-layer base --
+content type, legacy version, length, and content-type dispatch -- with
+DTLS's own divergence (the epoch/sequence-number pair in its record header,
+and the fragment header each handshake message carries) staying in
+:class:`~pcapkit.protocols.application.dtls.DTLS` alone. ``ClientHello`` and
+``ServerHello`` decode down to their cipher suite(s), compression method(s)
+and extension list (TYPE+LENGTH framed, extension bodies undecoded); every
+other handshake message is message-TYPE-level framing only. Decryption is a
+separate question and was never needed to make the record structure legible,
+in the same way :class:`ESP <pcapkit.protocols.internet.esp.ESP>` parses
+without keys.
+
+**Not yet done: reassembling a handshake message DTLS has fragmented across
+several records** (:rfc:`6347#section-4.2.3`). That needs a
+:class:`~pcapkit.foundation.reassembly.reassembly.Reassembly` subclass keyed
+on the UDP 5-tuple plus epoch, which is substantial enough that it was left
+for a follow-up rather than landing alongside the dissector
+(:issue:`2440`). Until then, a fragmented message's body is kept as that one
+fragment's raw octets -- see
+:attr:`DTLSHandshake.is_fragmented <pcapkit.protocols.data.application.dtls.DTLSHandshake.is_fragmented>`
+-- rather than attempted as a decode only a slice of the message could ever
+back correctly. An unfragmented message, the common case, is unaffected.
+
+NGAP over DTLS over SCTP (PPID 66,
+:class:`~pcapkit.const.sctp.payload_protocol_identifier.PayloadProtocolIdentifier`),
 asked for in `discussion #251
-<https://github.com/JarryShaw/PyPCAPKit/discussions/251>`__, independently of
-whether NGAP itself is implemented.
-
-A record-layer dissector is enough to unblock that -- content type, version,
-epoch, sequence number, length, and the fragment offset and length DTLS adds to
-handshake messages. Decryption is a separate question and is not needed to make
-the record structure legible, in the same way :class:`ESP
-<pcapkit.protocols.internet.esp.ESP>` parses without keys. DTLS over UDP is the
-other half of the same work and wants the same dissector.
+<https://github.com/JarryShaw/PyPCAPKit/discussions/251>`__, is **not**
+unblocked by this: :attr:`SCTP.__proto__ <pcapkit.protocols.transport.sctp.SCTP.__proto__>`
+still maps PPID 66 straight to :class:`~pcapkit.protocols.application.ngap.NGAP`
+rather than through :class:`~pcapkit.protocols.application.dtls.DTLS`, so those
+bytes still degrade straight to :class:`~pcapkit.protocols.misc.raw.Raw`. Rewiring
+that dispatch, and deciding what an undecrypted DTLS-wrapped NGAP PDU should
+report, is left to its own follow-up.
 
 Registered, but Not Dissected
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -307,10 +320,15 @@ Some wanted only a table entry, because the dissector was already there:
   *name* rather than a parse -- which is the right answer for a data channel
   carrying an arbitrary file.
 * **Done.** HTTP is additionally bound on 8080 (IANA ``http-alt``, "HTTP
-  Alternate (see port 80)") on both TCP and UDP. **8443 is deliberately left
-  unbound**: IANA registers it as ``pcsync-https``, not as an HTTP alternate,
-  and de-facto 8443 traffic is TLS-wrapped, which pcapkit cannot parse -- see
-  the ``tls`` stub above. Binding it would feed a TLS record to an HTTP parser.
+  Alternate (see port 80)") on both TCP and UDP, and TCP 443 (IANA ``https``)
+  is bound to :class:`~pcapkit.protocols.application.tls.TLS`, now that it
+  parses the record layer de-facto 443 traffic carries; UDP 5684 (IANA
+  ``coaps``) is bound to :class:`~pcapkit.protocols.application.dtls.DTLS`
+  likewise. **8443 is deliberately left unbound**: IANA registers it as
+  ``pcsync-https``, not as an HTTP alternate, and binding it to HTTP would
+  feed a TLS record to an HTTP parser; binding it to TLS instead would be a
+  guess this registry does not make for a service IANA does not actually
+  name there.
 * **Done.** The service VLAN tag identifier (S-Tag), ``0x88A8``, is bound to
   :class:`~pcapkit.protocols.link.s_tag.S_Tag`, and the customer tag ``0x8100``
   to :class:`~pcapkit.protocols.link.c_tag.C_Tag`. Both subclass the abstract
@@ -1078,6 +1096,11 @@ pair alone would answer it twice. ``LINUX_SLL`` matters out of proportion to its
 size: every ``tcpdump -i any`` capture uses it, and neither variant has even a
 stub.
 
+**Done within wave 2 — TLS/SSL with DTLS.** See the `DTLS`_ section above for
+what landed (the shared :class:`~pcapkit.protocols.application.ssl.SSL` base,
+both concrete protocols, and handshake message framing) and what is left
+(DTLS handshake-fragment reassembly, tracked as its own follow-up).
+
 **Done ahead of wave 2 — handlers for the** ``DLT_NULL`` **and** ``DLT_RAW``
 **link types.** Both are genuine DLTs that a capture can legitimately be rooted
 in — ``DLT_NULL`` (0) is BSD's loopback encapsulation, ``DLT_RAW`` (101) an IP

docs/source/pcapkit/protocols/application/dtls.rst

@@ -0,0 +1,83 @@
+DTLS - Datagram Transport Layer Security
+==============================================
+
+.. module:: pcapkit.protocols.application.dtls
+
+:mod:`pcapkit.protocols.application.dtls` contains
+:class:`~pcapkit.protocols.application.dtls.DTLS` only, which implements an
+extractor for Datagram Transport Layer Security (DTLS) [*]_ -- DTLS 1.2
+(:rfc:`6347`) and DTLS 1.3 (:rfc:`9147`) -- at the record layer, plus the
+epoch/sequence-number fields and the handshake-message fragment header that
+set DTLS apart from :class:`~pcapkit.protocols.application.tls.TLS`, whose
+reliable, ordered transport needs neither.
+
+Known Limitation
+-----------------
+
+**A handshake message split across several DTLS records is not reassembled.**
+DTLS fragments a handshake message when it does not fit in one datagram
+(:rfc:`6347#section-4.2.3`); reassembling that would need
+:class:`~pcapkit.foundation.reassembly.reassembly.Reassembly` keyed on the
+UDP 5-tuple plus epoch, which is substantial enough that it did not fit
+cleanly alongside this dissector in the same PR (:issue:`2440`). A fragment's
+:attr:`~pcapkit.protocols.data.application.dtls.DTLSHandshake.is_fragmented`
+says whether this is the case; such a message's
+:attr:`~pcapkit.protocols.data.application.dtls.DTLSHandshake.body` is kept
+as that one fragment's raw octets rather than attempted as a (necessarily
+wrong, since only a slice of it is present) decode. An *unfragmented* message
+-- ``fragment_offset == 0`` and ``fragment_length == length`` -- decodes
+exactly as :class:`~pcapkit.protocols.application.tls.TLS` would, which is
+the common case: a ``ClientHello`` or ``ServerHello`` that fits one datagram
+never fragments.
+
+.. versionadded:: 1.6.0
+
+   :issue:`2437`.
+
+.. raw:: html
+
+   <br />
+
+.. autoclass:: pcapkit.protocols.application.dtls.DTLS
+   :no-members:
+   :show-inheritance:
+
+   .. autoproperty:: name
+   .. autoproperty:: length
+
+   .. automethod:: read
+   .. automethod:: make
+
+   .. automethod:: __length_hint__
+
+   .. automethod:: _make_data
+
+Header Schema
+-------------
+
+.. module:: pcapkit.protocols.schema.application.dtls
+
+.. autoclass:: pcapkit.protocols.schema.application.dtls.DTLS
+   :members:
+   :show-inheritance:
+
+Data Models
+-----------
+
+.. module:: pcapkit.protocols.data.application.dtls
+
+.. autoclass:: pcapkit.protocols.data.application.dtls.DTLS
+   :members:
+   :show-inheritance:
+
+.. autoclass:: pcapkit.protocols.data.application.dtls.DTLSHandshake
+   :members:
+   :show-inheritance:
+
+See :doc:`ssl` for ``ClientHello``, ``ServerHello``, ``Extension``, ``Alert``
+and ``ChangeCipherSpec``, shared verbatim with
+:class:`~pcapkit.protocols.application.tls.TLS`.
+
+.. rubric:: Footnotes
+
+.. [*] https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security

docs/source/pcapkit/protocols/application/index.rst

@@ -22,11 +22,14 @@ function rather than encapsulation, see
    ngap
    ospf
    rarp
+   ssl
+   tls
+   dtls
 
 .. todo::
 
    Implement BGP, DHCP, DHCPv6, DNS, IMAP, LDAP, MQTT, NNTP, NTP, ONC:RPC,
-   POP, RIP, RTP, SIP, SMTP, SNMP, SSH, TELNET, TLS/SSL, XMPP.
+   POP, RIP, RTP, SIP, SMTP, SNMP, SSH, TELNET, XMPP.
 
 Protocol Registry
 -----------------

docs/source/pcapkit/protocols/application/ngap.rst

@@ -91,8 +91,11 @@ Known Limitations
 -----------------
 
 * **PPID 66 payloads are not decoded.** NGAP over DTLS over SCTP wraps the
-  ``NGAP-PDU`` in a DTLS record, and :mod:`pcapkit` implements no DTLS, so the
-  bytes reaching :meth:`NGAP.read` are not an APER encoding. The PPID is
+  ``NGAP-PDU`` in a DTLS record, and :attr:`SCTP.__proto__
+  <pcapkit.protocols.transport.sctp.SCTP.__proto__>` still maps PPID 66
+  straight to :class:`~pcapkit.protocols.application.ngap.NGAP` rather than
+  through :class:`~pcapkit.protocols.application.dtls.DTLS`, so the bytes
+  reaching :meth:`NGAP.read` are not an APER encoding. The PPID is
   registered so that it is *named* rather than anonymous; the payload itself
   degrades to :class:`~pcapkit.protocols.misc.raw.Raw`.
 * **The specification version is that of the installed decoder, not this

docs/source/pcapkit/protocols/application/ssl.rst

@@ -0,0 +1,87 @@
+SSL - Secure Sockets Layer
+===============================
+
+.. module:: pcapkit.protocols.application.ssl
+
+:mod:`pcapkit.protocols.application.ssl` contains
+:class:`~pcapkit.protocols.application.ssl.SSL` only,
+which is a base class for Transport Layer Security (TLS) protocol
+family [*]_, e.g.
+:class:`~pcapkit.protocols.application.tls.TLS` and
+:class:`~pcapkit.protocols.application.dtls.DTLS`.
+
+The record-layer header -- a :class:`~pcapkit.const.tls.content_type.ContentType`,
+a legacy record version, and a length -- is byte-identical in shape between
+TLS (:rfc:`9846#section-5.1`) and DTLS (:rfc:`9147#section-4`); DTLS's own
+divergence (an explicit epoch and sequence number in the record header, and
+handshake-message fragmentation that a reliable TLS stream never needs) stays
+entirely in :class:`~pcapkit.protocols.application.dtls.DTLS`. This base class
+carries the logic the two genuinely share -- content-type dispatch, handshake-
+message decoding, and the record-level validation that keeps dispatch from
+accepting bytes that cannot be a genuine record.
+
+.. versionadded:: 1.6.0
+
+   :issue:`2437`.
+
+.. raw:: html
+
+   <br />
+
+.. autoclass:: pcapkit.protocols.application.ssl.SSL
+   :no-members:
+   :show-inheritance:
+
+   .. automethod:: id
+
+   .. automethod:: _validate_tls_record
+
+   .. automethod:: _tls_content_is_cleartext
+
+   .. automethod:: _read_tls_content
+   .. automethod:: _make_tls_content
+
+   .. automethod:: _read_tls_handshake_messages
+   .. automethod:: _make_tls_handshake_messages
+
+   .. automethod:: _read_tls_client_hello
+   .. automethod:: _make_tls_client_hello
+
+   .. automethod:: _read_tls_server_hello
+   .. automethod:: _make_tls_server_hello
+
+   .. automethod:: _read_tls_extensions
+   .. automethod:: _make_tls_extensions
+
+Data Models
+-----------
+
+.. module:: pcapkit.protocols.data.application.tls
+
+.. autoclass:: pcapkit.protocols.data.application.tls.Handshake
+   :members:
+   :show-inheritance:
+
+.. autoclass:: pcapkit.protocols.data.application.tls.ClientHello
+   :members:
+   :show-inheritance:
+
+.. autoclass:: pcapkit.protocols.data.application.tls.ServerHello
+   :members:
+   :show-inheritance:
+
+.. autoclass:: pcapkit.protocols.data.application.tls.Extension
+   :members:
+   :show-inheritance:
+
+.. autoclass:: pcapkit.protocols.data.application.tls.Alert
+   :members:
+   :show-inheritance:
+
+.. autoclass:: pcapkit.protocols.data.application.tls.ChangeCipherSpec
+   :members:
+   :show-inheritance:
+
+.. rubric:: Footnotes
+
+.. [*] https://en.wikipedia.org/wiki/Transport_Layer_Security