In other words, something basic like
--- wget\src\gen_sslfunc.c Fri Nov 30 09:18:19 2001
+++ wget.wip\src\gen_sslfunc.c Mon Dec 3 16:05:37 2001
@@ -70,6 +70,7 @@
RAND_seed((unsigned char *)&t, sizeof(time_t));
/* Initialize system's random number generator */
RAND_bytes((unsigned char *)&seed, sizeof(long));
+#ifndef WINDOWS
srand48(seed);
while (RAND_status () == 0)
{
@@ -78,6 +79,12 @@
l = lrand48();
RAND_seed((unsigned char *)&l, sizeof(long));
}
+#else /* WINDOWS */
+ RAND_screen();
+ if (RAND_status() == 0)
+ /* Here we should probably disable the whole ssl protocol ? HEH
*/
+ DEBUGP (("SSL random data generator not seeded correctly, %i",
RAND_status()));
+#endif /* WINDOWS */
if (rand_file != NULL)
{
/* Write a rand_file */
should be somewhat ok. At least it does compile and work (just tested).
However openssl.org in 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 leave it to somebody more knowledgeable to determine if wget can catch
windows events (I think not without major additions ? Probably I'm
wrong.) and in case to produce a patch, in the meantime, if this is the
best we've got, Hrvoje please add it to cvs if you like it.
However I'm a bit bothered about the last sentence in that man page -
there could be somebody running a NT server without any user interaction
in order to wget mirror something from scheduler or something. On the
other hand if security is on hand at least the ssl randomness should be
perused before. Possibly would be appropriate a note in the
Changelog:
* gen_sslfunc.c: provide ssl crypto random initialization
through RAND_screen();
could possibly not enough for strong ssl communication (see
the relevant
manual page from the openssl package).
Heiko
--
-- PREVINET S.p.A. [EMAIL PROTECTED]
-- Via Ferretto, 1 ph x39-041-5907073
-- I-31021 Mogliano V.to (TV) fax x39-041-5907087
-- ITALY
> -----Original Message-----
> From: Daniel Stenberg [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 03, 2001 3:33 PM
> To: Herold Heiko
> Cc: [EMAIL PROTECTED]
> Subject: Re: Win ssl bug
>
>
> On Mon, 3 Dec 2001, Herold Heiko wrote:
>
> > However it still won' work due to mising
> >
> > gen_sslfunc.obj : error LNK2001: unresolved external symbol _lrand48
> > gen_sslfunc.obj : error LNK2001: unresolved external symbol _srand48
> >
> > In fact looking through the VC++ documentation there
> doesn't seem to be a
> > rand48() available.
>
> You can replace those onse with just plain rand() and srand()
> or just write
> your own.
>
> No one in their right mind shall ever depend on using that
> random value
> anyway for anything that pretends to be secure, as that wouldn't be
> considered random enough, and thus it is not secure enough to
> use for seeding
> SSL.
>
> If /dev/urandom or similar isn't present, a serious SSL-using
> person should
> provide a good random source himself. If not, there's not
> much difference in
> using lrand48() or just plain rand(). They're both software
> (faked) random
> generators.
>
> For windows users, I recommend using the RAND_screen()
> function (it is only
> presen in windows), it uses the current displayed screen as
> input to the
> random engine.
>
> Of course, I may be completely wrong.
>
> --
> Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
> ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
>
