[Cryptography] Langsec & authentication

Viktor Dukhovni cryptography at dukhovni.org
Tue May 27 09:38:00 EDT 2014


On Mon, May 26, 2014 at 10:24:35PM -0400, Phillip Hallam-Baker wrote:

> For each client/server interface there is a rigorous separation of the
> message and API. First the entire message is read in and
> authenticated. Only if the message verifies is it passed to the
> parser. And only messages that parse correctly are passed to the
> handler.

Fully agree with the sentiment.

> So for example, imagine we have a TLS session using RC4 encryption
> that plops a MAC value onto the pipe every 64Kb. And the target
> environment has some sort of SSL accelerator in place.

No SSL library (or accelerator) has any business delivering raw
decrypted payload whose MAC has not been checked to the application.
Any that do are seriously defective.   My imagination does not
stretch far enough to admit fatally broken implementations as
plausible straw-man examples.

The API that checks message signatures could also be fatally flawed.
It is turtles all the way down.

> Unless the
> application developer reaches into the TLS stack to assure themselves
> that their packets are too going to be authenticated properly it is
> quite possible that the receiving end pulls a 2048 byte transaction
> 'fire the nuclear missiles' out of the TLS stream and acts on it
> before the MAC value is found to be bad and the socket closes. Since
> we are using a stream cipher with chosen plaintext it is easy to
> recover and reuse the cipherkey.

The straw-man is on fire.  In the mean time real implementations
don't return plaintext that has not been MACed.

> Requiring every transaction to have a separate application layer
> authentication blob protects against any nonsense at the transport
> layer and protects against injection attacks. There is no possibility
> of injecting commands when every command requires a separate
> authentication value.

This is back on much firmer footing, signed messages are sometimes
semantically preferrable to signed transport, although with message
signatures not channel-bound to a transport, one has to be much
more careful about replay attacks.  No silver bullet.

-- 
	Viktor.


More information about the cryptography mailing list