diff options
author | Nick Mathewson <nickm@torproject.org> | 2015-05-25 17:12:49 -0400 |
---|---|---|
committer | Matt Caswell <matt@openssl.org> | 2015-05-28 16:05:01 +0100 |
commit | 858618e7e037559b75b0bfca4d30440f9515b888 (patch) | |
tree | 88e7816fd7353b59238fdf1c52ae37c6a352b7f1 /doc | |
parent | 9ef175148b7da12cb09f5e78f32bc6ab58d78b83 (diff) | |
download | openssl-858618e7e037559b75b0bfca4d30440f9515b888.tar.gz |
Add new functions to extract {client,server}_random, master_key
Tor uses these values to implement a low-rent clone of RFC 5705 (which,
in our defense, we came up with before RFC 5705 existed). But now that
ssl_st is opaque, we need another way to get at them.
Includes documentation, with suitable warnings about not actually
using these functions.
Signed-off-by: Nick Mathewson <nickm@torproject.org>
Signed-off-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Diffstat (limited to 'doc')
-rw-r--r-- | doc/ssl/SSL_get_client_random.pod | 73 |
1 files changed, 73 insertions, 0 deletions
diff --git a/doc/ssl/SSL_get_client_random.pod b/doc/ssl/SSL_get_client_random.pod new file mode 100644 index 0000000000..e31d3f0a28 --- /dev/null +++ b/doc/ssl/SSL_get_client_random.pod @@ -0,0 +1,73 @@ +=pod + +=head1 NAME + +SSL_get_client_random, SSL_get_server_random, SSL_SESSION_get_master_key - retrieve internal TLS/SSL random values and master key + +=head1 SYNOPSIS + + #include <openssl/ssl.h> + + int SSL_get_client_random(const SSL *ssl, unsigned char *out, int outlen); + int SSL_get_server_random(const SSL *ssl, unsigned char *out, int outlen); + int SSL_SESSION_get_master_key(const SSL_SESSION *session, unsigned char *out, int outlen); + +=head1 DESCRIPTION + +SSL_get_client_random() extracts the random value sent from the client +to the server during the initial SSL/TLS handshake. It copies this +value into the buffer provided in B<out>, which must have at least +B<outlen> bytes available. It returns the total number of bytes that were +actually copied. +If B<outlen> is less than zero, SSL_get_client_random() copies nothing, and +returns the total size of the client_random value. + +SSL_get_server_random() behaves the same, but extracts the random value +sent from the server to the client during the initial SSL/TLS handshake. + +SSL_SESSION_get_master_key() behaves the same, but extracts the master +secret used to guarantee the security of the SSL/TLS session. This one +can be dangerous if misused; see NOTES below. + + +=head1 NOTES + +You probably shouldn't use these functions. + +These functions expose internal values from the TLS handshake, for +use in low-level protocols. You probably should not use them, unless +you are implementing something that needs access to the internal protocol +details. + +Despite the names of SSL_get_client_random() and SSL_get_server_random(), they +ARE NOT random number generators. Instead, they return the mostly-random values that +were already generated and used in the TLS protoccol. Using them +in place of RAND_bytes() would be grossly foolish. + +The security of your TLS session depends on keeping the master key secret: +do not expose it, or any information about it, to anybody. +If you need to calculate another secret value that depends on the master +secret, you should probably use SSL_export_keying_material() instead, and +forget that you ever saw these functions. + +Finally, though the "client_random" and "server_random" values are called +"random", many TLS implementations will generate four bytes of those +values based on their view of the current time. + + +=head1 RETURN VALUES + +If B<outlen> is at least 0, these functions return the number of bytes +actually copied, which will be less than or equal to B<outlen>. + +If B<outlen> is less than 0, these functions return the maximum number +of bytes they would copy--that is, the length of the underlying field. + +=head1 SEE ALSO + +L<ssl(3)|ssl(3)>, +L<RAND_bytes(3)|RAND_bytes(3)>, +L<SSL_export_keying_material(3)|SSL_export_keying_material(3)> + + +=cut |