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 well
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 to the new
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 contexts,
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
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
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() is
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 realize
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 version
(0.9.8k), session
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
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 version
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
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_mode
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
resulting
13 matches
Mail list logo
