[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] DTLS handshake message encryption
|
> the messages are encrypted as part of the Handshaker.wrapMessage(Record)
> method where Record instances are created for the outgoing DTLSMessages. As
> part of Record's constructor the Record.setFragment(DTLSMessage) method is
> invoked where the encryption takes place invariably for all types of messages. It
> seems that the original idea in the code was to control the need for encryption
> by means of the existence of a DTLSSession within the Record instance.
> However, this obviously does not work for a rehandshake or session resumption
> where the server still has a cached session.
Oh, yes that call in the constructor...
Actually, the case for HANDSHAKE in setFragment() should be handled differently.
> Regarding understanding of the spec: What's the meaning of "special case for
> the FINISHED message"? Do you think that it should be encrypted according to
> the current session state? I think that only the incuded hash is generated using
> the (newly) negotiated crypto params but the fragment itself is still plaintext.
Well, it goes through the PRF, so the parameters are not in plaintext. That's what I meant with special case; not that FINISHED should be encrypted.
> The spec explicitly states that Change Cipher Spec messages must be encrypted
> according to the current session state, i.e. in an initial handshake the message is
> not encrypted, whereas in a rehandshake it would be encrpyted using the
> session's current state, right?
Yes and it only consists of the CCS.
In the case of resumption, the current state is still unencrypted after the resuming ClientHello. Only after the CCS you switch to the encrypted state and ensure the parameters with the cryptographic FINISHED message as usual.
I think we are on the same page here :)
I agree that there is something wrong in the setFragment() method. And we need some refactoring to make the encryption more explicit than this constructor call and misleading "setFragment" name!
Ciao
Matthias
