Re: [TLS] Unifying tickets and sessions

[Richard Fussenegger <[e-mail]>]

On 10/22/2014 9:09 PM, Viktor Dukhovni wrote:
> On Wed, Oct 22, 2014 at 08:42:15PM +0200, Richard Fussenegger wrote:
>
>> Viktor Dukhovni already mentioned that
>> OpenSSL is actually supporting different key strengths, but for instance
>> nginx isn't exposing this setting to administrators.
> For the record OpenSSL makes it possible for applications to use
> some other block cipher than aes-128-cbc, but this is not as easy
> as it sounds.  The application needs to register appropriate
> callbacks and take over key life-cycle management.  So simply using
> some other cipher-suite is not a trivial exercise, rather only once
> one is already managing key rotation via the callbacks, making the
> cipher configurable is trivial:
>
> The code for this is roughly:
>
>      #define TLS_TICKET_NAMELEN      16      /* RFC 5077 ticket key name length */
>      #define TLS_TICKET_IVLEN        16      /* RFC 5077 ticket IV length */
>      #define TLS_TICKET_KEYLEN       32      /* AES-256-CBC key size */
>      #define TLS_TICKET_MACLEN       32      /* RFC 5077 HMAC key size */
>
>      typedef struct TLS_TICKET_KEY {
> 	unsigned char name[TLS_TICKET_NAMELEN];
> 	unsigned char bits[TLS_TICKET_KEYLEN];
> 	unsigned char hmac[TLS_TICKET_MACLEN];
> 	time_t  tout;
>      } TLS_TICKET_KEY;
>
>      #define NOENGINE				((ENGINE *) 0)
>      #define TLS_TKT_NOKEYS	-1		/* No keys for encryption */
>      #define TLS_TKT_STALE	0		/* No matching keys for decryption */
>      #define TLS_TKT_ACCEPT	1		/* Ticket decryptable and re-usable */
>      #define TLS_TKT_REISSUE	2		/* Ticket decryptable, not re-usable */
>
>      static int ticket_cb(SSL *con, unsigned char name[], unsigned char iv[],
> 			      EVP_CIPHER_CTX * ctx, HMAC_CTX * hctx, int create)
>      {
> 	static const EVP_MD *sha256;
> 	static const EVP_CIPHER *ciph;
> 	TLS_TICKET_KEY *key;
> 	int     timeout = ((int) SSL_CTX_get_timeout(SSL_get_SSL_CTX(con))) / 2;
>
> 	if ((!sha256 && (sha256 = EVP_sha256()) == 0)
> 	    || (!ciph && (ciph = EVP_get_cipherbyname(var_tls_tkt_cipher)) == 0)
> 	    || (key = tls_mgr_key(create ? 0 : name, timeout)) == 0
> 	    || (create && RAND_bytes(iv, TLS_TICKET_IVLEN) <= 0))
> 	    return (create ? TLS_TKT_NOKEYS : TLS_TKT_STALE);
>
> 	HMAC_Init_ex(hctx, key->hmac, TLS_TICKET_MACLEN, sha256, NOENGINE);
>
> 	if (create) {
> 	    EVP_EncryptInit_ex(ctx, ciph, NOENGINE, key->bits, iv);
> 	    memcpy((char *) name, (char *) key->name, TLS_TICKET_NAMELEN);
> 	} else {
> 	    EVP_DecryptInit_ex(ctx, ciph, NOENGINE, key->bits, iv);
> 	}
> 	return (TLS_TKT_ACCEPT);
>      }
>
> Plus additional supporting functions to fetch encryption/decryption
> keys, subject to appopriate key rotation policies, (in the above
> case tls_mgr_key() whose implementation is rather application
> specific).
>
> Perhaps I'll donate a variant of this code to OpenSSL, and then we
> can ask users to just provide algorithm name, and either a key
> lifetime for automatic in memory keys or callbacks to access
> externally managed keys.
>
That would be great and exactly what the world needs. It's also the 
reason for my proposed changes that should be made during merge of 
RFC5077, so that OpenSSL will finally implement proper configurable 
rotation and configurable ticket ciphers. Applications like nginx 
wouldn't have to start implementing cryptographic stuff (which is a 
dangerous game), rather simply exposing the configuration options of 
OpenSSL which handles everything internally.

A nice to have above this would be some warning that is emitted if 
ciphers are configured that are actually stronger than the key used for 
the tickets. But that's already implementation specific stuff and has 
nothing to do with the RFC.

Richard