Re: [Wireshark-dev] payload_proto_id in SCPT dissector
On 17/08/19 11:16, Peter Wu wrote: On Fri, Aug 16, 2019 at 10:09:43AM +0100, João Valverde wrote: Using a hash table is an indirect method of passing data. A void pointer function argument is a direct method of passing data. So why would the former present problems with nested TLS traffic and the latter not? Any limitations present in one would be present in the other and vice-versa. What am I missing? In a direct approach, the caller either passes data or it passes NULL. With indirect methods, the caller may pass data, but if it does not, then the setting from previous layers would be applied, unless every caller is audited and modified to clear the data. This is the "unexpected interference" problem I mentioned in the review comments. The indirect approach naturally assumes a dissector won't behave whimsically about argument passing when called multiple times for the same frame (tunneling, etc). ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] payload_proto_id in SCPT dissector
On Fri, Aug 16, 2019 at 10:09:43AM +0100, João Valverde wrote:
>
>
> On 15/08/19 23:48, Peter Wu wrote:
> > The problem was introduced with v3.1.1rc0-144-gede7be3440 ("TLS: allow
> > dissectors to set the appdata protocol via the data param"). Since that
> > commit, the "data" parameter of TCP is interpreted as a string.
> >
> > The problem is that the SCTP dissector can also call the TLS dissector
> > with a non-NULL data parameter:
> >
> > dissector_try_uint_new(sctp_port_dissector_table, high_port,
> > payload_tvb, pinfo, tree, TRUE, GUINT_TO_POINTER(ppi)))
> >
> > This dissector table registration happened in ssl_association_add:
> >
> > dissector_add_uint("sctp.port", port, main_handle);
> >
> > The data parameter is badly overloaded, all I wanted to is to directly
> > pass data from the EAP dissector to the TLS dissector via
> > call_dissector_with_data(tls_handle, ...);
> > Instead we have several things that can go wrong:
> >
> > - sctp.port - sctp dissector passes an integer
> > - tcp.port - TCP passes a "struct tcpinfo" structure
> > - udp.port - UDP passes NULL (ok).
> >
> > So far I only considered the case where the Lua dissector passes NULL, I
> > did not think about the above dissector table cases... Meh.
> >
> > There are at least two ways to fix this:
> >
> > - Add an explicit check to ignore the data parameter when invoked
> > through the TCP or SCTP dissectors. Disadvantage: any other user that
> > adds TLS to their dissector table with non-NULL data will have
> > exactly the same issue.
> > - Apply my initial approach: do not use the data parameter and instead
> > introduce a new function similar to ssl_starttls
> > (tls_set_appdata_dissector). That does not reuse existing dissector
> > APIs however and is indirect which is why I considered the data
> > parameter instead.
> >
> > João's proposed patch to allow sub-dissectors to pass data via a
> > hashtable[1] would have a similar affect to the second option, except
> > that it would require additional code in the TLS dissector to actually
> > look up the data. Such approaches also do not work if you have nested
> > TLS traffic for some reason (maybe a VPN tunnel in TLS?).
>
> I would like to understand your concern with encapsulation/nested traffic
> and [1]. I think the point your are missing, correct me if I'm wrong, is
> that encapsulation already does not work (for your definition of "not
> working") with the void data pointer dissector argument and my patch is
> orthogonal to that issue.
The concern was a situation where the TLS dissector is initially called
with an explicit dissector. Then when HTTPS is within this initial TLS
tunnel, it would still use the old explicit dissector because it has not
been overridden by the new call. This problem will likely exist in any
approach that relies on indirectly passing information (option two or
your patch).
This is a hypothetical case however, I have not run into such a
TLS-over-TLS situation.
> Using a hash table is an indirect method of passing data. A void pointer
> function argument is a direct method of passing data. So why would the
> former present problems with nested TLS traffic and the latter not? Any
> limitations present in one would be present in the other and vice-versa.
> What am I missing?
In a direct approach, the caller either passes data or it passes NULL.
With indirect methods, the caller may pass data, but if it does not,
then the setting from previous layers would be applied, unless every
caller is audited and modified to clear the data. This is the
"unexpected interference" problem I mentioned in the review comments.
Another potential solution is to let the consumer (TLS) clear the data.
That could work with the indirect hashtable approach.
> What I would like to do is implement a consumer pull model of data passing
> between dissectors instead of a producer push model. And one that would be
> Lua friendly too. This seems like a difficult and very time consuming task.
> One that would require breaking all sorts of compatibility, optimizations
> and assumptions I suspect.
>
> >
> > [1]: https://code.wireshark.org/review/34049
> >
> > For now I will consider the first option, but I am open to other
> > suggestions.
The first option with a blocklist approach feels too fragile, I'll just
revert the patch and try an alternative approach.
Kind regards,
Peter
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] payload_proto_id in SCPT dissector
On 15/08/19 23:48, Peter Wu wrote:
The problem was introduced with v3.1.1rc0-144-gede7be3440 ("TLS: allow
dissectors to set the appdata protocol via the data param"). Since that
commit, the "data" parameter of TCP is interpreted as a string.
The problem is that the SCTP dissector can also call the TLS dissector
with a non-NULL data parameter:
dissector_try_uint_new(sctp_port_dissector_table, high_port, payload_tvb,
pinfo, tree, TRUE, GUINT_TO_POINTER(ppi)))
This dissector table registration happened in ssl_association_add:
dissector_add_uint("sctp.port", port, main_handle);
The data parameter is badly overloaded, all I wanted to is to directly
pass data from the EAP dissector to the TLS dissector via
call_dissector_with_data(tls_handle, ...);
Instead we have several things that can go wrong:
- sctp.port - sctp dissector passes an integer
- tcp.port - TCP passes a "struct tcpinfo" structure
- udp.port - UDP passes NULL (ok).
So far I only considered the case where the Lua dissector passes NULL, I
did not think about the above dissector table cases... Meh.
There are at least two ways to fix this:
- Add an explicit check to ignore the data parameter when invoked
through the TCP or SCTP dissectors. Disadvantage: any other user that
adds TLS to their dissector table with non-NULL data will have
exactly the same issue.
- Apply my initial approach: do not use the data parameter and instead
introduce a new function similar to ssl_starttls
(tls_set_appdata_dissector). That does not reuse existing dissector
APIs however and is indirect which is why I considered the data
parameter instead.
João's proposed patch to allow sub-dissectors to pass data via a
hashtable[1] would have a similar affect to the second option, except
that it would require additional code in the TLS dissector to actually
look up the data. Such approaches also do not work if you have nested
TLS traffic for some reason (maybe a VPN tunnel in TLS?).
I would like to understand your concern with encapsulation/nested
traffic and [1]. I think the point your are missing, correct me if I'm
wrong, is that encapsulation already does not work (for your definition
of "not working") with the void data pointer dissector argument and my
patch is orthogonal to that issue.
Using a hash table is an indirect method of passing data. A void pointer
function argument is a direct method of passing data. So why would the
former present problems with nested TLS traffic and the latter not? Any
limitations present in one would be present in the other and vice-versa.
What am I missing?
What I would like to do is implement a consumer pull model of data
passing between dissectors instead of a producer push model. And one
that would be Lua friendly too. This seems like a difficult and very
time consuming task. One that would require breaking all sorts of
compatibility, optimizations and assumptions I suspect.
[1]: https://code.wireshark.org/review/34049
For now I will consider the first option, but I am open to other
suggestions.
Kind regards,
Peter
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] payload_proto_id in SCPT dissector
The problem was introduced with v3.1.1rc0-144-gede7be3440 ("TLS: allow
dissectors to set the appdata protocol via the data param"). Since that
commit, the "data" parameter of TCP is interpreted as a string.
The problem is that the SCTP dissector can also call the TLS dissector
with a non-NULL data parameter:
dissector_try_uint_new(sctp_port_dissector_table, high_port, payload_tvb,
pinfo, tree, TRUE, GUINT_TO_POINTER(ppi)))
This dissector table registration happened in ssl_association_add:
dissector_add_uint("sctp.port", port, main_handle);
The data parameter is badly overloaded, all I wanted to is to directly
pass data from the EAP dissector to the TLS dissector via
call_dissector_with_data(tls_handle, ...);
Instead we have several things that can go wrong:
- sctp.port - sctp dissector passes an integer
- tcp.port - TCP passes a "struct tcpinfo" structure
- udp.port - UDP passes NULL (ok).
So far I only considered the case where the Lua dissector passes NULL, I
did not think about the above dissector table cases... Meh.
There are at least two ways to fix this:
- Add an explicit check to ignore the data parameter when invoked
through the TCP or SCTP dissectors. Disadvantage: any other user that
adds TLS to their dissector table with non-NULL data will have
exactly the same issue.
- Apply my initial approach: do not use the data parameter and instead
introduce a new function similar to ssl_starttls
(tls_set_appdata_dissector). That does not reuse existing dissector
APIs however and is indirect which is why I considered the data
parameter instead.
João's proposed patch to allow sub-dissectors to pass data via a
hashtable[1] would have a similar affect to the second option, except
that it would require additional code in the TLS dissector to actually
look up the data. Such approaches also do not work if you have nested
TLS traffic for some reason (maybe a VPN tunnel in TLS?).
[1]: https://code.wireshark.org/review/34049
For now I will consider the first option, but I am open to other
suggestions.
Kind regards,
Peter
On Thu, Aug 15, 2019 at 12:09:33PM +, Anders Broman wrote:
> Hi,
>
> It is the SCTP PPI which is defined by IANA
>
> Payload protocol identifier: M3UA (3)
>
> { _data_chunk_payload_proto_id, { "Payload protocol
> identifier","sctp.data_payload_proto_id",
> FT_UINT32, BASE_DEC, VALS(sctp_payload_proto_id_values), 0x0,
> NULL, HFILL } },
>
>
>
> You find it in sctpppids.h and
>
> static const value_string sctp_payload_proto_id_values[] = {
>
> { NOT_SPECIFIED_PROTOCOL_ID, "not specified" },
>
> { IUA_PAYLOAD_PROTOCOL_ID,"IUA" },
>
> { M2UA_PAYLOAD_PROTOCOL_ID, "M2UA" },
>
> { M3UA_PAYLOAD_PROTOCOL_ID, "M3UA" },
>
> { SUA_PAYLOAD_PROTOCOL_ID,"SUA" },
>
> { M2PA_PAYLOAD_PROTOCOL_ID, "M2PA" },
>
> { V5UA_PAYLOAD_PROTOCOL_ID, "V5UA" },
>
> { H248_PAYLOAD_PROTOCOL_ID, "H.248/MEGACO" },
>
> { BICC_PAYLOAD_PROTOCOL_ID, "BICC/Q.2150.3" },
>
> { TALI_PAYLOAD_PROTOCOL_ID, "TALI" },
>
> { DUA_PAYLOAD_PROTOCOL_ID,"DUA" },
>
> { ASAP_PAYLOAD_PROTOCOL_ID, "ASAP" },
>
> { ENRP_PAYLOAD_PROTOCOL_ID, "ENRP" },
>
> { H323_PAYLOAD_PROTOCOL_ID, "H.323" },
>
> { QIPC_PAYLOAD_PROTOCOL_ID, "Q.IPC/Q.2150.3" },
>
> { SIMCO_PAYLOAD_PROTOCOL_ID, "SIMCO" },
>
> { DDP_SEG_CHUNK_PROTOCOL_ID, "DDP Segment Chunk" },
>
> { DDP_STREAM_SES_CTRL_PROTOCOL_ID,"DDP Stream Session
> Control" },
>
> { S1AP_PAYLOAD_PROTOCOL_ID, "S1 Application Protocol
> (S1AP)" },
>
> { RUA_PAYLOAD_PROTOCOL_ID,"RUA" },
>
> { HNBAP_PAYLOAD_PROTOCOL_ID, "HNBAP" },
>
> { FORCES_HP_PAYLOAD_PROTOCOL_ID, "ForCES-HP" },
>
> { FORCES_MP_PAYLOAD_PROTOCOL_ID, "ForCES-MP" },
>
> { FORCES_LP_PAYLOAD_PROTOCOL_ID, "ForCES-LP" },
>
> { SBC_AP_PAYLOAD_PROTOCOL_ID, "SBc-AP" },
>
> { NBAP_PAYLOAD_PROTOCOL_ID, "NBAP" },
>
> /* Unassigned 26 */
>
> { X2AP_PAYLOAD_PROTOCOL_ID, "X2AP" },
>
> { IRCP_PAYLOAD_PROTOCOL_ID, "IRCP" },
>
> { LCS_AP_PAYLOAD_PROTOCOL_ID, "LCS-AP" },
>
> { MPICH2_PAYLOAD_PROTOCOL_ID, "MPICH2" },
>
> { SABP_PAYLOAD_PROTOCOL_ID, "SABP" },
>
> { FGP_PAYLOAD_PROTOCOL_ID,"Fractal Generator
> Protocol" },
>
> { PPP_PAYLOAD_PROTOCOL_ID,"Ping Pong
Re: [Wireshark-dev] payload_proto_id in SCPT dissector
Hi,
It is the SCTP PPI which is defined by IANA
Payload protocol identifier: M3UA (3)
{ _data_chunk_payload_proto_id, { "Payload protocol
identifier","sctp.data_payload_proto_id",
FT_UINT32, BASE_DEC, VALS(sctp_payload_proto_id_values), 0x0,
NULL, HFILL } },
You find it in sctpppids.h and
static const value_string sctp_payload_proto_id_values[] = {
{ NOT_SPECIFIED_PROTOCOL_ID, "not specified" },
{ IUA_PAYLOAD_PROTOCOL_ID,"IUA" },
{ M2UA_PAYLOAD_PROTOCOL_ID, "M2UA" },
{ M3UA_PAYLOAD_PROTOCOL_ID, "M3UA" },
{ SUA_PAYLOAD_PROTOCOL_ID,"SUA" },
{ M2PA_PAYLOAD_PROTOCOL_ID, "M2PA" },
{ V5UA_PAYLOAD_PROTOCOL_ID, "V5UA" },
{ H248_PAYLOAD_PROTOCOL_ID, "H.248/MEGACO" },
{ BICC_PAYLOAD_PROTOCOL_ID, "BICC/Q.2150.3" },
{ TALI_PAYLOAD_PROTOCOL_ID, "TALI" },
{ DUA_PAYLOAD_PROTOCOL_ID,"DUA" },
{ ASAP_PAYLOAD_PROTOCOL_ID, "ASAP" },
{ ENRP_PAYLOAD_PROTOCOL_ID, "ENRP" },
{ H323_PAYLOAD_PROTOCOL_ID, "H.323" },
{ QIPC_PAYLOAD_PROTOCOL_ID, "Q.IPC/Q.2150.3" },
{ SIMCO_PAYLOAD_PROTOCOL_ID, "SIMCO" },
{ DDP_SEG_CHUNK_PROTOCOL_ID, "DDP Segment Chunk" },
{ DDP_STREAM_SES_CTRL_PROTOCOL_ID,"DDP Stream Session
Control" },
{ S1AP_PAYLOAD_PROTOCOL_ID, "S1 Application Protocol
(S1AP)" },
{ RUA_PAYLOAD_PROTOCOL_ID,"RUA" },
{ HNBAP_PAYLOAD_PROTOCOL_ID, "HNBAP" },
{ FORCES_HP_PAYLOAD_PROTOCOL_ID, "ForCES-HP" },
{ FORCES_MP_PAYLOAD_PROTOCOL_ID, "ForCES-MP" },
{ FORCES_LP_PAYLOAD_PROTOCOL_ID, "ForCES-LP" },
{ SBC_AP_PAYLOAD_PROTOCOL_ID, "SBc-AP" },
{ NBAP_PAYLOAD_PROTOCOL_ID, "NBAP" },
/* Unassigned 26 */
{ X2AP_PAYLOAD_PROTOCOL_ID, "X2AP" },
{ IRCP_PAYLOAD_PROTOCOL_ID, "IRCP" },
{ LCS_AP_PAYLOAD_PROTOCOL_ID, "LCS-AP" },
{ MPICH2_PAYLOAD_PROTOCOL_ID, "MPICH2" },
{ SABP_PAYLOAD_PROTOCOL_ID, "SABP" },
{ FGP_PAYLOAD_PROTOCOL_ID,"Fractal Generator
Protocol" },
{ PPP_PAYLOAD_PROTOCOL_ID,"Ping Pong Protocol" },
{ CALCAPP_PAYLOAD_PROTOCOL_ID,"CalcApp Protocol" },
{ SSP_PAYLOAD_PROTOCOL_ID,"Scripting Service
Protocol" },
{ NPMP_CTRL_PAYLOAD_PROTOCOL_ID, "NetPerfMeter Control" },
{ NPMP_DATA_PAYLOAD_PROTOCOL_ID, "NetPerfMeter Data" },
{ ECHO_PAYLOAD_PROTOCOL_ID, "Echo" },
{ DISCARD_PAYLOAD_PROTOCOL_ID,"Discard" },
{ DAYTIME_PAYLOAD_PROTOCOL_ID,"Daytime" },
{ CHARGEN_PAYLOAD_PROTOCOL_ID,"Character Generator" },
{ PROTO_3GPP_RNA_PROTOCOL_ID, "3GPP RNA" },
{ PROTO_3GPP_M2AP_PROTOCOL_ID,"3GPP M2AP" },
{ PROTO_3GPP_M3AP_PROTOCOL_ID,"3GPP M3AP" },
{ SSH_PAYLOAD_PROTOCOL_ID,"SSH" },
{ DIAMETER_PROTOCOL_ID, "DIAMETER" },
{ DIAMETER_DTLS_PROTOCOL_ID, "DIAMETER OVER DTLS" },
{ R14P_BER_PROTOCOL_ID, "R14P" },
{ WEBRTC_DCEP_PROTOCOL_ID,"WebRTC Control" },
{ WEBRTC_STRING_PAYLOAD_PROTOCOL_ID, "WebRTC String" },
{ WEBRTC_BINARY_PARTIAL_PAYLOAD_PROTOCOL_ID, "WebRTC Binary Partial
(Deprecated)" },
{ WEBRTC_BINARY_PAYLOAD_PROTOCOL_ID, "WebRTC Binary" },
{ WEBRTC_STRING_PARTIAL_PAYLOAD_PROTOCOL_ID, "WebRTC String Partial
(Deprecated)" },
{ PROTO_3GPP_PUA_PAYLOAD_PROTOCOL_ID, "3GPP PUA" },
{ WEBRTC_STRING_EMPTY_PAYLOAD_PROTOCOL_ID,"WebRTC String Empty" },
{ WEBRTC_BINARY_EMPTY_PAYLOAD_PROTOCOL_ID,"WebRTC Binary Empty" },
{ XWAP_PROTOCOL_ID, "XwAP" },
{ XW_CONTROL_PLANE_PROTOCOL_ID, "Xw - Control Plane" },
{ NGAP_PROTOCOL_ID, "NGAP" },
{ XNAP_PROTOCOL_ID, "XnAP" },
{ F1AP_PROTOCOL_ID, "F1 AP" },
{ ELE2_PROTOCOL_ID, "ELE2 Lawful
Interception" },
{ 0, NULL } };
Regards
Anders
From: Wireshark-dev On Behalf Of Dario
Lombardo
Sent: den 15 augusti 2019 13:55
To: Developer support list for Wireshark
Subject:
