On 1/30/2013 6:42 AM, Viktor Dukhovni wrote:
On Wed, Jan 30, 2013 at 05:29:51PM +1300, T J wrote:
How does one obtain the session key from a SSL structure after a
successful TLS handshake?
You don't, but, you shold instead obtain the "tls-unique" channel
binding data ( https://tools.ietf.org/html/rfc5929#section-3 ) and
run the result through a KDF (HKDF should work well) on both ends
to obtain a suitable key for a symmetric algorithm of your choice.
Sorry, not such a good idea.
As I read RFC5929 and the TLS 1.2 RFC, it seems that despite some
vaguely promising language in RFC5929, the tls-unique value is *not*
suitable as the basis of an encryption key for the following reasons:
1. It is quite vague (underspecified) if and when the form of the
finished message used as the tls-unique value is A) sent in the clear
B) The already encrypted form of the message as sent over the network or
C) The plaintext passed to the TLS encryption mechanism before
transmission. In interpretation A and B the value is known to any
attackers, while in interpretation C it is known to attackers only if
the negotiated TLS encryption is NULL or weak.
2. The TLS 1.2 RFC seems clear that the raw input tls-unique value will
often be only 12 bytes (96 bits) which is not enough input to generate a
128 bit or stronger encryption key, no matter how clever the KDF.
It seems that the only proper use of the tls-unique value is as a way to
use an outside channel to authenticate the TLS session, not the other
way around.
The use that seems to be suggested in the text of RFC5929 is to use it
as an extra input to any strong authentication protocols (such as SRP
or HTTP-digest) done over the TLS session to prove to the other end
that the authentication is for this TLS session, and not for some TLS
session you are having with a man in the middle. This is safe even if
an attacker knows the value as long as he cannot force both ends of a
MitM compromised connection to use the same value and cannot compute
the needed changes in authentication messages to compensate for the
difference between the two tls-unique values from the two halfs of the
connection.
> (snip code to extract the tls-unique binary value from an SSL_CTX
> handle without a specific API for this task)
>
For HKDF see: https://tools.ietf.org/html/rfc5869
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
