Wireshark-dev: Re: [Wireshark-dev] Fixing the problem where Wireshark misdissects the SPNEGO ne
On Fri, May 16, 2014 at 1:12 AM, Richard Sharpe
<realrichardsharpe@xxxxxxxxx> 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
(何以解憂？唯有杜康。--曹操)
