Ok the slow down on windows is because openssl runs through the proccess
heap looking for entropy.
If you make the initial ssl connection after the app has initialized the
heap size can be very large

Other people on the openssl list report 30 second wait times after the
heap has been initialized
http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&threadm=ca900f%24829%241%40FreeBSD.csie.NCTU.edu.tw&prev=/groups%3Fgroup%3Dmailing.openssl.users
But even after implementing their ideas, it requires 10 seconds to go
through the heap to obtain 2048 bytes from the heap.

RAND_poll seems to be the primary means of finding entropy on the
windows platform.
( it takes in account all kinds of system properties, user properties,
and process information to ensure entropy )
RAND_screen seems to be a old, less effect, outdated means of finding
entropy on the windows platform. ( RAND_screen calls RAND_poll to
improve the entropy )

curl takes 60second because
    1. RAND_screen calls RAND_poll ( 1st 30 seconds )
    2. RAND_status then calls RAND_poll again ( 1st 30 seconds )

Both openssl functions RAND_status and RAND_bytes call RAND_poll and
wrap that call with a openssl initialized flag to prohibit repeated
unnecessary RAND_poll calls.
So by calling RAND_bytes early in application init the 2nd RAND_poll can
be avoided.
RAND_screen seems old and outdated. First it doesn't use the openssl
initialized flag to prohibit repeated RAND_poll calls.

man RAND_add(3) says:
    The RAND_screen() function is available for the convenience of
Windows programmers. It adds the current contents of the screen to the
PRNG. For applications that can catch Windows events, seeding the PRNG
by calling RAND_event() is a significantly better source of randomness.
It should be noted that both methods cannot be used on servers that run
without user interaction.

I would recommend replacing the RAND_screen call with a call to
RAND_bytes( &c, 1 );
because this call would be wrapped inside the HAVE_RAND_SCREEN it would
only effect the windows platform and would eliminate the 1st call the
RAND_poll
leaving the second call (RAND_status ) to do the work if the openssl
initialized flag has not previously been called.
 
lib/ssluse.c:177
#ifdef HAVE_RAND_SCREEN
  /* This one gets a random value by reading the currently shown screen */
  //old code
 RAND_screen();
  // new code
  unsigned char c ;
  RAND_bytes( &c, 1 );
  // end new code
  nread = 100; /* just a value */
#else

Looking for feedback,
Listman

Daniel Stenberg wrote:

>On Tue, 8 Jun 2004, listman wrote:
>
>
>
>>I've looked and found that entropy init occurs on the first successfull
>>SSL connection.
>>
>>RAND_screen takes about 60 seconds on a P4 2.4 ghz RAND_add & RAND_status
>>takes about 30 seconds on the same machine. Which is a long time to wait on
>>the first SSL connection.
>>
>>
>
>*yikes*
>
>I figure this is only when using Windows? I've never seen anything but swift
>operation on my various unix-uses. Also, I get the feeling most people do not
>get this major slowdown as you experience, as then people would've been
>complaining louder earlier...
>
>
>
>>I would like an additional exported function that would allow early init of
>>the SSL entropy data ( ie before a libcurl handle is opened ). I'm willing
>>to submit a patch if there is interest.
>>
>>
>
>We could in fact do the seeding already when curl_global_init() sets up the
>SSL stuff. If a specific bit is set. The benefit I've seen with doing it on
>the first SSL connect is that if you never do any SSL connects you never waste
>any time doing the seeding.
>
>
>
>>What are people's opinion of using
>>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/cryptgenrandom.asp
>>on the windows plaform instead of RAND_screen?
>>
>>
>
>I could indeed consider changing how the entropy is gathered, but this is
>security stuff so it takes a great deal of consideration and proper research
>first. I suggest you first take this up with the proper OpenSSL people to
>figure out what they consider regarding the improving of this situation.
>
>
>
>>openssl docs state that RAND_screen should not be used on a non-interactive
>>machine such as a windows server.
>>
>>
>
>The openssl docs unfortunately is and was in a sorry state. Most good OpenSSL
>facts are obtained by asking people or reading source code, IMHO.
>
>But this is news to me. So we should replace the RAND_screen() usage with
>something else indeed!
>
>
>
Received on 2004-06-10