parent
98a3c3c514
commit
a414bc8c3e
1 changed files with 15 additions and 2 deletions
|
@ -49,8 +49,10 @@ the callback function will be called with I<enc> equal to 1. The OpenSSL
|
|||
library expects that the function will set an arbitary I<name>, initialize
|
||||
I<iv>, and set the cipher context I<ctx> and the hash context I<hctx>.
|
||||
|
||||
The I<name> is only 16 characters long. The I<iv> is of length
|
||||
L<EVP_MAX_IV_LENGTH> defined in B<evp.h>.
|
||||
The I<name> is 16 characters long and is used as a key identifier.
|
||||
|
||||
The I<iv> length is the length of the IV of the corresponding cipher. The
|
||||
maximum IV length is L<EVP_MAX_IV_LENGTH> bytes defined in B<evp.h>.
|
||||
|
||||
The initialization vector I<iv> should be a random value. The cipher context
|
||||
I<ctx> should use the initialisation vector I<iv>. The cipher context can be
|
||||
|
@ -110,6 +112,17 @@ an all other negotiated state information encrypted within the ticket. In a
|
|||
resumed session the applications will have all this state information available
|
||||
exactly as if a full negiotation had occured.
|
||||
|
||||
If an attacker can obtain the key used to encrypt a session ticket, they can
|
||||
obtain the master secret for any ticket using that key and decrypt any traffic
|
||||
using that session: even if the ciphersuite supports forward secrecy. As
|
||||
a result applications may wish to use multiple keys and avoid using long term
|
||||
keys stored in files.
|
||||
|
||||
Applications can use longer keys to maintain a consistent level of security.
|
||||
For example if a ciphersuite uses 256 bit ciphers but only a 128 bit ticket key
|
||||
the overall security is only 128 bits because breaking the ticket key will
|
||||
enable an attacker to obtain the session keys.
|
||||
|
||||
=head1 EXAMPLES
|
||||
|
||||
Reference Implemention:
|
||||
|
|
Loading…
Reference in a new issue