Wireshark mailing list archives
Re: Fixing the problem where Wireshark misdissects the SPNEGO negTokenInit
From: "Kukosa, Tomas" <tomas.kukosa () unify com>
Date: Thu, 22 May 2014 07:37:23 +0000
Hi Richard, I do not know how to decide (and where) whether it is request or response as I have never seen SPNEGO. But the second half of the problem to switch between NegTokenInit and NegTokenInit2 can be solved in following way: #.FN_BODY NegotiationToken/negTokenInit gboolean is_response = FALSE; /* get this information from somewhere */ if (is_response) { return dissect_spnego_NegTokenInit2(%(IMPLICIT_TAG)s, %(TVB)s, %(OFFSET)s, %(ACTX)s, %(TREE)s, %(HF_INDEX)s); } else { return dissect_spnego_NegTokenInit(%(IMPLICIT_TAG)s, %(TVB)s, %(OFFSET)s, %(ACTX)s, %(TREE)s, %(HF_INDEX)s); } #.END Best regards, Tomas -----Original Message----- From: wireshark-dev-bounces () wireshark org [mailto:wireshark-dev-bounces () wireshark org] On Behalf Of Richard Sharpe Sent: Wednesday, May 21, 2014 16:04 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Fixing the problem where Wireshark misdissects the SPNEGO negTokenInit On Fri, May 16, 2014 at 1:12 AM, Richard Sharpe <realrichardsharpe () gmail com> wrote:
Hi folks, Simo Sorce informed me that there are some other SPNEGO sequences that Wireshark does not deal with. They turned up in some HTTP traffic. So, I decided to look at the issue of fixing the problem I am already aware of (it's in bugzilla somewhere.) This problem is that [MS-SPNG].pdf defines an negTokenInit2: NegHints ::= SEQUENCE { hintName[0] GeneralString OPTIONAL, hintAddress[1] OCTET STRING OPTIONAL } NegTokenInit2 ::= SEQUENCE { mechTypes[0] MechTypeList OPTIONAL, reqFlags [1] ContextFlags OPTIONAL, mechToken [2] OCTET STRING OPTIONAL, negHints [3] NegHints OPTIONAL, mechListMIC [4] OCTET STRING OPTIONAL, ... } and they coyly say: "Note In the ASN.1 description in the preceding, the NegTokenInit2 message occupies the same context-specific ([X690] section 8.1.2.2) message ID (0) as does NegTokenInit in SPNEGO. " They also pointed out that hintAddress is never actually used. Now, these are only emitted by the server in a NegotiateResponse. I notice that the spnego.cnf file says this: #.FN_BODY NegTokenInit/mechListMIC gint8 ber_class; gboolean pc; gint32 tag; tvbuff_t *mechListMIC_tvb; /* * There seems to be two different forms this can take, * one as an octet string, and one as a general string in a * sequence. * * Peek at the header, and then decide which it is we're seeing. */ get_ber_identifier(tvb, offset, &ber_class, &pc, &tag); if (ber_class == BER_CLASS_UNI && pc && tag == BER_UNI_TAG_SEQUENCE) { /* * It's a sequence. */ return dissect_spnego_PrincipalSeq(FALSE, tvb, offset, actx, tree, hf_spnego_mechListMIC); } else { ... } So, the problem is that we have to dissect as if it is a netTokenInit2 if we are in the appropriate context, otherwise as a negTokenInit, and the above stuff is one giant hack. Does anyone have any suggestions on how we can massage the .cnf file to determine this? I also have to get some captures showing these new SPNEGO things before making any changes.
The problems with SPNEGO dissection in HTTP requests and responses seems to be related to mishandling the mechListMIC. Here are the changes I think are needed for the ASN1 defn: diff --git a/asn1/spnego/spnego.asn b/asn1/spnego/spnego.asn index 190b3f1..1f1dcf7 100644 --- a/asn1/spnego/spnego.asn +++ b/asn1/spnego/spnego.asn @@ -24,10 +24,6 @@ MechTypeList ::= SEQUENCE OF MechType -- to some flavor of "embrace, extend, expectorate" sequence from -- Microsoft. -- -PrincipalSeq ::= SEQUENCE { - principal [0] GeneralString -} - NegTokenInit ::= SEQUENCE { mechTypes [0] MechTypeList OPTIONAL, reqFlags [1] ContextFlags OPTIONAL, @@ -35,6 +31,19 @@ NegTokenInit ::= SEQUENCE { mechListMIC [3] OCTET STRING OPTIONAL } +NegHints ::= SEQUENCE { + hintName [0] GeneralString OPTIONAL, + hintAddress [1] OCTET STRING OPTIONAL +} + +NegTokenInit2 ::= SEQUENCE { + mechTypes [0] MechTypeList OPTIONAL, + reqFlags [1] ContextFlags OPTIONAL, + mechToken [2] OCTET STRING OPTIONAL, + negHints [3] NegHints OPTIONAL, + mechListMIC [4] OCTET STRING OPTIONAL +} + ContextFlags ::= BIT STRING { delegFlag (0), mutualFlag (1), ---------------------------------------------------- Then, I think what I have to do is to replace the current #.FN_XXXX NegTokenInit* entries with one simply for NegTokenInit that looks at whether we are dealing with a request or a response, and if a request, uses negTokenInit else uses negTokenInit2. Not sure how to do this at the moment, though. Can anyone provide a hint? -- Regards, Richard Sharpe (何以解憂?唯有杜康。--曹操) ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Fixing the problem where Wireshark misdissects the SPNEGO negTokenInit Richard Sharpe (May 16)
- Re: Fixing the problem where Wireshark misdissects the SPNEGO negTokenInit Richard Sharpe (May 19)
- Re: Fixing the problem where Wireshark misdissects the SPNEGO negTokenInit Richard Sharpe (May 21)
- Re: Fixing the problem where Wireshark misdissects the SPNEGO negTokenInit Kukosa, Tomas (May 22)
- Re: Fixing the problem where Wireshark misdissects the SPNEGO negTokenInit Richard Sharpe (May 26)
- Re: Fixing the problem where Wireshark misdissects the SPNEGO negTokenInit Richard Sharpe (May 26)
- Re: Fixing the problem where Wireshark misdissects the SPNEGO negTokenInit Kukosa, Tomas (May 22)