Joe Orton wrote:
> 1) why do we need a new config directive for session ticket support?
> I'm struggling to understand why any server admin would need/want
> control over support for session tickets.
Session tickets are a relatively new thing (RFC 4507 is from May 2006),
and I'm not sure how we
On Mon, Nov 09, 2009 at 07:06:16PM +0100, Kaspar Brand wrote:
> Dr Stephen Henson wrote:
> > Yes that looks better. There is an alternative technique if it is easier to
> > find
> > a "base" SSL_CTX, you can retrieve the auto generated keys using
> > SSL_CTX_get_tlsext_ticket_keys() and then copy
Dr Stephen Henson wrote:
> Yes that looks better. There is an alternative technique if it is easier to
> find
> a "base" SSL_CTX, you can retrieve the auto generated keys using
> SSL_CTX_get_tlsext_ticket_keys() and then copy to the new context as above.
The loop actually iterates over all contex
Kaspar Brand wrote:
> Dr Stephen Henson wrote:
>> A few comments about that:
>
> Thanks for the review!
>
>> These are cryptographic keys (or at least the HMAC and AES keys are) so you
>> should use RAND_bytes(), not RAND_pseudo_bytes().
>
> Ok - when looking at ssl_lib.c:SSL_CTX_new(), I didn't
Dr Stephen Henson wrote:
> A few comments about that:
Thanks for the review!
> These are cryptographic keys (or at least the HMAC and AES keys are) so you
> should use RAND_bytes(), not RAND_pseudo_bytes().
Ok - when looking at ssl_lib.c:SSL_CTX_new(), I didn't realize that
RAND_pseudo_bytes() i
Kaspar Brand wrote:
+#if !defined(OPENSSL_NO_TLSEXT) && OPENSSL_VERSION_NUMBER < 0x009080d0
+#define TICK_KEYS_LEN sizeof(((SSL_CTX *)0)->tlsext_tick_key_name) \
+ + sizeof(((SSL_CTX *)0)->tlsext_tick_hmac_key) \
+ + sizeof(((SSL_CTX *)0)->tlsext_tick_a
Kaspar Brand wrote:
> Does that sound reasonable? If so, I would prepare a new patch with
> SSL_CTX_set_tlsext_ticket_keys and the new config directive.
No reactions = no objections?
Would it perhaps be possible to piggyback onto Joe's reneg patch and get
this also into 2.2.15...? ;-)
Attached a
On 11/04/2009 05:59 PM, Kaspar Brand wrote:
> Ruediger Pluem wrote:
>>> 2) In the SNI callback, it adjusts OpenSSL's session id context - which
>>> makes sure that the session can be properly resumed. (With the current
>>> mod_ssl code, this context is always tied to the first vhost, possibly
>>
Ruediger Pluem wrote:
> I guess your current patch fails on trunk since
> myModConfig(s))->nSessionCacheMode
> is no longer present in trunk
Oops, you're right - my bad. I didn't compile trunk with that last
change applied, obviously. For trunk, it should be
if ((myModConfig(s))->sesscache_m
On 11/04/2009 10:35 AM, Kaspar Brand wrote:
> Kamesh Jayachandran wrote:
>> Reasonable fix for this on the server side is to apply SSL_OP_NO_TICKET
>> patch and enable SSLSessionCache.
>
> There is actually another reason why disabling TLS session tickets makes
> sense at the present time: with
Kaspar Brand wrote:
> Kamesh Jayachandran wrote:
>> Reasonable fix for this on the server side is to apply SSL_OP_NO_TICKET
>> patch and enable SSLSessionCache.
>
> There is actually another reason why disabling TLS session tickets makes
> sense at the present time: with OpenSSL's current stable
Thanks Kaspar.
I tested your patch against 2.2 branch on to my apache-2.2.12 and found
it to be working.
My observations:
Without SSLSessionCache it failed as usual after a long time.
With SSLSessionCache it succeeded.
Looking forward for this patch to get committed.
Thanks to all involved
12 matches
Mail list logo
