Re: packet-hislip & tls

[Peter Wu <peter () lekensteyn nl>]

Hi,

On Thu, Jan 30, 2020 at 05:56:27AM +0100, Jaap Keuter wrote:
> Hi Guido,
>
> I’m not sure we have another protocol which supports switching back to
> plain text after going TLS. Therefore I’m not sure if there is
> intrinsic support for it. 
> My first instinct would be to setup a new conversation, starting the
> frame after ‘close notify’, with the HiSLIP dissector assigned to it.
> I’m not sure how that would interact with the existing HiSLIP over TLS
> conversation though, so YMMV.
> Hopefully someone else has a better idea.

The conversation dissector API supports switching over to a new protocol
from a certain frame (this is how the ssl_starttls_ack parameter works),
but it indeed requires creating a new conversation as Jaap suggested.

Alternatives:

 * Implement heuristics that can identify your protocol. Disadvantages:

    - As soon as a port-specific dissector accepts the protocol, yours
      won't be called unless you change the TCP protocol preference to
      try heuristics dissectors first.
    - May not work if your protocol is typically fragmented over
      multiple TCP segments with unclear boundaries.

 * Treat TLS as protocol tunneled by your protocol. When you are sure
   that your connection is using TLS, it could unconditionally call the
   TLS dissector. Then you could still implement the previous heuristics
   to detect the start of the new plaintext session (or the end of the
   TLS stream).

See epan/dissectors/packet-eap.c for an example of the latter. An
excerpt with some annotations:

    // TODO check whether you are still in the TLS phase. Then:
    // Ensures that the encrypted payload is interpreted based on
    // knowledge from your protocol.
    switch (eap_type) {
      case EAP_TYPE_TTLS:
        tls_set_appdata_dissector(tls_handle, pinfo, diameter_avps_handle);
        break;
      case EAP_TYPE_PEAP:
        tls_set_appdata_dissector(tls_handle, pinfo, eap_handle);
        break;
    }

    // Actually dissect the payload as TLS.
    call_dissector(tls_handle, next_tvb, pinfo, eap_tree);

A sample capture for to visualize the above code path can be found at
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15597

Another example of a protocol that is deeply connected with TLS is QUIC.
QUIC provides the record layer that is responsible for fragmenting and
encrypting the payload, but relies on TLS to interpret handshake
messages. In Wireshark this required a dedicated interface (see
tls13-handshake in epan/dissectors/packet-quic.c). I suppose that your
protocol is not that complicated, but it shows that sometimes changes
are needed to accommodate new protocols.

Kind regards,
Peter

> Thanks,
> Jaap
>
> > On 29 Jan 2020, at 23:05, Guido Kiener <Guido.Kiener () rohde-schwarz com> wrote:
> >
> > Hi all,
> >
> > Our working group defines the HiSLIP 2.0 protocol over TLS. I could extend the new messages (e.g. like STARTTLS) 
> > and pass over the encrypted data with ssl_starttls_ack(tls_handle, pinfo, hislip_handle);
> >
> > For performance/debug reason we also have a requirement to switch back the TLS connection (sockets) to plain text 
> > (e.g. when sensitive data is already exchanged). This is done with the ‘close notify’ alerts. I can see the plain 
> > text within the TLS dissector marked as ‘Continuation Data’, but I would like to see the packets again with the 
> > hislip dissector.
> >
> > Question: Can you please give me a hint how I can fall back to the hislip dissector? Is there another dissector 
> > (code) where I can copy the logic?
> >
> > -Guido
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe