Odpowiedz automatyczna:
Do 5 maja przebywam na zasluzonym urlopie.
W pilnych sprawach prosze o kontakt z Kamilem Kilinskim.
Z powazaniem,
Michal Trojnara
>>> "[EMAIL PROTECTED]" 04/27/00 07:18 >>>
Amit Chopra <[EMAIL PROTECTED]>:
> I had posted a query about using the SSL_CTX_set_tmp_rsa/dsa_cb(...).
> I was using the callback so that i'd generate a new ephemeral key for
> every session.
> The impression i got from the reply was that instead of setting the
> callback and generating\selecting a key during SSL_accept, I can at
> startup generate ephemeral keys at startup and set them into SSL_CTX
> using SSL_CTX_set_tmp_rsa/dsa(...). This did solve my leaks problem
> but I am wondering if it is safe to be using the same ephemeral keys
> all through the run of the application (i.e across probably thousands of
> sessions).
This depends on how the parameters have been generated. If you
use safe primes (modulus p such that (p-1)/2 is prime too),
this is no problem; but if you use DSA-style parameters,
you should use SSL_CTX_set_options(ctx, SSL_OP_SINGLE_DH_USE)
to use a fresh key for each connection (see ssl/ssltest.c).
> And btw using the callback for ephemeral keys still causes memory to
> leak.
Because you don't call DH_free for each DH structure that you created,
presumably (I've modified s_server to use a callback for its DH
structures just as it does for RSA, and it did not leak memory).
This may be some ex_data problem if that's what you're using,
but I don't think it's a callback problem (except that there's
no possibility to hand over a reference count to the library
when returning something from these callbacks -- DH structures don't
have reference counters, which is very inconvenient here).
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
