[Guido Kiener <Guido.Kiener@xxxxxxxxxxxxxxxxx>]

Hi,

Thanks for your proposals. I will try it and go deeper in the code. When I need more hints and I will ask again.

-Guido


-----Original Message-----
Date: Thu, 30 Jan 2020 11:26:11 +0000
From: Peter Wu 
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Subject: Re: [Wireshark-dev] packet-hislip & tls
Message-ID: <20200130112611.GA1094833@al>
Content-Type: text/plain; charset=utf-8

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
> 
> > 
> > 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