RE: SSL <-> mod_gzip <-> mod_perl = mod_proxy error

[Nigel Hamilton]

HI Adam,

Your speed vs time point is a good one. If the network is fast
then the time it takes the CPU to do the compression may negate any speed
benefits from compressing the message.

However, compression is generally worth it because:

* HTML compresses well - messages often compress by 80% or more. 
* Even though your network may be fast - the last mile over a 28.8 K 
modem can be slow - and compression helps here
* The CPU cost of calculating the compression can be avoiding by caching 
the compressed document in memory or on disk

On a side note ... I've had a tough time trying to get all the 
compression bits and pieces to work together.

I've tried mod_gzip and it worked well for non-SSL content ...  
however, it didn't work with SSL and the only workaround is proxying to a
second server ... and I couldn't get this to work with mod_perl. :-(

I then looked at mod_deflate but unfortunately this involved 
re-compiling the Apache source and applying patches etc.

Recently I've installed Apache:DynaGzip ... which installed no 
problem. 

Apache::DynaGzip, is supposed to work with SSL and can handle 
chunked dynamic output  which is what I'm looking for - I haven't set 
this up yet but will report my experiences back to the list.


NIgel



> I feel like most of my responses on this list ask 'why' rather than
> answer a question but:
> 
> Assuming you have an internet connection between 1 Mb and 10 Mb
> 
> You're internal network is running at 100Mb with 1Gb around the corner
> or already going.
> 
> Why bother compressing stuff when it seems clear that processing power
> is more of a bottleneck than bandwidth (because in the end, compression
> is always a tradeoff between computation and the quantity of information
> coming to/going out of your machine).
> 
> I would have to imagine that compression would only speed up the actual
> response time if the external connection is >25% (just a guess) of the
> internal speed limit.  So, in a typical 100Mb internal network, I
> wouldn't worry about compression unless I could actually deliver 25Mb to
> the end-user.  Of course, if we're paying for more than a 25Mb
> (10k/month?) connection to the internet, than the cost of a 1Gb network
> is nominal.
> 
> All this is moot if the app serves a lan, but still, I think the
> gzipping would simply make the application more sluggish rather than
> speed it up (I concede that I have not done any benchmarks) since
> internal network bandwidth is so cheap.
> 
> Adam
> 
> 
> -Original Message-
> From: Nigel Hamilton [mailto:nigel@;turbo10.com] 
> Sent: Friday, October 18, 2002 10:47 PM
> To: [EMAIL PROTECTED]
> Subject: SSL <-> mod_gzip <-> mod_perl = mod_proxy error
> 
> 
> Hi,
>   
>   I'm trying to hand all SSL requests to a backend mod_perl server
> 
> with mod_gzip installed for compression.
> 
>   This means that SSL content is pre-compressed by the backend 
> server before being encrypted by the frontend (Mini How To - below).
> 
>   Apparently mod_gzip and SSL on the same server will not work - 
> this is why I need to pass the request to a proxy to handle the
> compression.
>   
>   So ... a request on https://turbo10.com:446/index.html (server
> A)  
> passes to http://turbo10.com:44300/index.html (server B).
> 
>   The file is compressed by server B and passed back to server A
> for 
> encryption and tranmission to the client.
> 
>   This works fine for static files.
> 
>    BUT 
> 
>   Mod_perl scripts seem to fail: 
> 
>   https://turbo10.com:446/cgi-bin/splashpage1.cgi
> 
>   The log reports:
>   
> [Mon Oct 14 21:33:25 2002] [error] 
> proxy:http://turbo10.com:44300/cgi-bin/splashpage1.cgi not found or
> unable 
> to stat 
> 
>   However, when I access the proxy directly, the mod_perl script
> works fine (no access restrictions just yet):
>   
>   http://turbo10.com:44300/cgi-bin/splashpage1.cgi
>   
>   Any ideas? Is there some weird interaction between mod_perl + 
> mod_proxy?
>   
>   Even better ...  is there a way to do SSL compression in
> mod_perl
> with only one server?
> 
>   Any help would be much appreciated.
> 
> NIgel 
>   
> 
> MOD_GZIP WITH SSL MINI HOWTO
> 
> Version 0.2 February 23, 2002
> Tim Behrendsen
> This document is released into the public domain.
> 
> INTRODUCTION
> 
> This document describes how to run mod_gzip over SSL connections using
> mod_ssl. The method described has been tested with Apache 1.3.22 under
> RedHat 7.2 (Kernel 2.4.13), mod_gzip 1.3.19.1a, mod_ssl 2.8.5 and
> OpenSSL
> 0.9.6b.
> 
> THE PROBLEM
> 
> One would expect to be able to just plug in mod_gzip into Apache in the
> normal way, and have it work with SSL. Unfortunately, due to technical
> issues with mod_ssl beyond the scope of this document (apparently
> mod_ssl
> greedily grabs the result before anyone else has a 

Re: SSL <-> mod_gzip <-> mod_perl = mod_proxy error

[Tom Hukins]

On Mon, Oct 21, 2002 at 08:11:16AM -0500, Nigel Hamilton wrote:
> 
> * Even though your network may be fast - the last mile over a 28.8 K 
> modem can be slow - and compression helps here

Most modems use compression protocols such as V.42bis.  You don't gain
much, if anything, from compressing data sent through such devices, or
from using other techniques such as stripping redundant whitespace
from HTML.

In my experience, most ISDN connections don't use link level
compression - techniques such as mod_gzip have some merit in this
case.

Tom

RE: SSL <-> mod_gzip <-> mod_perl = mod_proxy error

[Adam Nelson]

I feel like most of my responses on this list ask 'why' rather than
answer a question but:

Assuming you have an internet connection between 1 Mb and 10 Mb

You're internal network is running at 100Mb with 1Gb around the corner
or already going.

Why bother compressing stuff when it seems clear that processing power
is more of a bottleneck than bandwidth (because in the end, compression
is always a tradeoff between computation and the quantity of information
coming to/going out of your machine).

I would have to imagine that compression would only speed up the actual
response time if the external connection is >25% (just a guess) of the
internal speed limit.  So, in a typical 100Mb internal network, I
wouldn't worry about compression unless I could actually deliver 25Mb to
the end-user.  Of course, if we're paying for more than a 25Mb
(10k/month?) connection to the internet, than the cost of a 1Gb network
is nominal.

All this is moot if the app serves a lan, but still, I think the
gzipping would simply make the application more sluggish rather than
speed it up (I concede that I have not done any benchmarks) since
internal network bandwidth is so cheap.

Adam


-Original Message-
From: Nigel Hamilton [mailto:nigel@;turbo10.com] 
Sent: Friday, October 18, 2002 10:47 PM
To: [EMAIL PROTECTED]
Subject: SSL <-> mod_gzip <-> mod_perl = mod_proxy error


Hi,

I'm trying to hand all SSL requests to a backend mod_perl server

with mod_gzip installed for compression.

This means that SSL content is pre-compressed by the backend 
server before being encrypted by the frontend (Mini How To - below).

Apparently mod_gzip and SSL on the same server will not work - 
this is why I need to pass the request to a proxy to handle the
compression.

So ... a request on https://turbo10.com:446/index.html (server
A)  
passes to http://turbo10.com:44300/index.html (server B).

The file is compressed by server B and passed back to server A
for 
encryption and tranmission to the client.

This works fine for static files.

 BUT 

Mod_perl scripts seem to fail: 

https://turbo10.com:446/cgi-bin/splashpage1.cgi

The log reports:

[Mon Oct 14 21:33:25 2002] [error] 
proxy:http://turbo10.com:44300/cgi-bin/splashpage1.cgi not found or
unable 
to stat 

However, when I access the proxy directly, the mod_perl script
works fine (no access restrictions just yet):

http://turbo10.com:44300/cgi-bin/splashpage1.cgi

Any ideas? Is there some weird interaction between mod_perl + 
mod_proxy?

Even better ...  is there a way to do SSL compression in
mod_perl
with only one server?

Any help would be much appreciated.

NIgel 


MOD_GZIP WITH SSL MINI HOWTO

Version 0.2 February 23, 2002
Tim Behrendsen
This document is released into the public domain.

INTRODUCTION

This document describes how to run mod_gzip over SSL connections using
mod_ssl. The method described has been tested with Apache 1.3.22 under
RedHat 7.2 (Kernel 2.4.13), mod_gzip 1.3.19.1a, mod_ssl 2.8.5 and
OpenSSL
0.9.6b.

THE PROBLEM

One would expect to be able to just plug in mod_gzip into Apache in the
normal way, and have it work with SSL. Unfortunately, due to technical
issues with mod_ssl beyond the scope of this document (apparently
mod_ssl
greedily grabs the result before anyone else has a chance), the easy
solution doesn't work.

There are workarounds, however, that give the desired result.

THE SOLUTION

A workaround solution is to use mod_proxy. A front-end SSL-enabled
Virtual
Host receives the request, and then uses mod_proxy to pass the result to
a
back-end non-SSL virtual host that processes the request, compresses the
content and passes it back. The front-end then happily forwards the data
through the SSL connection.

CONFIGURATION

Install and test mod_gzip. Insallation information and sample
configuration
may be found on the home page of mod_gzip at
http://www.remotecommunications.com/apache/mod_gzip. It's recommended to
get
mod_gzip completely working before adding SSL.

After installing mod_gzip, enable mod_proxy in the configuration file by
adding or uncommenting the following lines to the appropriate areas
(near
directives of the same form would be a good place). Note that the
mod_gzip
module needs to be the last one in the chain, so activate these before
the
mod_gzip module.

LoadModule proxy_module modules/libproxy.so

AddModule mod_proxy.c

Some mod_gzip configurations apparently need the following line. Add it
to
your "item_include" sections:

mod_gzip_item_include handler ^proxy-server$

Add the following lines to your SSL VirtualHost:

ProxyRequests On
ProxyPass / http://localhost:44300/
ProxyPassReverse / http://localhost:44300/
mod_gzip_on No

This directs mod_proxy to send all requests to a back-end virtual host
on
port 44300. Note tha

Re: SSL <-> mod_gzip <-> mod_perl = mod_proxy error

[Igor Sysoev]

On Fri, 18 Oct 2002, Nigel Hamilton wrote:

>Even better ...  is there a way to do SSL compression in mod_perl
>with only one server?

mod_deflate. http://sysoev.ru/mod_deflate/mod_deflate-1.0.15.tar.gz
Documentation is in Russian only but feel free to ask me directly.
There is also Babelfish translation at:
http://pflanze.mine.nu/~chris/mod_deflate/mod_deflate_readme_EN.html

mod_deflate compresses any module output (except pre-1.3.24 mod_proxy,
however I did not test it with 1.3.24+ mod_proxy).
It works with mod_ssl correctly.

>ProxyRequests On

This directive is not needed for reverse proxying.
It makes yet another public proxy.


Igor Sysoev
http://sysoev.ru

Re: SSL <-> mod_gzip <-> mod_perl = mod_proxy error

[Thomas Eibner]

On Fri, Oct 18, 2002 at 09:46:38PM -0500, Nigel Hamilton wrote:
> Hi,
>   
>   I'm trying to hand all SSL requests to a backend mod_perl server 
> with mod_gzip installed for compression.
> 
>   This means that SSL content is pre-compressed by the backend 
> server before being encrypted by the frontend (Mini How To - below).
> 
>   Apparently mod_gzip and SSL on the same server will not work - 
> this is why I need to pass the request to a proxy to handle the compression.
>   
>   So ... a request on https://turbo10.com:446/index.html (server A)  
> passes to http://turbo10.com:44300/index.html (server B).
> 
>   The file is compressed by server B and passed back to server A for 
> encryption and tranmission to the client.
> 
>   This works fine for static files.
> 
>    BUT 
> 
>   Mod_perl scripts seem to fail: 
> 
>   https://turbo10.com:446/cgi-bin/splashpage1.cgi
> 
>   The log reports:
>   
> [Mon Oct 14 21:33:25 2002] [error] 
> proxy:http://turbo10.com:44300/cgi-bin/splashpage1.cgi not found or unable 
> to stat 

Something tells me that the proxy isn't handling this, have you double
checked that the proxy server is actually sending the request to the
mod_gzip enabled server?

-- 
  Thomas Eibner  DnsZone 
  mod_pointer  
  !(C)  
  Putting the HEST in .COM 

Re: SSL Installation Questions - Help

[Andrew Ho]

Hello,

LDM>Having to compile, install, integrate everything yourself is a huge
LDM>waste of time. Your are duplicating all the efforts put in by the
LDM>distributions, for zero added value.

Huh? Having control over what modules go into your Apache, plus having one
compiled on your machine for your version, is zero added value?

I think most people on this list would disagree with you. Most of us who
depend on Apache build our own for one reason or another. You can
generally make an Apache that fulfills your needs and no more which
consumes less memory and has less dependencies than a prebuilt binary from
somewhere. And being tied to a vendor release schedule probably qualifies
as far more of an "upgrade nightmare" than having to occasionally pull out
the text file where you put your build procedure.

Humbly,

Andrew

--
Andrew Ho   http://www.tellme.com/   [EMAIL PROTECTED]
Engineer   [EMAIL PROTECTED]  Voice 650-930-9062
Tellme Networks, Inc.   1-800-555-TELLFax 650-930-9101
--

Re: SSL Installation Questions - Help

[Michael Robinton]

> On Sat, Mar 09, 2002 at 10:12:32AM -0800, Kirk Rogers wrote:
> > Hi all,
> > So I went ahead and tried to install apache-ssl and am following the
> > instructions to the T.
> >
> > I've acquired:
> > mod_perl-1.26.tar.gz
> > openssl-0.9.6c.tar.gz
> > apache_1.3.22.tar.gz
> > apache_1.3.22+ssl_1.47.tar.gz
>
> Man this is terrible.
>
> Having to compile, install, integrate everything yourself is a huge
> waste of time. Your are duplicating all the efforts put in by the
> distributions, for zero added value. Plus you've got an upgrade
> nightmare waiting for you.
>

It is quite easy actually.

do it this way

build and install open_ssl

untar apache in /usr/src
ln -s apache_version apache

cp  apache_1.3.22+ssl_1.47.tar.gz into the apache directory
untar apache_1.3.22+ssl_1.47.tar.gz
run ./FixPatch

If you wish to use mod_so or any of the other non-standard modules
rm src/Configuration
rm src/Configuration.apaci

edit src/Configuration.tmpl  as required
i.e. for mod_rewrite, mod_so, etc

--
untar mod_perl distribution
in the mod perl source directory, ...
perl Makefile.PL \
APACHE_SRC=/usr/src/apache/src \
DO_HTTPD=1 \
USE_APACI=1 \
PREP_HTTPD=1 \
EVERYTHING=1 \

make
make test   # broken
make install

in apache directory
./configure --with-layout=Apache \
--activate-module=src/modules/perl/libperl.a
make
make install

Re: SSL Installation Questions - Help

[Louis-David Mitterrand]

On Sat, Mar 09, 2002 at 10:12:32AM -0800, Kirk Rogers wrote:
> Hi all,
> So I went ahead and tried to install apache-ssl and am following the
> instructions to the T.
> 
> I've acquired:
> mod_perl-1.26.tar.gz
> openssl-0.9.6c.tar.gz
> apache_1.3.22.tar.gz
> apache_1.3.22+ssl_1.47.tar.gz

Man this is terrible.

Having to compile, install, integrate everything yourself is a huge
waste of time. Your are duplicating all the efforts put in by the
distributions, for zero added value. Plus you've got an upgrade
nightmare waiting for you.

-- 
THESEE: Vous deviez le rendre moins volage ;
Comment souffriez-vous cet horrible partage ?
  (Phèdre, J-B Racine, acte 5, scène 3)

Re: SSL Installation Questions - Help

[Ged Haywood]

Hi there,

On Sat, 9 Mar 2002, Kirk Rogers wrote:

> I've acquired:
> mod_perl-1.26.tar.gz
> openssl-0.9.6c.tar.gz
> apache_1.3.22.tar.gz
> apache_1.3.22+ssl_1.47.tar.gz

I use mod_ssl with no problems, you could try that.

73,
Ged.

Re: SSL and thin/fat server setups.

[Gunther Birznieks]

At 02:07 PM 6/29/2001 -0500, Christopher L. Everett wrote:
>Hello all,
>
>I've been running apache+mod_perl servers with apache+mod_ssl
>front-ends, and been quite happy with this type of setup for
>quite some time.
>
>Now I need to use SSL certificates for authenticating users
>of an online database.  It seems like there's no way to get
>the SSL information that the front-end sees to the back-end
>server because the SSL protocol underlies the HTTP protocol
>(outside of writing a custom apache module, and passing back
>the cert info in headers) and there's no such thing as an SSL
>proxy module that I've been able to find.
>
>Right now, I'm considering setting up a very lightweight
>apache+mod_perl+ssl+mod_proxy frontend with just a single
>perl auth/authz handler installed, and have that decrypt,
>authenticate, authorize, and proxy all SSL requests back
>to the fat server.  Then I revert the apache+mod_ssl front
>end to a vanilla apache server and have it handle all
>plain HTTP requests.

>Before I do this, I'd just like to know if anyone has any
>other ideas on how to do this.

Read Mads post. We use a similar method of accomplishing this in our own work.

You can't use mod_proxy to proxy the SSL connection to the back-end server 
because as soon as you've established the SSL connection from the front-end 
proxy to the browser, you can't carry the certificate through to the 
back-end server even if you establish a second SSL connection.

You can only satisfy the SSL challenge response mechanisms through having 
the browser's private key which the reverse proxy does not have.

Later,
Gunther

Re: SSL and thin/fat server setups.

[Mads Toftum]

On Fri, Jun 29, 2001 at 02:07:50PM -0500, Christopher L. Everett wrote:
> Hello all,
> 
> I've been running apache+mod_perl servers with apache+mod_ssl
> front-ends, and been quite happy with this type of setup for 
> quite some time.
> 
> Now I need to use SSL certificates for authenticating users 
> of an online database.  It seems like there's no way to get 
> the SSL information that the front-end sees to the back-end
> server because the SSL protocol underlies the HTTP protocol
> (outside of writing a custom apache module, and passing back 
> the cert info in headers) and there's no such thing as an SSL 
> proxy module that I've been able to find.
> 
I did make a module like that last year - it is available from
http://www2.toftum.dk/apache/

vh

Mads Toftum
-- 
`Darn it, who spiked my coffee with water?!' - lwall

Re: ssl encryption

[Fabrice Scemama]

Yes, it's possible. To achieve this, you should use asymetric
encryption, and *not* store the private key in the server.
Then, the question remains : how can I have the server safely
decrypt on demand ?! one possible solution could be to store
the private key in a remote server, dedicated to the unique
task of decrypting the sensitive data. A secure tunnel could be
established between the two servers, so to communicate the
encrypted text, and get back the decrypted text safely.

You could even add security by storing the private key in a
smartcard, and having the smartcard reader connected to the
server. Decryptions would have to be done within the smartcard.
It's completely possible, but you almost certainly don't want such
CPU-expensive operations be done within a 8-bit smartcard !

On Thu, 14 Jun 2001, Kevin Schroeder wrote:

> This would make an interesting discussion because I've had the same question
> come up in my mind.  How do you encrypt things on your server without giving
> out the passphrase?  Is it even possible to keep the key in the same
> location as the program using it and still maintain security?
> 
> Kevin

Re: ssl encryption

[Kevin Schroeder]

Then the question comes up of what happens if you're not storing it in a
database?  Say, for example, every night at midnight there's a report that
gets taken from the database and emailed to a manager in an Excel
spreadsheet that contains all the purchasing information from the previous
day.  Plus, most people concur that there is no such thing as a 100% secure
system, however, using a 2048 bit GPG asynchronous key would make it quite
difficult to get that information, even if the server was broken into and
all the root passwords were changed.  Then, of course, the intruder could
change the passkey for the encryption and send the reports to himself.
Then, of course you could modify "su" to report whenever someone uses it to
su to root, but that's only valid if they get in with su.  But then we're
getting beyond the scope of this mailing list.  I guess there really is no
such thing as absolute security, only probable security.  Oh well.

Kevin

- Original Message -
From: "Vivek Khera" <[EMAIL PROTECTED]>
Newsgroups: ml.apache.modperl
To: <[EMAIL PROTECTED]>
Sent: Friday, June 15, 2001 2:23 PM
Subject: Re: ssl encryption


> >>>>> "KS" == Kevin Schroeder <[EMAIL PROTECTED]> writes:
>
> KS> This would make an interesting discussion because I've had the
> KS> same question come up in my mind.  How do you encrypt things on
> KS> your server without giving out the passphrase?  Is it even
> KS> possible to keep the key in the same location as the program using
> KS> it and still maintain security?
>
> No; the only way to secure this would be to make the server ask you to
> type the passphrase on startup, and you never write this down.  This
> makes it impossible to have automated restart, of course.
>
> Better thing to do is to secure your database server a bit better.
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Vivek Khera, Ph.D.Khera Communications, Inc.
> Internet: [EMAIL PROTECTED]   Rockville, MD   +1-240-453-8497
> AIM: vivekkhera Y!: vivek_khera   http://www.khera.org/~vivek/
>

Re: ssl encryption

[Vivek Khera]

> "KS" == Kevin Schroeder <[EMAIL PROTECTED]> writes:

KS> This would make an interesting discussion because I've had the
KS> same question come up in my mind.  How do you encrypt things on
KS> your server without giving out the passphrase?  Is it even
KS> possible to keep the key in the same location as the program using
KS> it and still maintain security?

No; the only way to secure this would be to make the server ask you to
type the passphrase on startup, and you never write this down.  This
makes it impossible to have automated restart, of course.

Better thing to do is to secure your database server a bit better.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D.Khera Communications, Inc.
Internet: [EMAIL PROTECTED]   Rockville, MD   +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera   http://www.khera.org/~vivek/

Re: ssl encryption

[Martin Redington]

One solution is to set a perl variable in a conf file that is only 
readable by root. The parent httpd process can read this, and the 
children can inherit it, but its not visible in the code.

If your httpd children need to be able to read in the password, then 
you'll need less restrictive permissions on the password file.

Of course you need to be able to trust your application developers not 
to dump the variable out into the world.

A slightly better method is to abstract away from the connection method, 
so that your application developers don't use the password directly, but 
call a library routine that hands them a connection object, using the 
password variable under the hood.

I've seen this used, and it worked quite well, although having the 
password in plain text anywhere is a little disturbing.

A slightly better approach would be to keep a file of blowfish encrypted 
keys to be read during startup, and to somehow pass the key to decrypt 
the keys in manually during Apache startup, via a prompt. Stronghold 
does this at startup, in order to get the passphrase for your 
certificate. I'm not sure exactly how to do this from scratch, but I 
believe there are modules that allow you to embed perl in conf files, 
which might work, or you might be able to do it via startup.pl



On Friday, June 15, 2001, at 12:44  am, Kevin Schroeder wrote:

> This would make an interesting discussion because I've had the same 
> question
> come up in my mind.  How do you encrypt things on your server without 
> giving
> out the passphrase?  Is it even possible to keep the key in the same
> location as the program using it and still maintain security?
>
> Kevin
>
> - Original Message -
> From: "Benjamin Trott" <[EMAIL PROTECTED]>
> To: "modperl" <[EMAIL PROTECTED]>
> Sent: Thursday, June 14, 2001 5:00 PM
> Subject: Re: ssl encryption
>
>
>>> When apache is serving a ssl connection, I assume that everything
>>> sent back and forth between the server and the client is encrypted.
>>> I want an mod_perl script to encrypt/decrypt credit card numbers
>>> obtained over the ssl connection for storage in a db on the server.
>>> Is there any access to the same routines that apache is using for the
>>> encryption or do I have to use some other module.  If I have to use
>>> another module, what would be a good choice?
>>
>> You could use either an asymmetric cipher or a symmetric cipher.
>>
>> An example of the former is Crypt::RSA (Crypt::DSA is another, but DSA 
>> is
>> used only for signing/verification, not for encryption/decryption).
>>
>> A good, fast example of the latter is Crypt::Blowfish. Used together 
>> with
>> Crypt::CBC, you get Blowfish in CBC mode:
>>
>> use Crypt::CBC;
>> my $cipher = Crypt::CBC->new('passphrase', 'Blowfish');
>> my $ciphertext = $cipher->encrypt('data');
>> my $plaintext = $cipher->decrypt($ciphertext);
>>
>> In other words, you use the same passphrase to both encrypt and decrypt
> the
>> data (ie. symmetric).
>>
>> Personally, I think I'd use a symmetric cipher, but the thing you have 
>> to
> be
>> careful of is leaving your passphrase around in plain text (eg. in a
>> script). Doing this negates many of the benefits of encrypting the 
>> data in
>> the first place. :) Sadly I'm not sure of the best answer to this 
>> dilemma.
>>
>> bye,
>> Ben
>>
>>
>
>

Re: ssl encryption

[Kevin Schroeder]

This would make an interesting discussion because I've had the same question
come up in my mind.  How do you encrypt things on your server without giving
out the passphrase?  Is it even possible to keep the key in the same
location as the program using it and still maintain security?

Kevin

- Original Message -
From: "Benjamin Trott" <[EMAIL PROTECTED]>
To: "modperl" <[EMAIL PROTECTED]>
Sent: Thursday, June 14, 2001 5:00 PM
Subject: Re: ssl encryption


> > When apache is serving a ssl connection, I assume that everything
> > sent back and forth between the server and the client is encrypted.
> > I want an mod_perl script to encrypt/decrypt credit card numbers
> > obtained over the ssl connection for storage in a db on the server.
> > Is there any access to the same routines that apache is using for the
> > encryption or do I have to use some other module.  If I have to use
> > another module, what would be a good choice?
>
> You could use either an asymmetric cipher or a symmetric cipher.
>
> An example of the former is Crypt::RSA (Crypt::DSA is another, but DSA is
> used only for signing/verification, not for encryption/decryption).
>
> A good, fast example of the latter is Crypt::Blowfish. Used together with
> Crypt::CBC, you get Blowfish in CBC mode:
>
> use Crypt::CBC;
> my $cipher = Crypt::CBC->new('passphrase', 'Blowfish');
> my $ciphertext = $cipher->encrypt('data');
> my $plaintext = $cipher->decrypt($ciphertext);
>
> In other words, you use the same passphrase to both encrypt and decrypt
the
> data (ie. symmetric).
>
> Personally, I think I'd use a symmetric cipher, but the thing you have to
be
> careful of is leaving your passphrase around in plain text (eg. in a
> script). Doing this negates many of the benefits of encrypting the data in
> the first place. :) Sadly I'm not sure of the best answer to this dilemma.
>
> bye,
> Ben
>
>

Re: ssl encryption

[Martin Redington]

Not storing the credit card numbers at all would be the best option :-)

If you must, we've usually used crypt for one-way encryption, or 
Crypt::BlowFish for stuff we need to be able to decrypt (look after your 
key!).

On Thursday, June 14, 2001, at 09:54  pm, Tim Gardner wrote:

> When apache is serving a ssl connection, I assume that everything sent 
> back and forth between the server and the client is encrypted. I want 
> an mod_perl script to encrypt/decrypt credit card numbers obtained over 
> the ssl connection for storage in a db on the server. Is there any 
> access to the same routines that apache is using for the encryption or 
> do I have to use some other module.  If I have to use another module, 
> what would be a good choice?
>
> Thanks,
> Tim
>

Re: ssl encryption

[Benjamin Trott]

> When apache is serving a ssl connection, I assume that everything
> sent back and forth between the server and the client is encrypted.
> I want an mod_perl script to encrypt/decrypt credit card numbers
> obtained over the ssl connection for storage in a db on the server.
> Is there any access to the same routines that apache is using for the
> encryption or do I have to use some other module.  If I have to use
> another module, what would be a good choice?

You could use either an asymmetric cipher or a symmetric cipher.

An example of the former is Crypt::RSA (Crypt::DSA is another, but DSA is
used only for signing/verification, not for encryption/decryption).

A good, fast example of the latter is Crypt::Blowfish. Used together with
Crypt::CBC, you get Blowfish in CBC mode:

use Crypt::CBC;
my $cipher = Crypt::CBC->new('passphrase', 'Blowfish');
my $ciphertext = $cipher->encrypt('data');
my $plaintext = $cipher->decrypt($ciphertext);

In other words, you use the same passphrase to both encrypt and decrypt the
data (ie. symmetric).

Personally, I think I'd use a symmetric cipher, but the thing you have to be
careful of is leaving your passphrase around in plain text (eg. in a
script). Doing this negates many of the benefits of encrypting the data in
the first place. :) Sadly I'm not sure of the best answer to this dilemma.

bye,
Ben

Re: ssl encryption

[Mark Madsen]

Apache uses OpenSSL to implement the transport encryption for HTTP
connections.  You can find out more at http://www.openssl.org

This isn't necessarily how you would want to encrypt things on disk, however.
Encrypting a regular file or db file is not really a typical public key
encryption task -- typically this is done by using a block cipher like
Blowfish and a single shared secret.  Information is available at:
http://www.counterpane.com/blowfish.html, and there are perl modules on CPAN
as Crypt::Blowfish.

Hope this helps.


> When apache is serving a ssl connection, I assume that everything
> sent back and forth between the server and the client is encrypted.
> I want an mod_perl script to encrypt/decrypt credit card numbers
> obtained over the ssl connection for storage in a db on the server.
> Is there any access to the same routines that apache is using for the
> encryption or do I have to use some other module.  If I have to use
> another module, what would be a good choice?
>
> Thanks,
> Tim
>

---
Mark Madsen   EMAIL: [EMAIL PROTECTED]
Internap Network ServicesOFFICE: 206.441.8800
601 Union Street, Suite 1000FAX: 206.264.1833
Seattle, WA  98101PAGER: 888.464.6381

* The contents of this message are proprietary and confidential *

Re: ssl advice? modssl vs. apache-ssl vs. ?

[G.W. Haywood]

Hi there,

On Sat, 14 Apr 2001, Wim Kerkhoff wrote:

> > Apache-1.3.19
> > mod_ssl-2.8.1-1.3.19
> > mod_perl-1.25 (DSO!)
> > openssl-0.9.4
> > Linux_2.2.16
> > glibc 2.1.3 (*important*)
> 
> Why is using glibc 2.1.3 important? It works fine for me with glibc
> 2.2.2.  I'm using the latest versions of openssl (0.9.6) and the Linux
> kernel (2.4.x) as well. I'm using Debian, things may differ on other
> (I'll leave it at that ;) distributions and operating systems.

You need glibc 2.1 or later for full functionality, see the docs. if
you're worried.  You shouldn't be.  Note that there are problems with
56-bit export versions of MSIE5.x and versions of openssl later than
0.9.4, which is why I haven't upgraded to 0.9.6.  That's mentioned in
the docs for mod_ssl.  Worry.

73,
Ged.

Re: ssl advice? modssl vs. apache-ssl vs. ?

[iain truskett]

* Michael Robinton ([EMAIL PROTECTED]) [14 Apr 2001 17:23]:
> > I've just taken a quick look at the modssl site and the apache-ssl
> > site. Does anyone want to comment on the pros and cons of these 2
> > approaches?
> >
> > Can mod_perl co-exist with either or both of these?
[...]
> Don't know anything about modssl, I've been using apache-ssl +
> mod_perl for several years and am quite happy with the results.

Apache/1.3.19 (Unix) PHP/4.0.4pl1 mod_perl/1.25 mod_ssl/2.8.1 OpenSSL/0.9.6

Been happily working with various versions for the past year on the
above machine and another one. mod_perl happily coexists with mod_ssl.

Simple to install, simple to use.


cheers,
-- 
iain.  
Be nice to your kids They will pick out your nursing home.

Re: ssl advice? modssl vs. apache-ssl vs. ?

[Michael Robinton]

> I've just taken a quick look at the modssl site and the apache-ssl site.
> Does anyone want to comment on the pros and cons of these 2 approaches?
> 
> Can mod_perl co-exist with either or both of these?
> 
> All responses welcome, including "don't do it, go back, save yourself!".
> 
Don't know anything about modssl, I've been using apache-ssl + mod_perl 
for several years and am quite happy with the results. 

Currently up to: on 2 production and 1 development system 
apache_1.3.14
apache-ssl_1.42.
mod_perl-1.24_01
openssl-0.9.6


Hope this helps
Mod_perl development & telecommuting available
Michael

Re: ssl advice? modssl vs. apache-ssl vs. ?

[Wim Kerkhoff]

"G.W. Haywood" wrote:
> 
> Hi there,
> 
> On Fri, 13 Apr 2001, Fred Toth wrote:
> 
> > I've just taken a quick look at the modssl site and the apache-ssl site.
> > Does anyone want to comment on the pros and cons of these 2 approaches?
> 
> Recently I installed mod_ssl for the first time and although it took
> several attempts to get things done in the right order (and by the
> right user:) there were no real difficulties.  Haven't used apache-ssl
> so I can't comment on the relative merits, but if you read the mod_ssl
> docs the decision seems to be easy.

Yea, took me a while to the first couple of times, especially when
trying to create your own certificate or figure out how to obtain and
use a real certificate.
 
> Apache-1.3.19
> mod_ssl-2.8.1-1.3.19
> mod_perl-1.25 (DSO!)
> openssl-0.9.4
> Linux_2.2.16
> glibc 2.1.3 (*important*)

Why is using glibc 2.1.3 important? It works fine for me with glibc
2.2.2.  I'm using the latest versions of openssl (0.9.6) and the Linux
kernel (2.4.x) as well. I'm using Debian, things may differ on other
(I'll leave it at that ;) distributions and operating systems.

The modperl guide (perl.apache.org/guide) has sections on SSL servers as
well.  You can basically copy and paste the commands from there, I have
done that.

As for apache-ssl, sorry, I have no clue on that.  I have tried using
the debian package called 'apache-ssl', but had horrible luck with
that.  I prefer to 'roll my own' apache/mod_ssl/mod_perl mixes anyways
though.

-- 

Regards,

Wim Kerkhoff

Re: ssl advice? modssl vs. apache-ssl vs. ?

[G.W. Haywood]

Hi there,

On Fri, 13 Apr 2001, Fred Toth wrote:

> I've just taken a quick look at the modssl site and the apache-ssl site.
> Does anyone want to comment on the pros and cons of these 2 approaches?

Recently I installed mod_ssl for the first time and although it took
several attempts to get things done in the right order (and by the
right user:) there were no real difficulties.  Haven't used apache-ssl
so I can't comment on the relative merits, but if you read the mod_ssl
docs the decision seems to be easy.

Apache-1.3.19
mod_ssl-2.8.1-1.3.19
mod_perl-1.25 (DSO!)
openssl-0.9.4
Linux_2.2.16
glibc 2.1.3 (*important*)

HTH.

73,
Ged.

Re: SSL / Apache / .vtml

[brian d foy]

On Fri, 15 Dec 2000, Mike Buglioli wrote:

> Do you think it's because they are generating dynamic .vtml pages which could
> be causing them some problems ? mlb

i don't knwo what they have done.  i doubt that it is either an SSL,
database, or mime-type problem.  in my experience, and i've done some
fairly wierd stuff, it didn't matter to my application if it was happening
over SSL. whether SSL was used or not didn't affect anything and i could
turn it off or on without a problem.

it sounds like a design problem, although i wouldn't rule out a lack of
documentation reading either.
 
> brian d foy wrote:
> 
> > On Thu, 14 Dec 2000, Mike Buglioli wrote:
> >
> > > I got this message from a vendor as to why they couldn't do SSL on their
> > > site...or that they couldn't, what does Apache say ?
> >
> > > Utilizing SSL with Apache is indeed a very simple modification to Apache
> > > when there is not database parsing happening in the same process.
> >
> > both of those work fine together. perhaps they are having other issues.
> >
> > --
> > brian d foy  <[EMAIL PROTECTED]>
> > Director of Technology, Smith Renaud, Inc.
> > 875 Avenue of the Americas, 2510, New York, NY  10001
> > V: (212) 239-8985
> 

--
brian d foy  <[EMAIL PROTECTED]>
Director of Technology, Smith Renaud, Inc.
875 Avenue of the Americas, 2510, New York, NY  10001
V: (212) 239-8985

Re: SSL / Apache / .vtml

[Vivek Khera]

> "MB" == Mike Buglioli <[EMAIL PROTECTED]> writes:

MB> Utilizing SSL with Apache is indeed a very simple modification to Apache

true.

MB> when there is not database parsing happening in the same process.

no need for this qualifier.  SSL and mod_perl are orthogonal
technologies; the only interaction is that both require more CPU than
static non-ssl pages do.

basically, they're either 1) lazy, 2) incompetent, 3) ignorant, or 4)
all of the above.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D.Khera Communications, Inc.
Internet: [EMAIL PROTECTED]   Rockville, MD   +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera   http://www.khera.org/~vivek/

Re: ssl

[Rob Tanner]

Can't recommend one over the other since I have only used mod_ssl.  But I can tell you 
that I've been pleased with it and found it easy to install and configure. Also, I 
believe (but not 100% sure) that mod_ssl is the ssl piece for the commercial 
Stronghold server.  But at the same time, I would think that if there were any serious 
drawbacks to one or the other, it would be pretty much common knowledge.  So what it 
really comes down to is examine their respective WEB pages and the package 
documentation and see which one appears to better suite exactly what your looking for, 
and then install that one.

-- Rob


--On Friday, December 08, 2000 05:12:43 PM -0500 cbell <[EMAIL PROTECTED]> wrote:

> Hi everyone, does anyone have any suggestions as to which SSL package to
> use?  I'm a little unsure if I should use Mod_ssl or Apache-ssl.  I'm
> currently using Apache 1.3.12 if that helps...
>
> Thanks alot!!!
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>




   _ _ _ _   __ _ _ _ _
  /\_\_\_\_\/\_\ /\_\_\_\_\_\
 /\/_/_/_/_/   /\/_/ \/_/_/_/_/_/  QUIDQUID LATINE DICTUM SIT,
/\/_/__\/_/ __/\/_//\/_/  PROFUNDUM VIDITUR
   /\/_/_/_/_/ /\_\  /\/_//\/_/
  /\/_/ \/_/  /\/_/_/\/_//\/_/ (Whatever is said in Latin
  \/_/  \/_/  \/_/_/_/_/ \/_/  appears profound)

  Rob Tanner
  McMinnville, Oregon
  [EMAIL PROTECTED]

 PGP signature

Re: SSL/encryption & mod_perl

[Adi]

"B. Burke" wrote:
> 
> I've got a question related to encryption and mod_perl.  I'm running
> an apache mod_perl server (AIX and Linux platforms) to serve HTML
> forms, query backend databases, and print formatted results.  I currently
> use .htaccess for authentication, although this will probably change.
> 
> My problem is that the user/pass info. and much of the data is
> sensitive, and I'm looking for a way to implement SSL or encryption.
> 
> If anyone can point me in the right direction for implementing
> encryption that is compatible with apache/mod_perl, I'd appreciate
> it.

Use RSE's excellent open-source SSL software.

http://www.modssl.org/
http://www.openssl.org/

RE: SSL/encryption & mod_perl

[Paul G. Weiss]

You can now build mod_ssl and mod_perl together.  Instructions
are in the guide http://perl.apache.org/guide.  You have to
build openssl first.

OpenSSL: http://www.openssl.org
mod_ssl: http://www.modssl.org

I do this now on Solaris (all with DSO's)

-Paul

> -Original Message-
> From: B. Burke [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 07, 2000 2:01 PM
> To: [EMAIL PROTECTED]
> Subject: SSL/encryption & mod_perl
> 
> 
> I've got a question related to encryption and mod_perl.  I'm running
> an apache mod_perl server (AIX and Linux platforms) to serve HTML
> forms, query backend databases, and print formatted results.  
> I currently
> use .htaccess for authentication, although this will probably change.
> 
> My problem is that the user/pass info. and much of the data is
> sensitive, and I'm looking for a way to implement SSL or encryption.
> 
> If anyone can point me in the right direction for implementing
> encryption that is compatible with apache/mod_perl, I'd appreciate
> it.
> 
> Also, many of the resources I've found thus far were written yrs.
> ago, and since then, I believe the RSA patent has expired and I
> think US Laws on encryption have changed.  I need to make sure
> whatever I implement is legal for US and possibly 
> International use, so
> if you have any comments on legality, I'd appreciate that too.
> 
> Thanks,
> Brian B.
> [EMAIL PROTECTED]
>