Wireshark mailing list archives
Re: Fixing the problem where Wireshark misdissects the SPNEGO negTokenInit
From: Richard Sharpe <realrichardsharpe () gmail com>
Date: Mon, 19 May 2014 08:19:15 -0700
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.
Having thought about this some more, I think I simply need to detect the case where we are seeing a NegTokenInit from the server and treat it as a NegTokenInit2. Can anyone suggest how to do that? -- 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
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)