8
Managing Security

This chapter provides an overview of Oracle HTTP Server security features and configuration information for setting up a secure Web site using them.

Topics discussed are:

About Oracle HTTP Server Security
Classes of Users and Their Privileges
Resources Protected
Authentication and Authorization Enforcement
Security Services Implemented Within Oracle HTTP Server

See Also:
For additional information about security, refer to Oracle Application Server 10g Security Guide provides an overview of Oracle Database security and its core functionality.

About Oracle HTTP Server Security

Security can be organized into the three categories of authentication, authorization, and confidentiality. Oracle HTTP Server provides support for all three of these categories. It is based on the Apache Web server, and its security infrastructure is primarily provided by the Apache modules, mod_auth and mod_access, and the Oracle modules, mod_ossl. mod_auth provides authentication based on user name and password pairs, mod_access controls access to the server based on the characteristics of a request, such as hostname or IP address, mod_ossl provides confidentiality and authentication with X.509 client certificates over SSL.

Based on the Apache model, Oracle HTTP Server provides access control, authentication, and authorization methods that can be configured with access control directives in the httpd.conf file. When URL requests arrive at Oracle HTTP Server, they are processed in a sequence of steps determined by server defaults and configuration parameters. The steps for handling URL requests are implemented through a module or plug-in architecture that is common to many Web listeners.

Figure 8-1 shows how URL requests are handled by the server. Each step in this process is handled by a server module depending on how the server is configured. For example, if basic authentication is used, then the steps labeled "Authentication" and "Authorization" in Figure 8-1 represent the processing of the mod_auth module.

Figure 8-1 Steps for Handling URL Requests in Oracle HTTP Server

Text description of ohsurlpr.gif follows.

Text description of the illustration ohsurlpr.gif

Classes of Users and Their Privileges

Oracle HTTP Server authorizes and authenticates users before allowing them to access, or modify resources on the server. Following are two classes of users that access the server using Oracle HTTP Server, and their privileges.

Users that access the server without providing any authentication. They have access to unprotected resources only.
Users that have been authenticated and potentially authorized by modules within Oracle HTTP Server. This includes users authenticated by mod_auth and mod_ossl. Such users have access to URLs defined in http.conf file.

See Also:
"Authentication and Authorization Enforcement"

Resources Protected

Oracle HTTP Server is configured to protect resources such as:

Static content such as static HTML pages, graphics interchange format, .gif, files, and other static files that Oracle HTTP Server provides directly.
CGI/FastCGI scripts, simple scripts or programs that Oracle HTTP Server invokes directly.
Content generated by modules within Oracle HTTP Server. Modules such as mod_perl, mod_dms generate responses that are returned to the client.

Authentication and Authorization Enforcement

Oracle HTTP Server provides user authentication and authorization at two stages:

Host-based Access Control (stage one): This is based on the details of the incoming HTTP request and its headers, such as IP addresses or host names.
User Authentication and Authorization (stage two): This is based on different criteria depending on the HTTP server configuration. The server can be configured to authenticate users with user name and password pairs that are checked against a list of known users and passwords.

Host-based Access Control

Early in the request processing cycle, access control is applied, which can inhibit further processing based on the host name, IP address, or other characteristics such as browser type. You use the deny, allow, and order directives to set this type of access control. These restrictions are configured with Oracle HTTP Server configuration directives and can be based on particular files, directories, or URL formats using the <Files>, <Directory>, and <Location> container directives as shown in the Example 8-1:

Example 8-1 Host-based Access Control

<Directory /internalonly/>
  order deny, allow
  deny from all
  allow from 192.168.1 us.oracle.com
</Directory>

In Example 8-1, the order directive determines the order in which Oracle HTTP Server reads the conditions of the deny and allow directives. The deny directive ensures that all requests are denied access. Then, using the allow directive, requests originating from any IP address in the 192.168.1.* range, or with the domain name us.oracle.com are allowed access to files in the directory /internalonly/. It is common practice to specify both allow and deny in host-based authentication to make the access policy explicit.

If you want to match objects at the file system level, then you must use <Directory> or <Files>. If you want to match objects at the URL level, then you must use <Location>.

Note:

Allowing or restricting access based on a host name for Internet access is not considered a very good method of providing security, because host names are easy to spoof. While the same is true of IP addresses, sabotage is more difficult. However, setting access control with intranet IP address ranges is reasonable because the same risks do not apply. This assumes that your firewalls have been properly configured.

Access Control for Virtual Hosts

To set up access control for virtual hosts, place the AccessConfig directive inside a virtual host container in the server configuration file, httpd.conf. When used in a virtual host container, the AccessConfig directive specifies an access control policy contained in a file. Example 8-2 shows an excerpt from an httpd.conf file which provides the syntax for using AccessConfig this way:

Example 8-2 Using AccessConfig to Set Up Access Control

...
<VirtualHost ip_address_of_host.some_domain.com>
  ... virtual host directives ...
  AccessConfig conf/access.conf
</VirtualHost>

Using mod_access and mod_setenvif for Host-based Access Control

Using host-based access control schemes, you can control access to restricted areas based on where HTTP requests originate. Oracle HTTP Server uses mod_access and mod_setenvif to perform host-based access control. mod_access provides access control based on client hostname, IP address, or other characteristics of the client request, and mod_setenvif provides the ability to set environment variables based upon attributes of the request. When you enter configuration directives into the httpd.conf file that use these modules, the server fulfills or denies requests based on the address or name of the host, or based on the HTTP request header contents.

You can use host-based access control to protect static HTML pages, applications, or components.

Oracle HTTP Server supports four host-based access control schemes:

All of these allow you to specify the machines from which access to protected areas is granted or denied. Your decision to choose one or more of the host-based access control schemes is determined by which scheme most efficiently protects your restricted content and applications, or which scheme is easiest to maintain.

Controlling Access by IP Address

Controlling access with IP addresses is a preferred method of host-based access control. It does not require DNS lookups that consume time, system resources, and make your server vulnerable to DNS spoofing attacks.

Example 8-3 Controlling Access by IP Address

<Directory /secure_only/>
  order deny,allow
  deny from all
  allow from 207.175.42.*
</Directory>

In Example 8-3, requests originating from all IP addresses except 207.175.42.* range are denied access to the /secure_only/ directory.

Controlling Access by Domain Name

Domain name-based access control can be used with IP address-based access control to solve the problem of IP addresses changing without warning. When you combine these methods, if an IP address changes, then the secure areas of your site are still protected because the domain names you want to keep out will still be denied access.

To combine domain name-based with IP address-based access control, use the syntax shown in Example 8-4:

Example 8-4 controlling Access by Domain Name

<Directory /co_backgr/>
  order allow,deny
  allow from all
  # 141.217.24.* is the IP for malicious.cracker.com
  deny from malicious.cracker.com 141.217.24.*
</Directory>

In Example 8-4, all requests for directory /co_backgr/ are accepted except those that originate from the domain name malicious.cracker.com or the IP address 141.217.24.* range. Although this is not a fool proof precaution against domain name or IP address spoofing, it protects your site from malicious.cracker.com even if they change their IP address.

Controlling Access by Network or Netmask

You can control access based on subsets of networks, specified by IP address. The syntax is shown in Example 8-5:

Example 8-5 Controlling Access by Network or Netmask

<Directory /payroll/>
  order deny,allow
  deny from all
  allow from 10.1.0.0/255.255.0.0
</Directory>

In Example 8-5, access is allowed from a network/netmask pair. A netmask shows how an IP address is to be divided into network, subnet, and host identifiers. Netmasks enable you to refer to only the host ID portion of an IP address.

The netmask in Example 8-5, 255.255.0.0, is the default netmask setting for a Class B address. The binary ones (decimal 255) mask the network ID and the binary zeroes (decimal 0) retain the host ID of a given IP address.

Controlling Access with Environment Variables

You can use arbitrary environment variables for access control, instead of using IP addresses or domain names. Use BrowserMatch and SetEnvIf directives for this type of access control.

Note:

Typically, BrowserMatch and SetEnvIf are not used to implement security policies. Instead they are used to provide different handling of requests based on browser types and versions.

Use BrowserMatch when you want to base access on the type of browser used to send a request. For instance, if you want to allow access only to requests that come from a Netscape browser, then use the syntax shown in Example 8-6:

Example 8-6 Controlling Access with Environment Variables

BrowserMatch ^Mozilla netscape_browser
<Directory /mozilla-area/>
  order deny,allow
  deny from all
  allow from env=netscape_browser
</Directory>

Use SetEnvIf when you want to base access on header information contained in the HTTP request. For instance, if you want to deny access from any browsers using HTTP version 1.0 or earlier, then use the syntax shown in Example 8-7:

Example 8-7 Controlling Access with SetEnv

SetEnvIf Request_Protocol ^HTTP/1.1 http_11_ok
<Directory /http1.1only/>
  order deny,allow
  deny from all
  allow from env=http_11_ok
</Directory>

See Also: "Scope of Directives"

User Authentication and Authorization

Basic authentication prompts for a user name and password before serving an HTTP request. When a browser requests a page from a protected area, Oracle HTTP Server responds with an unauthorized message (status code 401) containing a WWW-Authenticate: header and the name of the realm configured by the configuration directive, AuthName. When the browser receives this response, it prompts for a user name and password. After the user enters a user name and password combination, the browser sends this information back to the server in an Authorization header. In the authorization header message, the user name and password are encoded as a base 64 encoded string.

User authorization involves checking the authenticated user against an access control list that is associated with a specific server resource such as a file or directory. To configure user authorization, place the require directive in the httpd.conf file, usually within a virtual host container. User authorization is commonly used in combination with user authentication. After the server has authenticated a user's user name and password, then the server compares the user to an access control list associated with the requested server resource. If Oracle HTTP Server finds the user or the user's group on the list, then the resource is made available to that user.

Using mod_auth to Authenticate Users

User authentication is based on user names and passwords that are checked against a list of known users and passwords. These user name and password pairs may be stored in a variety of forms, such as a text file, database, or directory service. Then configuration directives are used in httpd.conf to configure this type of user authentication on the server. mod_auth uses the AuthUserFile directive to set up basic authentication. It supports only files.

Any authentication scheme that you devise requires that you use a combination of the configuration directives listed in Table 8-1.

Table 8-1 Directives Descriptions

Directive Name	Description
`AuthName`	Defines the name of the realm in which the user names and passwords are valid. Use quotation marks if the name includes spaces.
`AuthType`	Specifies the authentication type. Most authentication modules use basic authentication, which transmits user names and passwords in clear text. This is not recommended.
`AuthUserFile`	Specifies the path to a file that contains user names and passwords.
`AuthGroupFile`	Specifies the path to a file that contains group names and their members.

Using mod_ossl to Authenticate Users

Secure Sockets Layer (SSL) is an encrypted communication protocol that is designed to securely send messages across the Internet. It resides between Oracle HTTP Server on the application layer and the TCP/IP layer, transparently handling encryption and decryption when a secure connection is made by a client.

One common use of SSL is to secure Web HTTP communication between a browser and a Web server. This case does not preclude the use of non-secured HTTP. The secure version is simply HTTP over SSL (named HTTPS). The differences are that HTTPS uses the URL scheme https:// rather than http://, and its default communication port is 4443.

mod_ossl is a plug-in to Oracle HTTP Server that enables the server to use SSL. mod_ossl replaces mod_ssl in the Oracle HTTP Server distribution. Oracle no longer supports mod_ssl.

See Also:

"Using mod_ossl" for detailed information regarding mod_ossl.

Enabling SSL

By default, SSL is disabled when you install Oracle Database. If you want to enable SSL after installation, perform the following steps:

Open opmn.xml in a text editor.
In the <ias-component id=HTTP_Server> entry, change the start mode from "ssl-disabled" to "ssl-enabled". After modification is made, the entry should look like the following:
```
<data id="start-mode" value="ssl-enabled"/>
```
Save and close opmn.xml.
Reload OPMN using the following command:
```
opmnctl reload
```
Stop Oracle HTTP Server using the following command:
- UNIX: ORACLE_HOME/opmn/bin> opmnctl [verbose] stopproc ias-component=HTTP_Server
- Windows: ORACLE_HOME\opmn\bin> opmnctl [verbose] stopproc ias-component=HTTP_Server
Start Oracle HTTP Server using the following command:
- UNIX: ORACLE_HOME/opmn/bin> opmnctl [verbose] startproc ias-component=HTTP_Server
- Windows: ORACLE_HOME\opmn\bin> opmnctl [verbose] startproc ias-component=HTTP_Server

You can verify if SSL was enabled successfully by navigating to the SSL port, for example:

HTTPS://hostname:4443

Note: The preceding steps enable SSL for Oracle HTTP Server using a default insecure certificate. To achieve completely secure SSL communication with Oracle HTTP Server, obtain and configure a real certificate within mod_ossl.

Security Services Implemented Within Oracle HTTP Server

Oracle HTTP Server provides security services that enable you to protect your server from unwanted users and malicious attacks. These security services ensure secure data exchanged between client and the server.

mod_ossl enables secure connections between Oracle HTTP Server and a browser client by using an Oracle-provided encryption mechanism over SSL. It also provides data integrity and strong authentication for users and HTTP servers.

Using mod_ossl

mod_ossl provides standard support for HTTPS protocol connections to Oracle Database. It enables secure connections between Oracle HTTP Server and a browser client by using an Oracle-provided encryption mechanism over SSL. It may also be used for authentication over the Internet through the use of digital certificate technology. It supports SSL v. 3.0, and provides:

Encrypted communication between client and server, using RSA or DES encryption standards.
Integrity checking of client-server communication using MD5 or SHA checksum algorithms.
Certificate management with Oracle wallets.

Table 8-2 identifies the differences between mod_ossl, and mod_ssl.

Table 8-2 Differences between mod_ossl and mod_ssl

Feature	mod_ossl	mod_ssl
SSL versions supported	3.0	2.0, 3.0, TLS 1.0
Certificate management	Oracle Wallet^{Foot 1}^, ^{Foot 2}	Text file

¹ Oracle Wallet Manager is a tool that manages certificates for mod_ossl.
² Supports obfuscated passwords.

The following mod_ssl directives listed are not supported by mod_ossl.

SSLRandomSeed
SSLCertificateFile
SSLCertificateKeyFile
SSLCertificateChainFile
SSLCACertificateFile
SSLCACertificatePath
SSLVerifyDepth

Caution:
The server will not start if these directives are used.

Using mod_ossl Directives

To configure SSL for your Oracle HTTP Server, enter the mod_ossl directives you want to use in the httpd.conf file.

The following directive are described in subsequent sections:

SSLAccelerator

Specifies if SSL accelerator is used. Currently only nFast card is supported.

Category	Value
Valid Values	`yes/no`
Syntax	`SSLAccelerator yes\|no`
Default	`SSLAccelerator no`
Context	server configuration

SSLCARevocationFile

Specifies the file where you can assemble the Certificate Revocation Lists (CRLs) from CAs (Certificate Authorities) that you accept certificates from. These are used for client authentication. Such a file is the concatenation of various PEM-encoded CRL files in order of preference. This directive can be used alternatively or additionally to SSLCARevocationPath.

Category	Value
Syntax	`SSLCARevocationFile` `file_name`
Example	`SSLCARevocationFile /``ORACLE_HOME``/Apache/conf/ssl.crl/ca_bundle.crl`
Default	None
Context	server configuration, virtual host

SSLCARevocationPath

Specifies the directory where PEM-encoded Certificate Revocation Lists (CRLs) are stored. These CRLs come from the CAs (Certificate Authorities) that you accept certificates from. If a client attempts to authenticate itself with a certificate that is on one of these CRLs, then the certificate is revoked and the client cannot authenticate itself with your server.

Category	Value
Syntax	`SSLCARevocationPath` `path/to/CRL_directory/`
Example	`SSLCARevocationPath /``ORACLE_HOME``/Apache/conf/ssl.crl/`
Default	None
Context	server configuration, virtual host

SSLCipherSuite

Specifies the SSL cipher suite that the client can use during the SSL handshake. This directive uses a colon-separated cipher specification string to identify the cipher suite. Table 8-3 shows the tags you can use in the string to describe the cipher suite you want.

Tags are joined together with prefixes to form cipher specification string.

Category	Value
Valid Values	`none`: Adds the cipher to the list `+` : Adds the cipher to the list and place them in the correct location in the list `-` : Remove the cipher from the list (can be added later) `!` : Remove the cipher from the list permanently
Example	`SSLCipherSuite` `ALL:!LOW:!DH` In this example, all ciphers are specified except low strength ciphers and those using the Diffie-Hellman key negotiation algorithm.
Syntax	`SSLCipherSuite` `cipher-spec`
Default	None
Context	server configuration, virtual host, directory

Table 8-3 SSLCipher Suite Tags

Function	Tag	Meaning
Key exchange	`kRSA`	`RSA` key exchange
Key exchange	`kDHr`	Diffie-Hellman key exchange with RSA key
Authentication	`aNULL`	No authentication
Authentication	`aRSA`	`RSA` authentication
Authentication	`aDH`	Diffie-Hellman authentication
Encryption	`eNULL`	No encryption
Encryption	`DES`	`DES` encoding
Encryption	`3DES`	Triple `DES` encoding
Encryption	`RC4`	`RC4` encoding
Data Integrity	`MD5`	`MD5` hash function
Data Integrity	`SHA`	`SHA` hash function
Aliases	`SSLv3`	All SSL version 3.0 ciphers
Aliases	`EXP`	All export ciphers
Aliases	`EXP40`	All 40-bit export ciphers only
Aliases	`EXP56`	All 56-bit export ciphers only
Aliases	`LOW`	All low strength ciphers (export and single `DES`)
Aliases	`MEDIUM`	All ciphers with 128-bit encryption
Aliases	`HIGH`	All ciphers using triple `DES`
Aliases	`RSA`	All ciphers using `RSA` key exchange
Aliases	`DH`	All ciphers using Diffie-Hellman key exchange

Note:

There are restrictions if export versions of browsers are used. Oracle module, mod_ossl, supports RC4-40 encryption only when the server uses 512 bit key size wallets.

Table 8-4 Cipher Suites Supported in Oracle Advanced Security 9i

Cipher Suite	Authentication	Encryption	Data Integrity
`SSL_RSA_WITH_3DES_EDE_CBC_SHA`	`RSA`	`3DES EDE CBC`	`SHA`
`SSL_RSA_WITH_RC4_128_SHA`	`RSA`	`RC4 128`	`SHA`
`SSL_RSA_WITH_RC4_128_MD5`	`RSA`	`RC4 128`	`MD5`
`SSL_RSA_WITH_DES_CBC_SHA`	`RSA`	`DES CBC`	`SHA`
`SSL_DH_anon_WITH_3DES_EDE_CBC_SHA`	`DH anon`	`3DES EDE CBC`	`SHA`
`SSL_DH_anon_WITH_RC4_128_MD5`	`DH anon`	`RC4 128`	`MD5`
`SSL_RSA_WITH_3DES_EDE_CBC_SHA`	`RSA`	`3DES EDE CBC`	`SHA`
`SSL_DH_anon_WITH_DES_CBC_SHA`	`DH anon`	`DES CBC`	`SHA`
`SSL_RSA_EXPORT_WITH_RC4_40_MD5`	`RSA`	`RC4 40`	`MD5`
`SSL_RSA_EXPORT_WITH_DES40_CBC_SHA`	`RSA`	`DES40 CBC`	`SHA`
`SSL_DH_anon_EXPORT_WITH_RC4_40_MD5`	`DH anon`	`RC4 40`	`MD5`
`SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA`	`DH anon`	`DES40 CBC`	`SHA`

SSLEngine

Toggles the usage of the SSL Protocol Engine. This is usually used inside a <VirtualHost> section to enable SSL for a particular virtual host. By default, the SSL Protocol Engine is disabled for both the main server and all configured virtual hosts.

Example 8-8 Using SSL Engine Directive

<VirtualHost_dafault_:4443>
SSLEngine on
...
</VirtualHost>

Category	Value
Syntax	SSLEngine on\|off
Default	SSLEngine off
Context	server configuration, virtual host

SSLLog

Specifies where the SSL engine log file will be written. (Error messages will also be duplicated to the standard Oracle HTTP Server log file specified by the ErrorLog directive.)

Place this file at a location where only root can write, so that it cannot be used for symlink attacks. If the filename does not begin with a slash (/), it is assumed to be relative to the ServerRoot. If the filename begins with a bar (|), then the string following the bar is expected to be a path to an executable program to which a reliable pipe can be established.

This directive should occur only once for each virtual server configuration.

Category	Value
Syntax	`SSLVerifyClient` `path/to/filename`
Default	None
Context	server configuration, virtual host

SSLLogLevel

Specifies the verbosity degree of the SSL engine log file.

Category	Value
Valid Values	The levels are (in ascending order, where each level is included in the levels preceding it): `none`: No dedicated SSL logging is done. Messages of type 'error' are duplicated to the standard HTTP server log file specified by the `ErrorLog` directive. `error`: Only messages of the type 'error' (conditions that stop processing) are logged. `warn`: Messages that notify of non-fatal problems (conditions that do not stop processing) are logged. `info`: Messages that summarize major processing actions are logged. `trace`: Messages that summarize minor processing actions are logged. `debug`: Messages that summarize development and low-level I/O operations are logged.
Syntax	`SSLLogLevel` `level`
Default	None
Context	server configuration, virtual host

SSLMutex

Type of semaphore (lock) for SSL engine's mutual exclusion of operations that have to be synchronized between Oracle HTTP Server processes.

Category	Value
Valid Values	`none`: Uses no mutex at all. Not recommended, because the mutex synchronizes the write access to the SSL session cache. If you do not configure a mutex, the session cache can become garbled. `file:`path/to/mutex: Uses a file for locking. The process ID (PID) of the Oracle HTTP Server parent process is appended to the filename to ensure uniqueness. If the filename does not begin with a slash (/), it is assumed to be relative to `ServerRoot`. This setting is not available on Windows. `sem`: Uses an operating system semaphore to synchronize writes. On UNIX, it would be a Sys V IPC semaphore; on Windows, it is a Windows Mutex. This is the best choice, if the operating system supports it.
Example	`SSLMutex file``:/usr/local/apache/logs/ssl_mutex`
Syntax	`SSLMutex` `type`
Default	`SSLMutex` `none`
Context	server configuration

SSLOptions

Controls various runtime options on a per-directory basis. In general, if multiple options apply to a directory, the most comprehensive option is applied (options are not merged). However, if all of the options in an SSLOptions directive are preceded by a plus ('+') or minus ('-') symbol, then the options are merged. Options preceded by a plus are added to the options currently in force, and options preceded by a minus are removed from the options currently in force.

Category	Value
Valid Values	`StdEnvVars`: Creates the standard set of CGI/SSI environment variables that are related to SSL. This is disabled by default because the extraction operation uses a lot of CPU time and usually has no application when serving static content. Typically, you only enable this for CGI/SSI requests. `ExportCertData`: Enables the following additional CGI/SSI variables: `SSL_SERVER_CERT` `SSL_CLIENT_CERT` `SSL_CLIENT_CERT_CHAIN_n` (where n= 0, 1, 2...) These variables contain the Privacy Enhanced Mail (PEM)-encoded X.509 certificates for the server and the client for the current HTTPS connection, and can be used by CGI scripts for deeper certificate checking. All other certificates of the client certificate chain are provided. This option is "Off" by default because there is a performance cost associated with using it. `SSL_CLIENT_CERT_CHAIN_n` variables are in the following order: `SSL_CLIENT_CERT_CHAIN_0` is the intermediate CA who signs `SSL_CLIENT_CERT`. `SSL_CLIENT_CERT_CHAIN_1` is the intermediate CA who signs `SSL_CLIENT_CERT_CHAIN_0`, and so forth, with `SSL_CLIENT_ROOT_CERT` as the root CA. `FakeBasicAuth`: Translates the subject distinguished name of the client X.509 certificate into an HTTP basic authorization user name. This means that the standard HTTP server authentication methods can be used for access control. Note that no password is obtained from the user; the string 'password' is substituted.
Valid Values (for `SSLOptions` continued)	`StrictRequire`: Denies access when, according to `SSLRequireSSL` or `SSLRequire` directives, access should be forbidden. Without `StrictRequire`, it is possible for a '`Satisfy any'` directive setting to override the `SSLRequire` or `SSLRequireSSL` directive, allowing access if the client passes the host restriction or supplies a valid user name and password. Thus, the combination of `SSLRequireSSL` or `SSLRequire` with `SSLOptions +StrictRequire` gives `mod_ossl` the ability to override a `'Satisfy any'` directive in all cases. `CompatEnvVars`: Exports obsolete environment variables for backward compatibility to Apache SSL 1.x, `mod_ssl` 2.0.x, Sioux 1.0, and Stronghold 2.x. Use this to provide compatibility to existing CGI scripts. `OptRenegotiate`: This enables optimized SSL connection renegotiation handling when SSL directives are used in a per-directory context.
Syntax	`SSLOptions` [+-] `option`
Default	None
Context	server configuration, virtual host, directory

SSLPassPhraseDialog

Type of pass phrase dialog for wallet access. mod_ossl asks the administrator for a pass phrase in order to access the wallet.

Category	Value
Valid Values	`builtin`: when the server is started, `mod_ossl` prompts for a password for each wallet. This cannot be used when Oracle HTTP Server is managed by OPMN. No user interaction is allowed when Oracle HTTP Server is started by OPMN. `exec:`path/to/program - when the server is started, `mod_ossl` calls an external program configured for each wallet. This program is invoked with two arguments: servername:portnumber and `RSA` or `DSA`.
Syntax	`SSLPassPhraseDialog` type
Example	`SSLPassPhraseDialog exec:``/usr/local/apache/sbin/pfilter`
Default	`SSLPassPhraseDialog` `builtin`
Context	server configuration

SSLProtocol

Specifies SSL protocol(s) for mod_ossl to use when establishing the server environment. Clients can only connect with one of the specified protocols.

Category	Value
Valid Values	`SSLv3` SSL version 3.0
Example	To specify only SSL version 3.0, set this directive to the following: `SSLProtocol` `+SSLv3`
Syntax	`SSLProtocol``[+-] protocol`
Default	`SSLProtocol +SSLv3`
Context	server configuration, virtual host

SSLRequire

Denies access unless an arbitrarily complex boolean expression is true. The expression must match the following syntax (given as a BNF grammar notation):

Category	Value
	expr ::= "true" \| "false" "!" expr expr "&&" expr expr "\|\|" expr "(" expr ")"
	comp ::=word "==" word \| word "eq" word word "!=" word \|word "ne" word word "<" word \|word "lt" word word "<=" word \|word "le" word word ">" word \|word "gt" word word ">=" word \|word "ge" word word "=~" regex word "!~" regex wordlist ::= word wordlist "," word
	word ::= digit cstring variable function
	digit ::= [0-9]+
	cstring ::= "..."
	variable ::= "%{varname}" Table 8-5 and Table 8-6 list standard and SSL variables. These are valid values for varname.
	function ::= funcname "(" funcargs ")" For funcname, the following function is available: file(filename) The file function takes one string argument, the filename, and expands to the contents of the file. This is useful for evaluating the file's contents against a regular expression.
Syntax	`SSLRequire` `expression`
Default	None
Context	directory

Table 8-5 lists the standard variables for SSLRequire varname.

Table 8-5 Standard Variables for SSLRequire Varname

Standard Variables	Standard Variables	Standard Variables
`HTTP_USER_AGENT`	`PATH_INFO`	`AUTH_TYPE`
`HTTP_REFERER`	`QUERY_STRING`	`SERVER_SOFTWARE`
`HTTP_COOKIE`	`REMOTE_HOST`	`API_VERSION`
`HTTP_FORWARDED`	`REMOTE_IDENT`	`TIME_YEAR`
`HTTP_HOST`	`IS_SUBREQ`	`TIME_MON`
`HTTP_PROXY_CONNECTION`	`DOCUMENT_ROOT`	`TIME_DAY`
`HTTP_ACCEPT`	`SERVER_ADMIN`	`TIME_HOUR`
`HTTP:headername`	`SERVER_NAME`	`TIME_MIN`
`THE_REQUEST`	`SERVER_PORT`	`TIME_SEC`
`REQUEST_METHOD`	`SERVER_PROTOCOL`	`TIME_WDAY`
`REQUEST_SCHEME`	`REMOTE_ADDR`	`TIME`
`REQUEST_URI`	`REMOTE_USER`	`ENV:variablename`
`REQUEST_FILENAME`

Table 8-6 lists the SSL variables for SSLRequire varname.

Table 8-6 SSL Variables for SSLRequire Varname

SSL Variables	SSL Variables	SSL Variables
`HTTPS`	`SSL_PROTOCOL`	`SSL_CIPHER_ALGKEYSIZE`
`SSL_CIPHER`	`SSL_CIPHER_EXPORT`	`SSL_VERSION_INTERFACE`
`SSL_CIPHER_USEKEYSIZE`	`SSL_VERSION_LIBRARY`	`SSL_SESSION_ID`
`SSL_CLIENT_V_END`	`SSL_CLIENT_M_SERIAL`	`SSL_CLIENT_V_START`
`SSL_CLIENT_S_DN_ST`	`SSL_CLIENT_S_DN`	`SSL_CLIENT_S_DN_C`
`SSL_CLIENT_S_DN_CN`	`SSL_CLIENT_S_DN_O`	`SSL_CLIENT_S_DN_OU`
`SSL_CLIENT_S_DN_G`	`SSL_CLIENT_S_DN_T`	`SSL_CLIENT_S_DN_I`
`SSL_CLIENT_S_DN_UID`	`SSL_CLIENT_S_DN_S`	`SSL_CLIENT_S_DN_D`
`SSL_CLIENT_I_DN_C`	`SSL_CLIENT_S_DN_Email`	`SSL_CLIENT_I_DN`
`SSL_CLIENT_I_DN_O`	`SSL_CLIENT_I_DN_ST`	`SSL_CLIENT_I_DN_L`
`SSL_CLIENT_I_DN_T`	`SSL_CLIENT_I_DN_OU`	`SSL_CLIENT_I_DN_CN`
`SSL_CLIENT_I_DN_S`	`SSL_CLIENT_I_DN_I`	`SSL_CLIENT_I_DN_G`
`SSL_CLIENT_I_DN_Email`	`SSL_CLIENT_I_DN_D`	`SSL_CLIENT_I_DN_UID`
`SSL_CLIENT_CERT`	`SSL_CLIENT_CERT_CHAIN_n`	`SSL_CLIENT_ROOT_CERT`
`SSL_CLIENT_VERIFY`	`SSL_CLIENT_M_VERSION`	`SSL_SERVER_M_VERSION`
`SSL_SERVER_V_START`	`SSL_SERVER_V_END`	`SSL_SERVER_M_SERIAL`
`SSL_SERVER_S_DN_C`	`SSL_SERVERT_S_DN_ST`	`SSL_SERVER_S_DN`
`SSL_SERVER_S_DN_OU`	`SSL_SERVER_S_DN_CN`	`SSL_SERVER_S_DN_O`
`SSL_SERVER_S_DN_I`	`SSL_SERVER_S_DN_G`	`SSL_SERVER_S_DN_T`
`SSL_SERVER_S_DN_D`	`SSL_SERVER_S_DN_UID`	`SSL_SERVER_S_DN_S`
`SSL_SERVER_I_DN`	`SSL_SERVER_I_DN_C`	`SSL_SERVER_S_DN_Email`
`SSL_SERVER_I_DN_L`	`SSL_SERVER_I_DN_O`	`SSL_SERVER_I_DN_ST`
`SSL_SERVER_I_DN_CN`	`SSSL_SERVER_I_DN_T`	`SSL_SERVER_I_DN_OU`
`SSL_SERVER_I_DN_G`	`SSL_SERVER_I_DN_I`

SSLRequireSSL

Denies access to clients not using SSL. This is a useful directive for absolute protection of a SSL-enabled virtual host or directories in which configuration errors could create security vulnerabilities.

Category	Value
Syntax	`SSLRequireSSL`
Default	None
Context	directory

SSLSessionCache

Specifies the global/interprocess session cache storage type. The cache provides an optional way to speed up parallel request processing.

Category	Value
Valid Values	`none`: disables the global/interprocess session cache. Produces no impact on functionality, but makes a major difference in performance. `shmht:`/path/to/datafile[bytes]: Uses a high-performance hash table (`bytes` specifies approximate size) inside a shared memory segment in RAM, which is established by the `/path/to/datafile`. This hash table synchronizes the local SSL memory caches of the server processes. `shmcb:`/path/to/datafile[bytes]: Uses a high-performance Shared Memory Cyclic Buffer (SHMCB) session cache to synchronize the local SSL memory caches of the server processes. The performance of `shmcb` is more uniform in all environments when compared to `shmht`.
Syntax	`SSLSessionCache` `type`
Examples	`SSLSessionCache shmht:` `/``ORACLE_HOME``/Apache/Apache/logs/ssl_scache(512000)` `SSLSessionCache shmcb: /``ORACLE_HOME``/Apache/Apache/logs/ssl_scache(512000)`
Default	`SSLSessionCache` none

SSLSessionCacheTimeout

Specifies the number of seconds before a SSL session in the session cache expires.

Category	Value
Syntax	`SSLSessionCacheTimeout` `seconds`
Default	300
Context	server configuration

SSLVerifyClient

Specifies whether or not a client must present a certificate when connecting.

Category	Value
Valid Values	`none`: No client certificate is required `optional`: Client may present a valid certificate `require`: Client must present a valid certificate
Syntax	`SSLVerifyClient` `level`
Default	None
Context	server configuration, virtual host

Note:

The level optional_no_ca included with mod_ssl (in which the client can present a valid certificate, but it need not be verifiable) is not supported in mod_ossl.

SSLWallet

Specifies the location of the wallet with its WRL.

Category	Value
Syntax	`SSLWallet` `wrl` The format of `wrl` is: `file:path to wallet`
Example	`SSLWallet` `file:/etc/``ORACLE/WALLETS/``server` Other values of wrl may be used as permitted by the Oracle SSL product.
Default	None
Context	server configuration, virtual host

SSLWalletPassword

Specifies the Wallet password needed to access the wallet specified within the same context. You can choose either a cleartext wallet password or an obfuscated password. The obfuscated password is created with the command line tool iasobf. If you must use a regular wallet, Oracle recommends that you use the obfuscated password instead of a cleartext password.

See Also:

"Using the iasobf Utility"

Category Value

Category	Value
Syntax	`SSLWalletPassword` `password` If no password is required do not set this directive. Note: If a wallet created with the Auto Login feature of Oracle Wallet Manager is used, then do not set this directive because these wallets do not require passwords.
Default	None
Context	server configuration, virtual host

Syntax

SSLWalletPassword password

If no password is required do not set this directive.

Note: If a wallet created with the Auto Login feature of Oracle Wallet Manager is used, then do not set this directive because these wallets do not require passwords.

Default

None

Context

server configuration, virtual host

Note:

SSLWalletPassword has been deprecated. A warning message is generated in the Oracle HTTP Server log if this directive is used.

For secure wallets, Oracle recommends that you get a SSO wallet instead. Refer to the Oracle Application Server 10g Security Guide for information on SSO wallet.

Using mod_proxy Directives

The following directives are for mod_proxy support only:

SSLProxyCache

Specifies whether the proxy cache will be used. The proxy will use the same session as the SSL server uses.

Category	Value
Syntax	`SSLProxyCache` `on/off`
Default	`SSLProxyCache off`
Context	server configuration, virtual host

SSLProxyCipherSuite

Specifies the proxy server's cipher suite.

Category	Value
Syntax	`SSLCipherSuite` `cipher-spec`
Default	`None`
Context	server configuration, virtual host

SSLProxyProtocol

Controls the proxy server's SSL protocol flavors.

Category	Value
Syntax	`SSLProxyProtocol [+-]` `protocol`
Default	`None`
Context	server configuration, virtual host

SSLProxyWallet

Specifies the location of the wallet containing the certificates to use when opening proxy connections.

Category	Value
Syntax	`SSLProxyWallet` `wrl`
Default	`None`
Context	server configuration, virtual host

SSLProxyWalletPassword

Specifies the proxy wallet password.

Category	Value
Syntax	`SSLProxyWalletPassword` `password`
Default	`None`
Context	server configuration, virtual host

Note:

SSLProxyWalletPassword has been deprecated. A warning message is generated in the Oracle HTTP Server log if this directive is used.

For secure wallets, Oracle recommends that you get a SSO wallet instead.

Refer to the Oracle Application Server 10g Security Guide for information on SSO wallet.

Using mod_ossl Directives to Configure Client Authentication

This section provides instructions on how you can use the directives mentioned earlier to set up configurations that enable you to use client certificates for authenticating clients. Following are some scenarios:

Authenticating clients based on certificates when all clients are known.

The server wallet has imported the CA certificate which signed all the client certificates.

For example, specify the following directives in the httpd.conf file:
```
SSLVerifyClient require
```
Authenticating for a particular URL based on certificates, while allowing arbitrary clients to access the rest of the server

To enable this, use the per-directory reconfiguration feature of mod_ossl. Session re-negotiation enables an SSL session to be re-negotiated with a client after the initial request and URL have been read. This is only supported for requests that do not contain body data, such as GET requests.
See Also:

"Classes of Directives" for more information.

mod_ssl documentation.
For example, specify the following directives in the httpd.conf file:
```
<Location /secure/area>
```
```
      SSLVerifyClient require

</Location>
```

Using the iasobf Utility

The iasobf utility enables you to generate an obfuscated wallet password from a cleartext password.

If you are using an Oracle Wallet that has been created with Auto Login enabled (an SSO wallet), then you do not need to use this utility. However, if you must use a regular wallet with a password, then Oracle recommends that you use the password obfuscation tool iasobf, which is located in ORACLE_HOME/Apache/Apache/bin, to generate an obfuscated wallet password from a cleartext password.

To generate an obfuscated wallet password, the command syntax is:

iasobf -p password

The obfuscated password is printed to the terminal. The arguments are optional. If you do not type them, the tool will prompt you for the password.

On Windows systems:

The corresponding tool for Windows environments is called osslpassword, which can be used in the same way as iasobf.

8 Managing Security

About Oracle HTTP Server Security

Figure 8-1 Steps for Handling URL Requests in Oracle HTTP Server

Classes of Users and Their Privileges

Resources Protected

Authentication and Authorization Enforcement

Host-based Access Control

Example 8-1 Host-based Access Control

Access Control for Virtual Hosts

Example 8-2 Using AccessConfig to Set Up Access Control

Using mod_access and mod_setenvif for Host-based Access Control

Controlling Access by IP Address

Example 8-3 Controlling Access by IP Address

Controlling Access by Domain Name

Example 8-4 controlling Access by Domain Name

Controlling Access by Network or Netmask

Example 8-5 Controlling Access by Network or Netmask

Controlling Access with Environment Variables

Example 8-6 Controlling Access with Environment Variables

Example 8-7 Controlling Access with SetEnv

User Authentication and Authorization

Using mod_auth to Authenticate Users

Table 8-1 Directives Descriptions

Using mod_ossl to Authenticate Users

Enabling SSL

Security Services Implemented Within Oracle HTTP Server

Using mod_ossl

Table 8-2 Differences between mod_ossl and mod_ssl

Using mod_ossl Directives

SSLAccelerator

SSLCARevocationFile

SSLCARevocationPath

SSLCipherSuite

Table 8-3 SSLCipher Suite Tags

Table 8-4 Cipher Suites Supported in Oracle Advanced Security 9i

SSLEngine

Example 8-8 Using SSL Engine Directive

SSLLog

SSLLogLevel

SSLMutex

SSLOptions

SSLPassPhraseDialog

SSLProtocol

SSLRequire

Table 8-5 Standard Variables for SSLRequire Varname

Table 8-6 SSL Variables for SSLRequire Varname

SSLRequireSSL

SSLSessionCache

SSLSessionCacheTimeout

SSLVerifyClient

SSLWallet

SSLWalletPassword

Using mod_proxy Directives

SSLProxyCache

SSLProxyCipherSuite

SSLProxyProtocol

SSLProxyWallet

SSLProxyWalletPassword

Using mod_ossl Directives to Configure Client Authentication

Using the iasobf Utility

8
Managing Security