Jakob Uhd Jepsen
changed
bug 8974
Comment # 6
on bug 8974
from Jakob Uhd Jepsen
I found myself recently in need of the ability to see what goes on inside a
FAST exchange, so I wrote up the dissectors and decryption code for FAST and
ENCRYPTED CHALLENGE. It is based off the git master branch (wireshark 1.10). It
is a bit of a work in progress, but complete enough that I figure some feedback
might not be a bad idea.
Things of note: In order to compute the required armor-keys and
encrypted-challenge keys, I've had to introduce a few state flags, the
trns_last_msg* and compute_armorkey stuff. The first to keep track of whether
the FX-FAST being processed contains a request or a reply (since the type does
not reveal this). The second keeps track of when we find sessionkeys inside
FX-FAST, so we may remember them and later use them to make armorkeys.
The armorkey needs both the sessionkey from a ticket, and the subkey from the
immediately following authenticator. All of the computation therefore goes on
in the subkey dissection. I'm unsure about whether this is the best approach,
but it was the only option that seemed intuitive to me. Input and suggestions
very much welcome.
Computing encrypted challenge keys is a bit messy at the moment, since I end up
making a few assumptions about principal naming schemes. I do this in an effort
to limit the number of keys to, hopefully, only those that might be useful
later. The assumptions are: service principals contain a "/" in their name (so
host/[email protected] f.inst). Clients contain no slash, so once I find an @
without a preceeding slash, I shortcircuit the search and make a key.
Finally, I suspect I may be leaking a bit of memory around the whole key-making
that goes on in the subkey dissector, but I've not been able to find a way to
free the keyblocks without introducing read errors and crashing wireshark.
The decryption will need the keys of the client principal and krbtgt service in
a keytab to work.
You are receiving this mail because:
- You are watching all bug changes.