You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@attglobal.net> on 2001/12/18 14:55:10 UTC
[PATCH] get mod_ssl to work again
mod_ssl has some questionable access to the scoreboard which doesn't
work correctly starting a few minutes ago because SCOREBOARD_SIZE is
much smaller than it expects (< 1024, not indicative of the real size
of the scoreboard).
This patch should get things going again, but I wonder if anybody has
a better idea for seeding the random number generator, since this is
an unfortunate dependence on the memory allocation of the scoreboard.
Index: include/scoreboard.h
===================================================================
RCS file: /home/cvspublic/httpd-2.0/include/scoreboard.h,v
retrieving revision 1.34
diff -u -r1.34 scoreboard.h
--- include/scoreboard.h 2001/12/18 13:48:52 1.34
+++ include/scoreboard.h 2001/12/18 13:52:43
@@ -195,9 +195,6 @@
char value[VALUE_LENGTH];
} status_table_entry;
-/* XXX what should mod_ssl init use instead of this? */
-#define SCOREBOARD_SIZE sizeof(scoreboard)
-
AP_DECLARE(int) ap_exists_scoreboard_image(void);
AP_DECLARE_NONSTD(void) ap_create_scoreboard(apr_pool_t *p, ap_scoreboard_e t);
AP_DECLARE(void) ap_increment_counts(void *sbh, request_rec *r);
@@ -220,6 +217,7 @@
AP_DECLARE(worker_score *) ap_get_servers_scoreboard(int x, int y);
AP_DECLARE(process_score *) ap_get_parent_scoreboard(int x);
AP_DECLARE(global_score *) ap_get_global_scoreboard(void);
+AP_DECLARE(apr_size_t) ap_get_scoreboard_size(void);
AP_DECLARE_DATA extern scoreboard *ap_scoreboard_image;
AP_DECLARE_DATA extern const char *ap_scoreboard_fname;
Index: modules/ssl/ssl_engine_rand.c
===================================================================
RCS file: /home/cvspublic/httpd-2.0/modules/ssl/ssl_engine_rand.c,v
retrieving revision 1.7
diff -u -r1.7 ssl_engine_rand.c
--- modules/ssl/ssl_engine_rand.c 2001/11/29 05:17:38 1.7
+++ modules/ssl/ssl_engine_rand.c 2001/12/18 13:52:44
@@ -153,7 +153,7 @@
* seed in an 1KB extract of the current scoreboard
*/
if (ap_scoreboard_image != NULL) {
- n = ssl_rand_choosenum(0, SCOREBOARD_SIZE-1024-1);
+ n = ssl_rand_choosenum(0, ap_get_scoreboard_size()-1024-1);
RAND_seed((unsigned char *)ap_scoreboard_image+n, 1024);
nDone += 1024;
}
Index: server/scoreboard.c
===================================================================
RCS file: /home/cvspublic/httpd-2.0/server/scoreboard.c,v
retrieving revision 1.40
diff -u -r1.40 scoreboard.c
--- server/scoreboard.c 2001/12/18 13:48:52 1.40
+++ server/scoreboard.c 2001/12/18 13:52:44
@@ -435,3 +435,8 @@
{
return(&ap_scoreboard_image->global);
}
+
+AP_DECLARE(apr_size_t) ap_get_scoreboard_size(void)
+{
+ return scoreboard_size;
+}
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] get mod_ssl to work again
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Daniel Lopez" <da...@covalent.net>
Sent: Thursday, December 20, 2001 1:26 PM
> On Thu, Dec 20, 2001 at 11:07:13AM -0800, Doug MacEachern wrote:
> > On Thu, 20 Dec 2001, Daniel Lopez wrote:
> >
> > >
> > > /dev/urandom is not available in all platforms
> >
> > right, which is why it is not portable to use directly.
>
> I was not arguing, I was just reinstating your point :)
> On NT openssl uses data from the screen. I like the idea of using truerand.c
> or whatever the genrandom program bundled with openssl uses.
Huh? No ... maybe a long time ago, but now it is digging up performance
metrics and so forth from the cpu (I'm certain - had to fix some older
SSL code that assumed we had the opcodes - they are so recent that older
MSVCs asm{} blocks couldn't parse them.)
Re: [PATCH] get mod_ssl to work again
Posted by Daniel Lopez <da...@covalent.net>.
On Thu, Dec 20, 2001 at 11:07:13AM -0800, Doug MacEachern wrote:
> On Thu, 20 Dec 2001, Daniel Lopez wrote:
>
> >
> > /dev/urandom is not available in all platforms
>
> right, which is why it is not portable to use directly.
I was not arguing, I was just reinstating your point :)
On NT openssl uses data from the screen. I like the idea of using truerand.c
or whatever the genrandom program bundled with openssl uses.
> /dev/random is
> also not available on all platforms, so apr uses whats available to
> provide the same functionality for the given platform in
> apr_generate_random_bytes().
>
Re: [PATCH] get mod_ssl to work again
Posted by Doug MacEachern <do...@covalent.net>.
On Thu, 20 Dec 2001, Daniel Lopez wrote:
>
> /dev/urandom is not available in all platforms
right, which is why it is not portable to use directly. /dev/random is
also not available on all platforms, so apr uses whats available to
provide the same functionality for the given platform in
apr_generate_random_bytes().
Re: [PATCH] get mod_ssl to work again
Posted by Daniel Lopez <da...@rawbyte.com>.
/dev/urandom is not available in all platforms
On Thu, Dec 20, 2001 at 10:40:09AM -0800, Doug MacEachern wrote:
> On Thu, 20 Dec 2001, Aaron Bannert wrote:
>
> > /dev/urandom won't block, so maybe we could live with that once per
> > request and use the /dev/random for startup.
>
> right, only problem is apr doesn't support /dev/urandom. maybe we need an
> apr_generate_urandom_bytes() function or a non-blocking flag to
> apr_generate_random_bytes()?
>
> modssl already has:
> SSLRandomSeed connect file:/dev/urandom 512
>
> but something more portable would be nice.
>
Re: [PATCH] get mod_ssl to work again
Posted by Doug MacEachern <do...@covalent.net>.
On Thu, 20 Dec 2001, Aaron Bannert wrote:
> /dev/urandom won't block, so maybe we could live with that once per
> request and use the /dev/random for startup.
right, only problem is apr doesn't support /dev/urandom. maybe we need an
apr_generate_urandom_bytes() function or a non-blocking flag to
apr_generate_random_bytes()?
modssl already has:
SSLRandomSeed connect file:/dev/urandom 512
but something more portable would be nice.
Re: [PATCH] get mod_ssl to work again
Posted by Aaron Bannert <aa...@clove.org>.
On Thu, Dec 20, 2001 at 10:17:13AM -0800, Doug MacEachern wrote:
> that function was derived from mod_ssl-1.xx and have learned some
> things since. i recently noticed OpenSSL internally calls
> RAND_seed(time()) during negotiation. so i was planning to remove that
> same call from modssl or at least change it to use r->request_time.
> (main goal: getting rid of time() and getpid() syscalls on every connect)
>
> since flood only seeds at startup time, might be better for you just to
> use apr_generate_random_bytes(). don't want to use that in modssl for
> 'SSLRandomSeed builtin connect', since /dev/random blocking will be too
> slow for every connect. but will probably change it to use that for
> 'SSLRandomSeed builtin startup'.
/dev/urandom won't block, so maybe we could live with that once per
request and use the /dev/random for startup.
-aaron
Re: [PATCH] get mod_ssl to work again
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Dec 20, 2001 at 11:00:13AM -0800, Aaron Bannert wrote:
> What is truerand.c? Can you provide a URL or perhaps a Message-ID in
> case it came up before and I missed it?
The only place I can find it is within mod_ssl's sources:
pkg.contrib/truerand.c
I can't find any online sources. I've just copied that version
to daedalus:
http://www.apache.org/~jerenkrantz/truerand.c
-- justin
Re: [PATCH] get mod_ssl to work again
Posted by Aaron Bannert <aa...@clove.org>.
On Thu, Dec 20, 2001 at 10:55:02AM -0800, Justin Erenkrantz wrote:
> As Daniel pointed out, /dev/{u}random isn't available on certain
> platforms (Solaris). And, in flood, this seeding is only used
> when /dev/{u}random are not available. APR does not support an
> internal PRNG. I've suggested it before and perhaps it is time
> that we integrate truerand.c (anyone have a better version than
> what is in mod_ssl?) so that we can always call
> apr_generate_random_bytes()?
>
> I think that truerand isn't installed in enough places that it
> merits our redistribution in APR. -- justin
What is truerand.c? Can you provide a URL or perhaps a Message-ID in
case it came up before and I missed it?
-aaron
Re: Internal PRNG was Re: [PATCH] get mod_ssl to work again
Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz <je...@ebuilt.com> writes:
> On Thu, Dec 20, 2001 at 03:11:54PM -0500, Jeff Trawick wrote:
> > But if you look at how truerand.c actually works, it is questionable
> > that APR should support it as-is because of its use of signals. I
> > don't think APR should be mucking around with signals like that.
>
> Oh, yeah, yuck. Is the use of signal() inherent to its proper
> operation or can we get rid of that?
It looks very integral to me. It seems to rely on the uncertainty of
when the signal will be driven???
> Or, would it make sense to do some research into PRNGs and use
> that as a basis instead of truerand.c? Or, is there some
> worthwhile aspect of truerand.c that merits our use of it?
> Does anyone have any other C implementations (under a suitable
> license) that would be good to use? I'm not sure how good a PRNG
> we need. I'm betting there are some piss-poor /dev/random
> implementations out there anyway. -- justin
All excellent questions :)
While googling around for this sort of thing I've seen complaints
about a /dev/random somebody had for Solaris some time ago.
If we can't find suitable code in the short term, I think for Apache's
benefit we could do some fork+truerand+exit kludge. mod_auth_digest
only needs it during initialization and it is disturbing that
mod_auth_digest won't build on so many platforms (assuming the admin
hasn't gathered truerand themself).
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Internal PRNG was Re: [PATCH] get mod_ssl to work again
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Dec 20, 2001 at 03:11:54PM -0500, Jeff Trawick wrote:
> But if you look at how truerand.c actually works, it is questionable
> that APR should support it as-is because of its use of signals. I
> don't think APR should be mucking around with signals like that.
Oh, yeah, yuck. Is the use of signal() inherent to its proper
operation or can we get rid of that?
Or, would it make sense to do some research into PRNGs and use
that as a basis instead of truerand.c? Or, is there some
worthwhile aspect of truerand.c that merits our use of it?
I know that Knuth Vol. 2 has a bunch of stuff on PRNGs in concept.
I don't know how current that is. Numerical Recipies in C has a
chapter on randomness (Chapter 7).
http://www.ulib.org/webRoot/Books/Numerical_Recipes/bookc.html
Does anyone have any other C implementations (under a suitable
license) that would be good to use? I'm not sure how good a PRNG
we need. I'm betting there are some piss-poor /dev/random
implementations out there anyway. -- justin
Re: [PATCH] get mod_ssl to work again
Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz <je...@ebuilt.com> writes:
> I think that truerand isn't installed in enough places that it
> merits our redistribution in APR. -- justin
+1 in general... AIX, OS/390, Tru64, HP-UX, older Solaris are
platforms I play on that don't have /dev/*random (leaving
mod_auth_digest unsupported)
But if you look at how truerand.c actually works, it is questionable
that APR should support it as-is because of its use of signals. I
don't think APR should be mucking around with signals like that.
truerand is supposedly pretty slow anyway. Perhaps we can make it
enen slower such by making it do its magic in a separate process to
avoid any interference with the signalling already in place?
Maybe the first time apr_generate_random_bytes() is called we
create a separate process where the truerand stuff runs and we talk to
it through a pipe? That is sort of like the entropy-gathering daemons
folks are using already except that it is handled under the covers by
APR. Or until somebody screams have it fork, do its magic, and exit
to avoid process cleanup problems?
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] get mod_ssl to work again
Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz <je...@ebuilt.com> writes:
> I think that truerand isn't installed in enough places that it
> merits our redistribution in APR. -- justin
+1 in general... AIX, OS/390, Tru64, HP-UX, older Solaris are
platforms I play on that don't have /dev/*random (leaving
mod_auth_digest unsupported)
But if you look at how truerand.c actually works, it is questionable
that APR should support it as-is because of its use of signals. I
don't think APR should be mucking around with signals like that.
truerand is supposedly pretty slow anyway. Perhaps we can make it
enen slower such by making it do its magic in a separate process to
avoid any interference with the signalling already in place?
Maybe the first time apr_generate_random_bytes() is called we
create a separate process where the truerand stuff runs and we talk to
it through a pipe? That is sort of like the entropy-gathering daemons
folks are using already except that it is handled under the covers by
APR. Or until somebody screams have it fork, do its magic, and exit
to avoid process cleanup problems?
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] get mod_ssl to work again
Posted by Doug MacEachern <do...@covalent.net>.
On Thu, 20 Dec 2001, Justin Erenkrantz wrote:
> so that we can always call apr_generate_random_bytes()?
oh, i assumed we already could. +1 on whatever it takes to make that
function usable on all platforms.
Re: [PATCH] get mod_ssl to work again
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Dec 20, 2001 at 10:17:13AM -0800, Doug MacEachern wrote:
> since flood only seeds at startup time, might be better for you just to
> use apr_generate_random_bytes(). don't want to use that in modssl for
> 'SSLRandomSeed builtin connect', since /dev/random blocking will be too
> slow for every connect. but will probably change it to use that for
> 'SSLRandomSeed builtin startup'.
As Daniel pointed out, /dev/{u}random isn't available on certain
platforms (Solaris). And, in flood, this seeding is only used
when /dev/{u}random are not available. APR does not support an
internal PRNG. I've suggested it before and perhaps it is time
that we integrate truerand.c (anyone have a better version than
what is in mod_ssl?) so that we can always call
apr_generate_random_bytes()?
I think that truerand isn't installed in enough places that it
merits our redistribution in APR. -- justin
Re: [PATCH] get mod_ssl to work again
Posted by Doug MacEachern <do...@covalent.net>.
On Thu, 20 Dec 2001, Justin Erenkrantz wrote:
> FWIW, DougM submitted this function to flood to generate OpenSSL
> entropy. I'd almost suggest somehow factoring this into apr-util
> since flood needs this too (and doesn't have a scoreboard).
that function was derived from mod_ssl-1.xx and have learned some
things since. i recently noticed OpenSSL internally calls
RAND_seed(time()) during negotiation. so i was planning to remove that
same call from modssl or at least change it to use r->request_time.
(main goal: getting rid of time() and getpid() syscalls on every connect)
since flood only seeds at startup time, might be better for you just to
use apr_generate_random_bytes(). don't want to use that in modssl for
'SSLRandomSeed builtin connect', since /dev/random blocking will be too
slow for every connect. but will probably change it to use that for
'SSLRandomSeed builtin startup'.
Re: [PATCH] get mod_ssl to work again
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Dec 20, 2001 at 11:29:43AM -0600, William A. Rowe, Jr. wrote:
> I'll see your +1 and double :)
>
> Yes - perhaps the MPM itself should generate ap_server_entropy.
FWIW, DougM submitted this function to flood to generate OpenSSL
entropy. I'd almost suggest somehow factoring this into apr-util
since flood needs this too (and doesn't have a scoreboard).
However, that'd require linking against OpenSSL in apr-util which
may be a no-no.
I wonder what ways we could do this though (some reason I'm
thinking as a nasty #define)? But, there is a definite value to
merging the implementations. -- justin
static void load_rand(void)
{
unsigned char stackdata[256];
time_t tt;
pid_t pid;
int l, n;
tt = time(NULL);
l = sizeof(time_t);
RAND_seed((unsigned char *)&tt, l);
pid = (pid_t)getpid();
l = sizeof(pid_t);
RAND_seed((unsigned char *)&pid, l);
n = ssl_rand_choosenum(0, sizeof(stackdata)-128-1);
RAND_seed(stackdata+n, 128);
}
Re: [PATCH] get mod_ssl to work again
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Doug MacEachern" <do...@covalent.net>
Sent: Thursday, December 20, 2001 11:07 AM
> On 18 Dec 2001, Jeff Trawick wrote:
>
> > or just an entropy function? why should any module care that it is
> > from the scoreboard?
>
> +1 on that or anything to get mod_ssl working again.
I'll see your +1 and double :)
Yes - perhaps the MPM itself should generate ap_server_entropy.
Re: [PATCH] get mod_ssl to work again
Posted by Doug MacEachern <do...@covalent.net>.
On 18 Dec 2001, Jeff Trawick wrote:
> or just an entropy function? why should any module care that it is
> from the scoreboard?
+1 on that or anything to get mod_ssl working again.
Re: [PATCH] get mod_ssl to work again
Posted by Jeff Trawick <tr...@attglobal.net>.
"William A. Rowe, Jr." <wr...@covalent.net> writes:
> From: "Jeff Trawick" <tr...@attglobal.net>
> Sent: Tuesday, December 18, 2001 7:55 AM
>
>
> > mod_ssl has some questionable access to the scoreboard which doesn't
> > work correctly starting a few minutes ago because SCOREBOARD_SIZE is
> > much smaller than it expects (< 1024, not indicative of the real size
> > of the scoreboard).
> >
> > This patch should get things going again, but I wonder if anybody has
> > a better idea for seeding the random number generator, since this is
> > an unfortunate dependence on the memory allocation of the scoreboard.
>
> What about an ap_scoreboard_entropy fn in the core?
or just an entropy function? why should any module care that it is
from the scoreboard?
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [PATCH] get mod_ssl to work again
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Jeff Trawick" <tr...@attglobal.net>
Sent: Tuesday, December 18, 2001 7:55 AM
> mod_ssl has some questionable access to the scoreboard which doesn't
> work correctly starting a few minutes ago because SCOREBOARD_SIZE is
> much smaller than it expects (< 1024, not indicative of the real size
> of the scoreboard).
>
> This patch should get things going again, but I wonder if anybody has
> a better idea for seeding the random number generator, since this is
> an unfortunate dependence on the memory allocation of the scoreboard.
What about an ap_scoreboard_entropy fn in the core?
Bill