id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
142	analyze consequences of recent TLS plaintext-injection vulnerability	Brian Warner		"A week ago, a new problem in TLS surfaced, in which an attacker can inject arbitrary plaintext into the supposedly-authenticated connection just after a ""renegotiation"" takes place. There was also some suggestion that the attacker could force a renegotiation to occur whenever they liked. I don't yet know if this means that the attacker can inject data into just the beginning of the conversation, or into other places too.

Foolscap is somewhat less vulnerable to this than systems (like HTTP using client-side certificates) that depend upon authorizing clients. Foolscap generally doesn't care *who* you are, just whether or not you know the swissnum.

However, a plaintext-injecting attacker could still cause mischief, sometimes with consequences that violate the expected security properties. If the injection can occur after a {{{getReferenceByName}}}, then the attacker will be able to send arbitrary messages to objects which the real client has already accessed and retains a {{{RemoteReference}}} to (because the swissnum-to-CLID mapping is cached for each connection). They'd have to guess which object you're using, and what methods/arguments it responds to, and couldn't see the results.

The attacker could also inject a message which updates the ""vocab table"" (a mapping from small integer to string, used to compress frequently-used strings like ""getReferenceByName""). This would probably only be usable to prevent methods from being called (a DoS attack), but the attacker might also be able to e.g. transform calls to remote_foo() into calls to remote_bar().

We need to:
 * learn more about the TLS vulnerability: arbitrary injection, or only at the beginning?
 * identify where renegotiation might take place
 * explain how foolscap-using applications might be vulnerable

(note that if every single message included the swissnum, and we didn't use CLIDs at all, then the injection-vulnerability window would be much smaller: they'd have to jam something exactly after the swissnum and before the normal message name/args).
"	defect	new	major	undecided	unknown	0.4.1		security