>I also seem to remember that the security code which manages
>the connections had code available for encrypting every byte
>in the connection, but in the RT days that code wasn't turned
>on. It could be that over time since the code wasn't used
>much, its falled into disrepair, and may have even been reaped,
>but it was considered in the past.
The code has not been reaped. With the (short) patch that MIT
submitted to Transarc in the mentioned defect report, I have
encryption enabled on several of my workstations, and it does appear
that everything's being encrypted. At least, I could make sense of the
tcpdump'd output of my AFS data before and identify textual data, but
now it's complete gobbledygook, and appears to be all the rx data,
including things like the fid in requests.
>I'm assuming that such a client would have to be physically
>secure, and that it would have to flush its cache frequently
>to purge any traces of the (decrypted) files on the local
>machine... at the very least when the user loses tokens.
It's true that transport-level encryption support (whether
application-level, as the patch, or network level, as Mr. Blackburn is
supporting) isn't the end of the story, but it's an important step. As
always, keeping one workstation mostly secure from breakins is much
easier than keeping the entire local network secure from them.
- Nathan
