لطفا منتظر باشید ...
Handling Secure
Sites
One feature that's often used in conjunction
with scripting is encryption. More precisely, the Secure
Sockets Layer (SSL) is an encryption protocol that can be used to
encrypt data that pass between the Web server and Web browser to protect the
data from prying eyes. SSL is frequently used on e-commerce sites and others
that handle sensitive data. Apache is capable of handling SSL encryption, but
only with the addition of supplemental software. There are various
implementations of SSL for Apache, such as the Apache-SSL project (
commercial sources.
Understanding SSL
SSL is a form of encryption technology that's
similar to that used in the Secure Shell (SSH) remote login protocol. (In fact,
the popular OpenSSH package relies on the OpenSSL package, which is also used by
some SSL-enabled Apache implementations.) In terms of Web transfers, SSL was
designed to solve two problems: Encryption SSL allows both sides of a connection to encrypt data in order to
keep it private. This is obviously important for transmitting sensitive
information such as credit card numbers or bank account numbers. Encryption
alone can be handled by using public-key cryptography,
which requires two keys on each side of the
connection. Each party encrypts data with the other's public
key. The encrypted data can only be decrypted with the matching private key, so the sender can be sure that only the
recipient can decode the data. Authentication Even with encryption, there is risk involved in sending sensitive
data across the Internet. One such risk is that the other server may not be
what it claims to be. For instance, if you type http://www.abigretailer.com into your Web browser, how can you be sure that you've actually
reached the claimed retailer? It's conceivable that a miscreant has adjusted a
DNS server to redirect requests for the legitimate retailer to a bogus site, or
has modified routers to the same end. SSL provides a mechanism for
authenticating parties in an exchange by relying upon a third party, known as a
certificate authority (CA). The CA provides certificates, which are digital codes used in
creating public keys. If one party uses a certificate from a CA, the second
party can verify the identity of the first with a high degree of confidence. (This
isn't perfect, though; for instance, there was a foul-up in 2001 involving
certificates that were mistakenly issued in Microsoft's name to somebody who
was not affiliated with Microsoft.) Normally, secure Web servers will need
certificates from a valid CA to reassure users that the site is valid.NOTE
align=left border=0> You can serve as your own CA, but this
doesn't provide good authentication except for internal uses, since outsiders
can't trust that your internally generated certificates are valid. If you
want to run an e-commerce site, as a practical matter you'll need to obtain
certificates from a CA. One list of CAs is available at
from a CA because Web sites seldom need to be sure they're communicating with
the claimed individual.
SSL encryption isn't normally done on the
usual HTTP port (80). The default port for secure HTTP (or HTTPS ) transfers is 443. You can tell a Web browser
to use this port by using https:// at the start of the URL rather than http:// . When you
configure Apache to use SSL, you'll have to either run one server that binds to
both ports and treats them differently, or run two servers, one for each port. The
former is usually the simpler approach, but if for some reason you want to run
two different types of servers (such as Apache for secure requests and thttpd for
normal requests), you can do so.
Configuring SSL
The first step in using SSL with Apache is to
install and configure an SSL package. There are two SSL packages in common use
in Linux: SSLeay (
Linux. (OpenSSL is actually derived from SSLeay, but SSLeay remains available
as a separate package.) It's included in many Linux distributions, including
Debian, Mandrake, Red Hat, and SuSE. SSLeay and OpenSSL are logically
equivalent; they function in the same way, although different packages
sometimes place configuration files in different locations, and their main
binaries are named differently ( ssleay and openssl , respectively).Once OpenSSL is installed, you need to obtain
a certificate for it. For a public site, you should obtain your certificate
through a CA, so that your users know you are who you claim to be. For testing
purposes or to run a private site, though, you can use a certificate that you
generate yourself. In fact, some Apache SSL installation scripts, like the one
that ships with Debian, create such a certificate automatically. If yours
doesn't, you can use a command like the following to do the job: # openssl req $@ -new -x509 -nodes \ -config /usr/share/doc/apache-ssl/examples/ssleay.cnf \ -out /etc/apache-ssl/apache.pem \ -keyout /etc/apache-ssl/apache.pem
NOTE
align=left border=0> The preceding command assumes that the
SSL-enabled Apache's configuration files will reside in /etc/apache-ssl and that an SSL example configuration file exists at /usr/share/doc/apache-ssl/examples/ssleay.cnf . You may need to change these values to suit your configuration. This
command also uses backslashes ( \ ) to indicate continuations of long
lines. You can leave these in or omit them and type the entire command on one
line.
When you type this command, openssl prompts for some information, such as your location and computer name. This
information will be encoded in the certificate, which will reside in the /etc/apache-ssl/ apache.pem file.If you obtain a certificate from a CA, you
should replace your self-generated certificate file with whatever file your CA
gives you. This should eliminate the warning message that users will see if
they try to access a site that uses a self-generated certificate.
one such warning message, as displayed by Opera in Linux; other browsers may
format the information differently or present it across multiple dialog boxes.
Figure 20.2. If you use a
self-generated certificate, users who access your site will see a warning that
the certificate has expired or is not recognized.
Enabling
SSL in Apache
In principle, Apache can be configured to use
SSL through an add-on module. In practice, though, the SSL module requires a
few changes to the Apache server, so some SSL-enabled Apache packages provide a
rebuilt Apache server along with the SSL extensions. Other distributions
release an Apache package that was built with the SSL hooks, and provide an SSL
extension package that works with the standard Apache package. If you try to
mix and match regular Apache and SSL-enabled Apache packages, the combination
might or might not work.Many SSL packages use a separate
configuration file for the SSL-enabled server than for the standard server. For
instance, Debian's SSL- enabled Apache configuration files reside in /etc/apache-ssl , whereas the standard Debian Apache files are in /etc/apache . The
configuration files are largely the same as those for Apache without SSL
support, so you should set details like the Web site directories in the same
way. Some specific options you might need to change compared to a regular
installation include the following: ServerType SSL-enabled versions of Apache must be run standalone, not from a
super server. Therefore, ServerType
must be standalone . Port The standard SSL HTTP port is 443, so you should set this value
appropriately. Listen may also bind the server to a specific port number, and so should
be adjusted, if used. Modules The LoadModule and AddModule directives may reference one or more modules related to SSL. These
should be set correctly in the default or example configuration file for any
SSL-enabled version of Apache. SSLRequireSSL You might use this option within a <Directory> directive to block access to a directory if the client isn't using SSL. You use
this directive alone (it takes no options). This can be a convenient way to
ensure that sensitive data aren't transferred without encryption, but of course
you'll also need some other form of access control to ensure that only
authorized users can reach the directory. SSLEnable This directive enables SSL. Like SSLRequiresSSL , it takes
no options; just list it on a line of its own. SSLCACertificatePath This directive points Apache to the directory in which the
certificate is stored, such as /etc/apache-ssl . SSLCertificateFile This directive points Apache to the SSL certificate file, such as /etc/apache-ssl/apache.pem .There are several other SSL-related
directives you can set. Consult the comments in the configuration file, your
SSL-enabled Apache's documentation, or a book that covers SSL Apache
configuration for details.Once you've configured SSL and Apache, you
can start the SSL-enabled Apache server. You should then be able to reach the
server by typing https:// rather than http:// in a URL for the server. If you've generated your own certificate,
you'll probably see a warning like the one in
can accept the certificate (some browsers give you several options for the
conditions in which they'll accept this certificate in the future) to continue
testing the Web site.WARNING
align=left border=0> As a general rule, you shouldn't accept
unverified certificates from random Web servers. Most Web sites that use SSL
register with a CA, and you should not see such warnings for these sites. If
you do, it may mean that the Web site operator has allowed the certificate to
lapse (they are time-limited) or that the operator hasn't registered with a
CA. It could also mean that somebody is attempting to masquerade as the Web
site, and hopes to dupe users into relinquishing sensitive data like credit
card numbers.
