PKI And Apache Setup Lecture Notes

Lecture 27 — PKI and x.509 Certificates

Review PKI overview (page 26). [Adopted from NIST SP800-32.pdf]

In conventional business transactions, customers and merchants rely on credit cards (e.g., VISA or MasterCard) to complete the financial aspects of transactions. The merchant may authenticate the customer through signature comparison or by checking identification, such as a driver’s license. The merchant relies on the information on the credit card and status information obtained from the credit card issuer to ensure that payment will be received. Similarly, the customer performs the transaction knowing they can reject the bill if the merchant fails to provide the goods or services. The credit card issuer is the trusted third party in this type of transaction.

With electronic commerce, customer and merchant may be separated by hundreds of miles. Other forms of authentication are needed, and the customer’s credit card and financial information must be protected for transmission over the internet. Customers who do business with a merchant over the internet must use encryption methods that enable them to protect the information they transmit to the merchant, and the merchant must protect the information it transmits back to customers. Both customer and merchant must be able to obtain encryption keys and ensure that the other party is legitimate. The PKI provides the mechanisms to accomplish these tasks. (See also AJava/CreditCardProcessing.htm)

Two parties who wish to transact business securely may be separated geographically, and may not have ever met. To use public key cryptography to achieve their security services, they must be able to obtain each other’s public keys and authenticate the other party’s identity. This may be performed out-of-band if only two parties need to conduct business. If they will conduct business with a variety of parties, or cannot use out-of-band means, they must rely on a trusted third party to distribute the public keys and authenticate the identity of the party associated with the corresponding key pair.

Public key infrastructure is the combination of software, encryption technologies, and services that enables enterprises to protect the security of their communications and business transactions on networks. PKI integrates digital certificates, public key cryptography, and certification authorities into a complete enterprise-wide network security architecture.

A typical enterprise’s PKI encompasses the issuance of digital certificates to individual users and servers; end-user enrollment software; integration with certificate directories; tools for managing, renewing, and revoking certificates; and related services and support.

The term public key infrastructure is derived from public key cryptography, the technology on which PKI is based. Public key cryptography is the technology behind modern digital signature techniques. It has unique features that make it invaluable as a basis for security functions in distributed systems.

PKI COMPONENTS

Functional elements of a public key infrastructure include certification authorities, registration authorities, repositories, and archives. The users of the PKI come in two flavors: certificate holders and relying parties.

A certification authority (CA) is similar to a notary. The CA confirms the identities of parties sending and receiving electronic payments or other communications. Authentication is a necessary element of many formal communications between parties, including payment transactions.

A registration authority (RA) is an entity that is trusted by the CA to register or vouch for the identity of users to a CA.

A repository is a database of active digital certificates for a CA system. The main business of the repository is to provide data that allows users to confirm the status of digital certificates for individuals and businesses that receive digitally signed messages. These message recipients are called relying parties. CAs post certificates and CRLs to repositories.

The CA issues a public key certificate for each identity, confirming that the identity has the appropriate credentials. A digital certificate typically includes the public key, information about the identity of the party holding the corresponding private key, the operational period for the certificate, and the CA’s own digital signature. In addition, the certificate may contain other information about the signing party or information about the recommended uses for the public key.

Note that public keys and certificates can be thousands of digits long. Scanning such values by a human for differences is not a reliable (or fun) mechanism. Instead a message digest, or hash, of the key/certificate can be computed, typically of 128 bits in length. This number, expressed as a 32 hex-digit number, is known as the fingerprint. This fingerprint can be compared by humans. Some companies print their server’s fingerprint on their business cards.

A subscriber is an individual or business entity that has contracted with a CA to receive a digital certificate verifying an identity for digitally signing electronic messages.

CAs must also issue and process certificate revocation lists (CRLs), which are lists of certificates that have been revoked. The list is usually signed by the same entity that issued the certificates. Certificates may be revoked, for example, if the owner’s private key has been lost; the owner leaves the company or agency; or the owner’s name changes. CRLs also document the historical revocation status of certificates. That is, a dated signature may be presumed to be valid if the signature date was within the validity period of the certificate, and the current CRL of the issuing CA at that date did not show the certificate to be revoked.

PKI users are organizations or individuals that use the PKI, but do not issue certificates.

Certification Authority

The certification authority, or CA, is the basic building block of the PKI. The CA is a collection of computer hardware, software, and the people who operate it. The CA is known by two attributes: its name and its public key. The CA performs four basic PKI functions:

· issues certificates (i.e., creates and signs them);

· maintains certificate status information and issues CRLs;

· publishes its current (e.g., unexpired) certificates and CRLs, so users can obtain the information they need to implement security services;

· maintains archives of status information about the expired certificates that it issued.

These requirements may be difficult to satisfy simultaneously. To fulfill these requirements, the CA may delegate certain functions to the other components of the infrastructure.

A CA may issue certificates to users, to other CAs, or both. When a CA issues a certificate, it is asserting that the subject (the entity named in the certificate) has the private key that corresponds to the public key contained in the certificate. If the CA includes additional information in the certificate, the CA is asserting that information corresponds to the subject as well. This additional information might be contact information (e.g., an electronic mail address), or policy information (e.g., the types of applications that can be performed with this public key.) When the subject of the certificate is another CA, the issuer is asserting that the certificates issued by the other CA are trustworthy.

The CA inserts its name in every certificate (and CRL) it generates, and signs them with its private key. Once users establish that they trust a CA (directly, or through a certification path) they can trust certificates issued by that CA. Users can easily identify certificates issued by that CA by comparing its name. To ensure the certificate is genuine, they verify the signature using the CA’s public key.

X.509 Public Key Certificates

The X.509 public key certificate format has evolved into a flexible and powerful mechanism. It may be used to convey a wide variety of information. Much of that information is optional, and the contents of mandatory fields may vary as well. It is important for PKI implementers to understand the choices they face, and their consequences. Unwise choices may hinder interoperability or prevent support for critical applications. The X.509 public key certificate is protected by a digital signature of the issuer. Certificate users know the contents have not been tampered with since the signature was generated if the signature can be verified. Certificates contain a set of common fields, and may also include an optional set of extensions.

There are ten common fields: six mandatory and four optional. The mandatory fields are:

· Serial number. The serial number is an integer assigned by the certificate issuer to each certificate. The serial number must be unique for each certificate generated by a particular issuer. The combination of the issuer name and serial number uniquely identifies any certificate.

· Signature. The signature field indicates which digital signature algorithm (e.g., DSA with SHA-1 or RSA with MD5) was used to protect the certificate.

In 2004 MD5 was shown to have some theoretical weaknesses. While still considered safe at the time, in 2008 a more severe weakness was discovered. It is possible for virus writers to craft a virus infected file to have the same MD5 sum as the real file.

Since PKI certificates generally rely on MD5 it has become possible to spoof a site even when using HTTPS. It is hoped that the X.509 certificates used for PKI will soon migrate to SHA-2 or SHA-2.

See www.phreedom.org/research/rogue-ca/ for more information.

· The certificate issuer name. The issuer field contains the X.500 distinguished name of the TTP (CA) that generated the certificate.

· Validity. The validity field indicates the dates on which the certificate becomes valid and the date on which the certificate expires (i.e., the certificate validity period).

· Subject’s public key information. The subject public key information field contains the subject’s public key, optional parameters, and algorithm identifier. The public key in this field, along with the optional algorithm parameters, is used to verify digital signatures or perform key management. If the certificate subject is a CA, then the public key is used to verify the digital signature on a certificate.

· Subject. The subject is the party that controls the corresponding private key. The subject field contains the distinguished name of the holder of the private key corresponding to the public key in this certificate. The subject may be a CA, a RA, or an end entity. End entities can be human users, hardware devices, or anything else that might make use of the private key.

There are four optional fields: the version number, two unique identifiers, and the extensions. These optional fields appear only in version 2 and 3 certificates.

· Version. The version field describes the syntax of the certificate. When the version field is omitted, the certificate is encoded in the original, version 1, syntax. Version 1 certificates do not include the unique identifiers or extensions. When the certificate includes unique identifiers but not extensions, the version field indicates version 2. When the certificate includes extensions, as almost all modern certificates do, the version field indicates version 3.

· Issuer unique ID and subject unique ID. These fields contain identifiers, and only appear in version 2 or version 3 certificates. The subject and issuer unique identifiers are intended to handle the reuse of subject names or issuer names over time. However, this mechanism has proven to be an unsatisfactory solution. The Internet Certificate and CRL profile does not recommend inclusion of these fields.

· Extensions. This optional field only appears in version 3 certificates. If present, this field contains one or more certificate extensions. Certificate extensions allow the CA to include information not supported by the basic certificate content.

Extensions have three components: extension identifier, a criticality flag, and extension value. The extension identifier indicates the format and semantics of the extension value. The criticality flag indicates the importance of the extension. When the criticality flag is set, the information is essential to certificate use. Therefore, if an unrecognized critical extension is encountered, the certificate must not be used. Alternatively, an unrecognized non-critical extension may be ignored.

Any organization may define a private extension to meet its particular business requirements. However, most requirements can be satisfied using standard extensions. Common certificate extensions have been defined by ISO and ANSI to answer questions that are not satisfied by the common fields:

o Subject type. This field indicates whether a subject is a CA or an end entity.

o Names and identity information. This field aids in resolving questions about a user’s identity, e.g., are “alice@gsa.gov” and
“c=US; o=U.S. Government; ou=GSA; cn=Alice Adams” the same person?

o Key attributes. This field specifies relevant attributes of public keys, e.g., whether it can be used for key transport, or be used to verify a digital signature.

o Policy information. This field helps users determine if another user’s certificate can be trusted, whether it is appropriate for large transactions, and other conditions that vary with organizational policies.

o basic constraints. The subject of a certificate could be an end user or another CA. The basic certificate fields do not differentiate between these types of users. The basic constraints extension appears in CA certificates, indicating this certificate may be used to build certification paths.

o The key usage extension indicates the types of security services that this public key can be used to implement. These may be generic services (e.g., non-repudiation or data encryption) or PKI specific services (e.g., verifying signatures on certificates or CRLs).

o The subject field contains a directory name, but that may not be the type of name that is used by a particular application. The subject alternative name extension is used to provide other name forms for the owner of the private key, such as DNS names or email addresses. For example, the email address alice@gsa.gov.gov could appear in this field.

o CAs may have multiple key pairs. The authority key identifier extension helps users select the right public key to verify the signature on this certificate.

o Users may also have multiple key pairs, or multiple certificates for the same key. The subject key identifier extension is used to identify the appropriate public key.

o Organizations may support a broad range of applications using PKI. Some certificates may be more trustworthy than others, based on the procedures used to issue them or the type of user cryptographic module. The certificate policies extension contains a globally unique identifier that specifies the certificate policy that applies to this certificate.

o Different organizations (e.g., different companies or government agencies) will use different certificate policies. Users will not recognize policies from other organizations. The policy mappings extension converts policy information from other organizations into locally useful policies. This extension appears only in CA certificates.

o The CRL distribution points extension contains a pointer to the X.509 CRL where status information for this certificate may be found.

When a CA issues a certificate to another CA, it is asserting that the other CA’s certificates are trustworthy. Sometimes, the issuer would like to assert that a subset of the certificates should be trusted. There are three basic ways to specify that a subset of certificates should be trusted:

o The basic constraints extension (described above) has a second role, indicating whether this CA is trusted to issue CA certificates, or just user certificates.

o The name constraints extension can be used to describe a subset of certificates based on the names in either the subject or subject alternative name fields. This extension can be used to define the set of acceptable names, or the set of unacceptable names . That is, the CA could assert “names in the NIST directory space are acceptable” or “names in the NIST directory space are not acceptable.”

o The policy constraints extension can be used to describe a subset of certificates based on the contents of the policy extension. If policy constraints are implemented, users will reject certificates without a policy extension, or where the specified policies are unrecognized.

Certificate Revocation Lists (CRLs)

Certificates contain an expiration date. Unfortunately, the data in a certificate may become unreliable before the expiration date arrives. Certificate issuers need a mechanism to provide a status update for the certificates they have issued. One mechanism is the X.509 certification revocation list (CRL).

CRLs are the PKI analog of the credit card hot list that store clerks review before accepting large credit card transactions. The CRL is protected by a digital signature of the CRL issuer . If the signature can be verified, CRL users know the contents have not been tampered with since the signature was generated.

Steps to Setup PKI

To obtain a certificate (for yourself, for email or commerce purposes, or for a website) you must first select the CA that you hope will issue your certificate. It is possible to setup a CA for your organization, that in turn can be used to issue certificates to employees, customers, etc. Then your CA’s certificate is the only one you need signed by an outside, trusted root CA. Actually you can self-sign your own CA certificate, essentially issuing the CA certificate from yourself to yourself.

To setup your own CA, you generate a certificate signing request (CSR) containing a pair of files (sometimes a single file is used). One contains your private key and the other contains your public key and your (subject) information. Once the CSR is processed by a CA (by adding information and digitally signing the content), this file becomes the CA’s certificate. OpenSSL includes tools to allow you to generate CSRs, and to self-sign them if desired.

Another possibility is to just use an existing CA to process all your CSRs. cacert.org will do this for free, and for learning purposes you can either become your own CA or just use theirs.

Note! The certificate for your own CA, and for some others including caceret.org are not included in most web browsers by default. (Some are.) This means the first time someone visits your site using HTTPS, they will need to import the CA certificate for the CA that signed your website’s certificate.

To setup a certificate for a website or other TLS protected service, you use Some toolkit and library. Currently the most popular of these is OpenSSL which comes with a complete library for crypto and digests, and many utilities.

A newer toolkit is NSS (Network Security Services). NSS is a set of libraries supporting security-enabled client and server applications. Applications built with NSS can support SSL v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security standards. NSS has received FIPS 140 validation from NIST, making it a preferred network cryptographic library for SSL/TLS and PKI certificate management and provides an alternative to OpenSSL and GNU TLS. NSS has been used with Netscape products for years, proving itself to be reliable (see www.mozilla.org/projects/security/pki/nss/tools).

openssl has tools (man CA) to generate a private key and a CSR. You then submit the CSR to your CA and install the certificate when they email it to you (it typically takes a few days). Finally you must configure your applications to use these certificates (and TLS). They will need to know the names to use as well as the location of the private key, the certificate, and the CA’s certificate An easy way to accomplish all this:

cd ... (Fedora: /etc/pki/tls/misc/)

./CA -newca

./CA -newreq-nodes

./CA -signreq

# To create a certificate in a standard format, to

# be imported into a web browser or on Windows:

# ./CA -pkcs12 "name of certificate to show"

[From www.ciscopress.com/articles/article.asp?p=24664&seqNum=4&rl=1 ]

The openssl packages no longer include the CA.pl script (on Linux anyway) and instead provide a more limited “CA” shell script instead that doesn’t have the “newreq‑nodes” (for “no DES”) option; it just has “‑newreq”. Thus extra steps are needed afterwards to get an unsigned key. (Such keys are very insecure, but needed for unattended reboot, otherwise a human must enter the key before the service can start up correctly.)

To add back this option, make a backup copy of that script. Then edit the script, finding the part that says:

-newreq)
    # create a certificate request
    $REQ -new -keyout newkey.pem -out newreq.pem $DAYS
    RET=$?
    echo "Request is in newreq.pem, private key is in newkey.pem"
    ;;
and add the following immediately below, like this:

   -newreq-nodes)
      # create a certificate request
      $REQ -new -nodes -keyout newkey.pem -out newreq.pem \
         $DAYS
      RET=$?
     echo "Request is in newreq.pem, private key is in " \
         "newkey.pem"
      ;;

(You might want to edit the help message too.)

PKCS #7 and #10 are acronyms for the Public-Key Cryptography Standards #7 and #10. These are standards originally from RSA Security Inc. used to encrypt and sign certificate enrollment messages. Today they are widely used formats for certificates. A PEM file is a base64 encoded series of certificates and/or keys. (See “X.509” in Wikipedia.)

The SCEP (Simple Certificate Enrollment Protocol) is an Internet Engineering Task Force (IETF) draft sponsored by Cisco that provides a standard way of managing the certificate lifecycle. The SCEP to automate the exchange of certificates with a CA server, and is often used by routers or firewalls to obtain PKI certificates.

When creating certificates, a CA using SCEP provides two authentication methods: manual authentication and authentication based on a preshared secret. In the manual mode, the end entity submitting the request is required to wait until the CA operator, using any reliable out-of-band method, can verify its identity. An MD5 fingerprint generated on the PKCS # must be compared out-of-band between the server and the end entity. SCEP clients and CAs (or RAs, if appropriate) must display this fingerprint to a user to enable this verification, if manual mode is used.

When using a preshared secret scheme, the server should distribute a shared secret to the end entity that can uniquely associate the enrollment request with the given end entity. The distribution of the secret must be private: only the end entity should know this secret. When creating the enrollment (certificate signing) request, the end entity is asked to provide a challenge password. When using the preshared secret scheme, the end entity must type in the redistributed secret as the password.

In the manual authentication case, the challenge password is also required because the server might challenge an end entity with the password before any certificate can be revoked. Later on, this challenge password will be included as a PKCS #10 attribute and will be sent to the server as encrypted data. The PKCS #7 envelope protects the privacy of the challenge password with Data Encryption Standard (DES) encryption.

Lecture 28 — Securing Apache to use PKI, Basic/Digest Authentication

Apache supports two authentication mechanisms: Basic and Digest. (support for other mechanisms such as Kerberos can be provided by additional Apache modules.) Digest is more secure, only few web browsers today support it! Basic authentication causes a user’s browser to prompt them for a username, password, and realm. The information is sent in plain text form back to the server, which reads the stored password from s special file (not /etc/{passwd,shadow}!)

Basic security is perfectly adequate if the session is encrypted using TLS (SSL). No web authentication is secure unless using HTTPS.

For a given location (or directory), you define the type of authentication desired (AuthType Basic or AuthType Digest), the name of the realm (AuthName "name of realm"), and the location of the file that contains username-passwords, and optionally a group file listing group names and usernames that belong to each group. Use AuthUserFile and AuthGroupFile directives for this.

Next you control access to this location with the Require directive. Besides listing specific users in the httpd.conf file to allow/deny, you can define groups of users (and then permit/deny users and/or groups). You can also allow any “valid-user”. In addition to the Require directive, you can use the Limit directives to control what HTTP commands to allow (e.g., GET, POST).

Apache uses htpasswd command to create and manage the username/password files for realms. Use the “-c” option for the first user you create, then omit (as this option re-create the file!) Use the “-m” option to force MD5 passwords. Here’s an example:

htpasswd -mc /home/wpollock.com/passwords wpollock
htpasswd -m /home/wpollock.com/passwords rnixon

The group file is a plain text file, with one group defined per line. The syntax is:

    group_name1: user1 user2 user3 ...
    group_name2: user1 user2 user3 ...
    ...

The Debian Apache2 web server comes with the SSL module available, but it is not automatically enabled. In order to enable it you must execute:
a2enmod ssl
and restart the web server. The generic way to do this is to have the line
Include /etc/apache2/mod_ssl.conf
in your /etc/apache2/apache2.conf (this file may also be called httpd.conf). You’ll need to edit it to give the appropriate location for mod_ssl.conf in your setup. Then restart the web server. (Fedora 11 has a separate package for this, “mod_ssl” that you must install.)

Case Study: Configuring Apache to use HTTPS, Basic/Digest Authentication

On Fedora, digital certificates are now centralized in directories under /etc/pki/tls/. See the /etc/httpd/conf.d/ssl.conf file for default locations and names.

Note: To use SSL you must use IP virtual hosts, not name virtual hosts!

To add SSL support for https://wpollock.com/ to apache, do these steps (Note: openssl includes a convenience shell scirpt /etc/pki/tls/misc/CA that can simplify these steps):

# Generate a private key for the wpollock.com website:

openssl genrsa -des3 -out wpollock-com.key 1024

# Remove password from key (so apache can start unattended):

openssl rsa -in wpollock-com.key.orig -out wpollock-com.key

# Generate a CSR (certificate signing request), to be submitted

# to your CA of choice (I used CAcert.org):

openssl req -new -key wpollock-com.key -out wpollock-com.csr

# Upload the CSR to cacert.org website,

# Wait for CA to return certificate via email, saved

# as ~/wpollock-com.crt. (This took a little over a day.)

# While waiting, get the CA's root certificate:

wget https://www.cacert.org/cacert.crt

# Add email alias for webmaster to /etc/aliases:

vi /etc/aliases; newaliases

# Install everything:

cd /etc/pki/tls

cp ~/wpollock-com.key private/

cp ~/cacert.crt certs/

cp ~/wpollock-com.crt certs/

# cp ~/wpollock-com.csr ssl.csr

# Update permissions:

chmod 400 certs/{cacert,wpollock-com}.crt \

private/wpollock-com.key

# Edit /etc/sysconfig/httpd to start apache with SSL option:

cd /etc/sysconfig/

cp httpd httpd.orig

vi httpd

diff httpd.orig httpd

15c15

< #OPTIONS=

---

> OPTIONS="-DSSL"

# Make firewall hole for port 443 (edit /etc/sysconfig/iptables

# by adding the following line after the line for port 80):

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp \

--dport 443 -j ACCEPT

# Modify /etc/httpd/conf.d/ssl.conf to include new virtual host:

# (comments and blank lines stripped out to reduce listing

# size here):

ServerAdmin webmaster@wpollock.com

DocumentRoot /home/wpollock.com/html-secure

ServerName wpollock.com:443

CheckSpelling on

Options Includes SymLinksIfOwnerMatch

</Location>

Scriptalias /cgi-bin/ "/home/wpollock.com/cgi-bin/"

ErrorLog /home/wpollock.com/ssl_error_log

SSLEngine on

SSLCipherSuite \

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

SSLCertificateFile /etc/pki/tls/certs/wpollock-com.crt

SSLCertificateKeyFile \

/etc/pki/tls/private/wpollock-com.key

SSLCACertificatePath /etc/pki/tls/certs

SSLOptions +StdEnvVars

</Files>

SSLOptions +StdEnvVars

</Directory>

SetEnvIf User-Agent ".*MSIE.*" \

nokeepalive ssl-unclean-shutdown \

downgrade-1.0 force-response-1.0

CustomLog /home/wpollock.com/ssl_request_log \

"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

</VirtualHost>

httpd -S # verify apache configuration

# create firewall holes:

vi /etc/sysconfig/iptables; service iptables restart

# Now reload apache (httpd):

/etc/init.d/httpd restart

# Check all logs for any errors:

cd /var/log

tail messages

cd httpd

tail error_log

cat ssl*

# Now try from other host to connect to URL

"https://wpollock.com/":

ssh wpollock@yborstudent.hccfl.edu

links https://wpollock.com/

#Success!

To add Basic authentication to this site, change (in that virtual host):

Options Includes SymLinksIfOwnerMatch

</Location>

To:

Options SymLinksIfOwnerMatch

AuthType Basic

AuthName "Restricted Files"

AuthUserFile /home/wpollock.com/passwords/htpasswd

Require valid-user

<Limit GET POST>

Order allow,deny

Allow from all

</Limit>

<LimitExcept GET POST>

Order deny,allow

Deny from all

</LimitExcept>

</Location>

HTTP Basic auth header capture (via “Live HTTPHeader” Firefox extension)

https://wpollock.com/

GET / HTTP/1.1

Host: wpollock.com

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061108 Fedora/1.5.0.8-1.fc5 Firefox/1.5.0.8

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

HTTP/1.x 401 Authorization Required

Date: Fri, 01 Dec 2006 02:25:54 GMT

Server: Apache

WWW-Authenticate: Basic realm="Restricted Files"

Content-Length: 510

Keep-Alive: timeout=15, max=100

Connection: Keep-Alive

Content-Type: text/html; charset=iso-8859-1

----------------------------------------------------------

https://wpollock.com/

GET / HTTP/1.1

Host: wpollock.com

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061108 Fedora/1.5.0.8-1.fc5 Firefox/1.5.0.8

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Authorization: Basic d3BvbGvxY3s6cmFiYXV0MjE=

HTTP/1.x 200 OK

Date: Fri, 01 Dec 2006 02:26:06 GMT

Server: Apache

Last-Modified: Mon, 13 Nov 2006 22:35:27 GMT

Etag: "270275-3ae-84afe9c0"

Accept-Ranges: bytes

Content-Length: 942

Keep-Alive: timeout=15, max=99

Connection: Keep-Alive

Content-Type: text/html; charset=UTF-8

----------------------------------------------------------

https://wpollock.com/favicon.ico

GET /favicon.ico HTTP/1.1

Host: wpollock.com

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061108 Fedora/1.5.0.8-1.fc5 Firefox/1.5.0.8

Accept: image/png,*/*;q=0.5

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Authorization: Basic d3BvbGvxY3s6cmFiYXV0MjE=

HTTP/1.x 200 OK

Date: Fri, 01 Dec 2006 02:26:06 GMT

Server: Apache

Last-Modified: Wed, 01 Sep 2004 21:25:07 GMT

Etag: "2708e8-436-ee95b2c0"

Accept-Ranges: bytes

Content-Length: 1078

Keep-Alive: timeout=15, max=98

Connection: Keep-Alive

Content-Type: text/plain; charset=UTF-8

----------------------------------------------------------

https://wpollock.com/UnixSecurity/

GET /UnixSecurity/ HTTP/1.1

Host: wpollock.com

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061108 Fedora/1.5.0.8-1.fc5 Firefox/1.5.0.8

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: https://wpollock.com/

Authorization: Basic d3BvbGvxY3s6cmFiYXV0MjE=

HTTP/1.x 200 OK

Date: Fri, 01 Dec 2006 02:26:12 GMT

Server: Apache

Last-Modified: Fri, 20 Oct 2006 06:55:06 GMT

Etag: "2741de-12b-958ac680"

Accept-Ranges: bytes

Content-Length: 299

Keep-Alive: timeout=15, max=97

Connection: Keep-Alive

Content-Type: text/html; charset=UTF-8

----------------------------------------------------------

Other Web Security Measures

Web content is generally read-only and is reasonably safe as long as an attacker can’t modify files on the server. The best an attacker from the outside can do on a read-only site is to craft URLs to either access confidential content, or to exploit a vulnerability in the server. (Here we are ignoring phishing attacks by slightly mis-spelling popular web sites, DNS rebinding attacks, etc.) However such web sites are boring and most are interactive, allowing people to upload content. This brings many other possible attacks into the mix, such as XSS, SQL Injection, and spam.

Making a web site secure is more difficult than most web developers realize. The obvious approaches are often not secure at all. Best advice is to use a well known web platform that provides the security features you need; then all an SA has to do is enable them correctly.

One common threat is from automatic spam-bots. There are a few measures you can take to “raise the bar” for attackers. For example it has been found that checking form input against a small dictionary of 20 or so words can be very successful at detecting form/forum spam.

Another technique is to have the server send an encrypted or specially encoded web page that is meaningless to attackers. An included JavaScript on the page dynamically renders the page. This process is invisible to users but an attacker would have to actually render the page before uploading, for each web site to be spammed. A similar technique uses CSS style-sheets to make some parts of the page invisible to users with a browser, but visible to spam-bots (unless they render the page). The extra fields are “decoys” designed to attract the spam-bots.