verified that we did have enough data in the buffer/tvb, which could
lead to a SEGV.
(for example if we enable KRB5 decryption but we do NOT use TCP
reassembly, and the encrypted data goes beyong the end of the current
segment)
Change the signature to decrypt_krb5_data() to take a TVB instead of a
buffer+length.
Actually check that we do have the entire encrypted PDU before calling
out to the kerberos libraries.
svn path=/trunk/; revision=29213
(1) Trailing/leading spaces are removed from 'name's/'blurb's
(2) Duplicate 'blurb's are replaced with NULL
(3) Empty ("") 'blurb's are replaced with NULL
(4) BASE_NONE, NULL, 0x0 are used for 'display', 'strings' and 'bitmask' fields
for FT_NONE, FT_BYTES, FT_IPv4, FT_IPv6, FT_ABSOLUTE_TIME, FT_RELATIVE_TIME,
FT_PROTOCOL, FT_STRING and FT_STRINGZ field types
(5) Only allow non-zero value for 'display' if 'bitmask' is non-zero
svn path=/trunk/; revision=28770
add a parameter *datalen to decrypt_krb5_data() so that we can pass back
the length of the decrypted blob back to the caller.
This is useful for when there are "junk" at the end of the blob and thus
the decrypted data is not the same size as the encrypted blob.
GSS CFX is one such example.
(we should have done this earlier since it might have made some other
stuff easier to imlement...)
make the preference setting krb_decrypt a globally visible variable so
we can see its value and act on it from callers of krb decryption from
outside of packet-kerberos.c i.e. from GSS CFX
Make keytype == -1 a wildcard that when passed to decrypt_krb5_data()
will try any/all encryption keys.
This since GSS CFX does not provide the enctype in the GSS layer.
(The GSS CFX enctype is only negotiated during the AP-REQ/REP so we
should later pick this value up and store it in a CFX session variable.
That is for a later enhancement.
)
Enhance the GSS decryption (that for hitorical reasons are implemented
in packet-spnego.c and not packet-gssapi.c :-) )
to also handle decryption of GSS CFX
This should make wireshark able to decrypt any/all GSSAPI RFC4121
packets, if the keytab file is provided.
I have successfully decrypted LDAP using GSS CFX with AES encryption
with this.
svn path=/trunk/; revision=26350
dissect_ber_boolean() to return a value and update asn2wrs to generate the new signature.
Regenerate all BER dissectors.
svn path=/trunk/; revision=24015
- support of extension in middle of SEQUENCE root elements
- new option EMBEDDED_PDV_CB to set default callback
- ChoiceValue support at syntax level
- ValueSet support at syntax level
- exception identifier support
- ValueFromObject support at syntax level
- next minor changes (to compile X.880 and INAP)
- dissectors using classes regenerated
svn path=/trunk/; revision=22036
This is purely empirical as I can find no standard that says it should be there.
However successful LDAP/SASL/GSSAPI between AD and Java client shows it seems to be present.
If the confounder is not dissected, the LDAPMessage to fail to be decoded.
svn path=/trunk/; revision=20833
and associate it with the conversation properly.
do the same for supportedMech in the negTokenTarg
This will allow wireshark to decode the blob in negTokenTarg even when no supportedMech is provided.
svn path=/trunk/; revision=20129
putative octet string isn't one; always check before using it to
dissect, and don't call the dissector if the tvbuff is null. This
should fix bug 472.
svn path=/trunk/; revision=15946
we use to determine how to interpret the token; don't bother fetching
the OID attached to the frame or conversation, as we're not using it.
Indent code in the .cnf file to match the code generated by asn2eth.
The mechListMIC in a NegTokenInit is sometimes a sequence containing a
string; check the header of the mechListMIC and dissect it as such a
sequence or as a regular item depending on whether it's a sequence or
not.
If we see a supportedMech in a NegTokenTarg, save next_level_value for
that OID with the conversation.
Dissect a responseToken in a NegTokenTarg, and a mechListMIC in a
NegTokenTarg, appropriately.
Get rid of "gssapi_dissector_handle()", and just use
next_level_value->handle - it was never being called if next_level_value
was null.
When we're dissecting a KRB5 blob, just use get_ber_identifier() to get
the header, so we don't report an ASN.1 error if there isn't a BER
identifier there; dissect the identifier and length only if we know we
have them.
svn path=/trunk/; revision=15937
Kovarththanan Rajaratnam