On Fri, May 16, 2014 at 1:12 AM, Richard Sharpe <[email protected]> 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 <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
