that can be called by dissectoirs using kerberos keytab files.
This function will load a new keytab file on demand, if it is changed in
the preferences.
The previous code had you save the preferences and then restart
wireshark which is suboptimal from a user friendly perspective
svn path=/trunk/; revision=30384
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
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
there are many reasons why some protocols actually need to be able to access the pinfo structure while determining the pdu size
svn path=/trunk/; revision=19751
structure. Handle that.
Don't muck with the columns, or put a top-level Kerberos protocol item
into the protocol tree, until we decide that we really have a Kerberos
packet.
Do, however, clear the Info column if we're dissecting the Kerberos
protocol.
svn path=/trunk/; revision=15590
pointers either "void *" or "guint8 *", to reduce the level of compiler
warnings (the data in question is largely binary in those cases).
svn path=/trunk/; revision=14886
decrypt and behold the new password in plaintext in all its glory
(given you have the keytab with the old one of course)
svn path=/trunk/; revision=13586
Also move ncp222.py, x11-fields, process-x11-fields.pl,
make-reg-dotc, and make-reg-dotc.py.
Adjust #include lines in files that include packet-*.h
files.
svn path=/trunk/; revision=11410
Balint Reczey