EKR wrote:
> SSL uses EXACTLY the same algorithm for RC4-40 as RC4-128. It
> simply expands the 40 bit key to a 128 bit key before feeding
> it to RC4. Thus, it's not any faster to use 40 bits. Actually
> it's very slightly slower because the expansion takes some
> time.

OK, makes sense.

> 
> Now, not all 56-bit modes are equally fast. RC4 in 56 mode
> (one of the experimental cipher suites)

All I am concerned with right now are what is supported by typical IE
and Netscape users, both US and non-US.
So then should I not be concerned with RC4 then because it is
experimental?

> is going to be much
> faster than DES-56. On the other hand 3DES (168 bit) is going
> to be 3 times as slow as DES.

Does the typical browser support 3DES? I thought 128 bit encryption was
it for the moment.

> 
> > > In the case of symmetric ciphers, RC4 is by far the fastest
> > > and it's no slower in 128 bit mode than 40 bit mode. Thus,
> > > I'd advise you to use RC4-128.
> >
> > OK, I followed the steps for a US installation which included RSA. Can I
> > still use RC4-128?
> Yes.
> 
> > Would the configuration be:
> > SLCipherSuite ALL:!ADH:RC4-RSA:-HIGH:-MEDIUM:+LOW:+SSLv2:+EXP
> > ??
> I doubt it.
> 
> What you want to do here is to use RC4-128 whenever possible but use
> RC4-40, DES, or 3DES (in that order) when necessary. Surely you don't
> want to not talk to clients just because they will only speak a slower
> cipher.

No, my thought is:
force the client to use the lowest, 'highest performance' encryption
they can
to insure the absolute lowest load level on the server.

> 
> I'm not sure enough about how OpenSSL negotiates to advise you on how
> to set this. It may not be possible to tell it what order to choose
> ciphers in. Sorry.
> 
> I'm fairly sure this is wrong, however, since you've turned off all
> the high security ciphers.
> 
> > Well, I have already created my key and received my cert from thawte for
> > www.datafree.com
> > I assume that I used the default settings which would be 1024??

> I think it is. Ralf?
> 
> > Bottom line, what is/are the setting(s) that will place the lowest
> > possible load on my server, assuming that I already have my certificate
> > (www.datafree.com)?
> I think youre overrating the effect of the symmetric cipher
> on server load. 

Could be, but doesn't SSL add quite a bit compared to non-SSL?

>Are you moving enormously large files? 

No.

>Do you know that load is a problem?

No, it is not yet. I am providing a free service with information that
can be *read* by guests, unencrypted via non-SSL. So encrypting the data
just doesn't matter.
Yet when users want to contribute or update their own information, they
must login.
Users may also be administrators, so I want pretty good security for the
login as well as the session.
I have designed this with secure cookies and it seems to work well.
BUT
I want to be prepared for extremely high traffic, and I know that
encryption is going to increase the load on the server. Therefore, I
want to force users to the encryption scheme that will incur the
smallest load on my servers, or at least that is what I thought.
Like I said, I don't really know much about SSL. The documentation at
modssl.org talks about forcing users to utilize the highest encryption,
yet it doesn't seem to talk about how to configure for the lowest server
load/processing hit.
I think I understand what you are saying, that much of what I am worried
about does not matter.
Yet I am still interested in finding out what the modssl settings would
be best for a situation that favors server performance over client
security. Right now my guess is:

SLCipherSuite ALL:!ADH:RC4+RSA:-HIGH:-MEDIUM:+LOW:+SSLv2:+EXP

I appreciate the response, it is providing me with a better
understanding of how SSL works.

Joe Junkin
[EMAIL PROTECTED]
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [EMAIL PROTECTED]
Automated List Manager                            [EMAIL PROTECTED]

Reply via email to