8
Man aging Security

This chapter provides an overview of Oracle HT TP 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 Protect ed
Authentication and Authorization Enforceme nt
Security Services Implemented Within Oracl e 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 an d mod_access, and the Oracle modules, mod_ossl. mod_auth provides authentication based on user name and password pairs, mod_access controls acce ss to the server based on the characteristics of a request, such as hostname or IP address, mod_ossl provides confidenti ality and authentication with X.509 client certificates over SSL.

Based on the Apache model, Oracle HTTP Server provides access control, authentication, and aut horization 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 an d configuration parameters. The steps for handling URL requests are implemented through a module or plug-in architecture that is comm on to many Web listeners.


 
Figure 8-1 shows how URL re
quests 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 descr
iption 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. Followi
ng 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 unprotect
ed resources only.
Users that have been authenticated and potentially authoriz
ed by modules within Oracle HTTP Server. This includes users authenticated by mod_auth and mod_ossl. Such u
sers have access to URLs defined in http.conf file. 




See Also:  
"Authent
ication and Authorization Enforcement"
<
/a> 
Resources Protected

 
Oracle HTTP Server is configured to protect resources such as:

Static content such as static HTML pages, graphics interchange format, .g
if, 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_pe
rl, mod_dms generate responses that are returned to the client.
 
Authenticatio
n and Authorization Enforcement

 
Oracle HTTP Server provides user aut
hentication and authorization at two stages:

Host-based Access Control (stage one): This is based on the details of the incoming HTT
P request and its headers, such as IP addresses or host names.
User Authentication and Authorization (stage two): This is based on different criteri
a depending on the HTTP server configuration. The server can be configured to authenticate users with user name and password pairs th
at are checked against a list of known users and passwords.
 
<
font face="Arial, Helvetica, sans-serif" color="#330099">Host-based Access Control



Early in the request processing cycle, access control is applied, which can inhibit further processing based on the ho
st name, IP address, or other characteristics such as browser type. You use the deny, allow, and orde
r directives to set this type of access control. These restrictions are configured with Oracle HTTP Server configuration direc
tives and can be based on particular files, directories, or URL formats using the <Files><
/a>, <Directory>, and <Location&
gt; container directives as shown in the Example 8-1:
 
Example 8-1 Host-based Access Control
<Directory /internalonly/>
  order deny, allow
  deny from all
<
a name="1011029">  allow from 192.168.1 us.oracle.com
</Directory>




In Example 8-1, the order directive determines t
he order in which Oracle HTTP Server reads the conditions of the deny and allow directives. The deny<
/code> 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 direc
tory /internalonly/. It is common practice to specify both allow and deny in host-based authen
tication to make the access policy explicit.

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





Note:  
Allowing or restricting access ba
sed on a host name for Internet access is not considered a very good method of providing security, because host names are easy to spo
of. While the same is true of IP addresses, sabotage is more difficult. However, setting access control with intranet IP address rang
es 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 contr
ol 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 w
hich 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 o
n 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 HTT
P request header contents.

 
You can use host-based access control to protect static HTML pag
es, applications, or components.
 
Oracle HTTP Server supports four host-based access control
 schemes:

Controlling Access by I
P Address
Controlling Access by Domain Name

Controlling Access by Network or Netmask
Controlling Access with Environment Variables<
/li>
 
All of these allow you to specify the machines from which access to protected areas i
s 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 a
ccess control. It does not require DNS lookups that consume time, system resources, and make your server vulnerable to DNS spoofing a
ttacks.
 
Example 8-3 Controlling Access by IP
 Address
<Directory /secure_only/>
  order deny,al
low
  deny from all
  allow from 207.175.42.*
</Directory>




In Example 8-3, requests orig
inating from all IP addresses except 207.175.42.* range are denied access to the /secure_only/ directory.
 
Controlling Access by D
omain Name

 
Domain name-based access control can be used with IP addr
ess-based access control to solve the problem of IP addresses changing without warning. When you combine these methods, if an IP addr
ess changes, then the secure areas of your site are still protected because the domain names you want to keep out will still be denie
d 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 addre
ss 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, spe
cified 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&n
bsp;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 address
es 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 use
d 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. Fo
r 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:
 
Examp
le 8-6 Controlling Access with Environment Variables
BrowserMatch ^Mozilla net
scape_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 synt
ax 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 brows
er 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 t
he browser receives this response, it prompts for a user name and password. After the user enters a user name and password combinatio
n, the browser sends this information back to the server in an Authorization header. In the authorization header message, the user na
me and password are encoded as a base 64 encoded string.
 
User authorization involves checki
ng the authenticated user against an access control list that is associated with a specific server resource such as a file or directo
ry. To configure user authorization, place the require directive in the httpd.conf file, usually within a v
irtual host container. User authorization is commonly used in combination with user authentication. After the server has authenticate
d a user's user name and password, then the server compares the user to an access control list associated with the requested server r
esource. 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_aut
h to Authenticate Users

 
User authentication is based on user names a
nd passwords that are checked against a list of known users and passwords. These user name and password pairs may be stored in a vari
ety 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 se
t up basic authentication. It supports only files.
 
Any authentication scheme that you devis
e 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_os
sl 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 a
pplication 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 serv
er. This case does not preclude the use of non-secured HTTP. The secure version is simply HTTP over SSL (named HTTPS). The difference
s are that HTTPS uses the URL scheme https:// rather than http://, and its default communication port is 44
43.
 
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 detai
led information regarding mod_ossl.
 

<
h4 class="H3">Enabling SSL

Secur
ity Services Implemented Within Oracle HTTP Server

 
Oracle HTTP Serve
r provides security services that enable you to protect your server from unwanted users and malicious attacks. These security service
s 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 als
o 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 secur
e 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 usin
g 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 Differen
ces 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 c
ertificates 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.

 <
!--TOC=h3-"1020598"-->
Using mod_ossl Directives


 
To configure SSL for your Oracle HTTP Server, enter the mod_ossl d
irectives you want to use in the httpd.conf file.
 
The following directive are
described in subsequent sections:

SSLAccelerator
SSLCARevocationFile
SSLCARevocationPath
SSLCipherSuite
SSLEngine
SSLLog<
/li>
SSLLogLevel

SSLMutex
SSLOptions
SSLPassPhraseDialog

SSLProtocol
SSLRequire
SSLRequireSSL
SSLSessio
nCache
SSLSessionCacheTimeout
SSLVerifyClient
SSLWallet
SSLWalletPassword
 
SSLAcceler
ator
 
Specifies if SSL accelerator is used. Currently only nFast card is supported.<
/p>
 
<
/tr>



 Category
 Value


 
Valid Values
 
yes/no

 
Syntax
 

SSLAccelerator yes|no

 
Default
 
SSLAccelerator no

 
Context
 
server configuration

SSLCARevocationFile
 
Sp
ecifies 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 fil
e is the concatenation of various PEM-encoded CRL files in order of p
reference. 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


 
Defa
ult
 
None

 
Context
 
server configuration, virtual host

SSLCARevocationPath
 
Specifies the directory where PEM-encoded Certificate Revocation Lists (CRLs) are stored. These CRLs com
e 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 a
nd the client cannot authenticate itself with your server.
 
 
Value
SSLCipherSuite
Specifies the SSL cipher suite that the cl
ient 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



 
Syntax
 
SSLCARevocationPath path/to/CRL_directory/

 
Example
 
SSLCARevocationPath /
ORACLE_HOME/Apache/conf/ssl.crl/

 
Default
 
None

 
C
ontext
 
server configuration, virtual host



 


 

 



 Category
 Value


 
Valid Values
 
none: Adds the cipher to the list 
+ : Ad
ds 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 fr
om the list permanently

 
Example
 
SSLCipherSuite ALL:!LO
W:!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  

 
aRSA



 Function
 Tag
 Meaning

 
Key exchange
 
kRSA
 
RSA key exchange

 
Key exchange
 
kDHr
 
Diffie-Hellman key exchange with RSA key

 
Authentication

 
aNULL
 
No authentication 

 
Authentication
 
RSA authentication

 
Authentication
 
aDH
 
Diffie-Hellman authentication

 
Encryption
 
eNULL
 
No encryption

 
Encryption

 
DES
 
DES encoding

 
En
cryption
 
3DES
 
Triple DES encoding

 
Encryption
 
RC4
 
RC4 encoding

 
Data Integrity
 
MD5
 
MD5 hash
function

 
Data In
tegrity
 
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

<
a name="1020935"> 
Aliases
 
HIGH<
/td>
 
All ciphers using triple DES

 
Aliases
 
RSA
 
All ciphers using RSA key exchange

 
Aliases
 
DH
 
All ciphers using Diffie-Hellman key exchange






Note:  
The
re are restrictions if export versions of browsers are used. Oracle module, mod_ossl, supports RC4-40 encryption only wh
en the server uses 512 bit key size wallets.


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

<
th class="Formal" align="left" valign="bottom" scope="col">E
ncryption


 Cipher Suite
 Authentication 
 Data Integrity



 
SSL_RSA_WITH_3DES_EDE_CBC_SHA
 
RSA
 
3DES EDE C
BC
 
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<
/p>
 
RSA

 
DES CBC
 
SHA


 
SSL_DH_anon_WITH_3DES_E
DE_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<
/p>
 
DH anon

 
RC4 40
 
MD5 

 
SSL_DH_anon_EXPORT_W
ITH_DES40_CBC_SHA
 
DH anon
 
DES40 CBC
 
SHA

SSLEngine
 
Toggles the usage of the SSL Protocol Engine. This is usually used ins
ide a <VirtualHost> section to enable SSL for a particular virtual host. By default, the SSL Protocol Engine is di
sabled for both the main server and all configured virtual hosts.
 
Example 8-8 Using SSL Engine Directive
<VirtualHost_d
afault_: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 s
pecified 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.
 
<
/tr>



 Category
 Value


 
Syntax
 
SSLVerifyClient path/to/filename

 
Default

 
None

 
<
p class="TB">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 actio
ns are logged.
trace: Messages that summarize minor processing ac
tions 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.
 

<
td class="Informal">SSLMutex none



 Category
 Value


 
Valid Values


none: Uses no mutex at all. Not recommended, because the mutex sync
hronizes 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_mut
ex

 
Syntax
 
SSLMutex type

 
Default 


 
Context

 
server configuration

SSLOptions
 
Controls various runtime opt
ions on a per-directory basis. In general, if multiple options apply to a directory, the most comprehensive option is applied (option
s 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
 V
alue


 
Valid Values


<
code>StdEnvVars: Creates the standard set of CGI/SSI environment variables that are related to SSL. This is disabled by defaul
t 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 th
e 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 a
re 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 t
he 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 di
stinguished 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 SSLRequi
re 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 comb
ination 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 directi
ves are used in a per-directory context.

 
Syntax
 
SSLOptions
 [+-] option

 
Default
 
None

 
Context
 
server configuration, virtual host, directory
<
/a>

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

<
tr class="Informal" align="left" valign="top">
 
Default



 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:port
number and RSA or DSA.

 
Syntax
 
SSLPassPh
raseDialog type

 
Example
 
SSLPassPhraseDia
log exec:/usr/local/apache/sbin/pfilter

 

SSLPassPhraseDialog builtin

 
Context
 
server
 configuration


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

<
th class="Informal" align="left" valign="bottom" scope="col">Category

 
 Value


 
Valid Values
 
SSLv3 
SSL version 3.0

 
Example
 
To specify only SSL version 3.0, set this directive to the following: 
SSLPro
tocol +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):
 

<
tr class="Informal" align="left" valign="top">



 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&
nbsp;8-5 and Table 8-6 list standard and SSL variables. These are valid values for varname.


 
 <
/td>

function ::= funcname "(" funcargs ")"




For funcname, the following function is available:
<
/a>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 expressio
n.

 
Syntax
 
SSLRequire expression 

 
Default
 
None

 
Context
 
directory<
/p>

Table 8-5 lists the s
tandard variables for SSLRequire varname.
 
 Table 8-5 Standard Variables for SSL
Require Varname  

<
th class="Formal" align="left" valign="bottom" scope="col">Standard Variables



 
Standard Variables 

 
Standard Variables<
/font>


 
HTTP_USER_AGENT
 
PATH_INFO

 
AUTH_TYPE

 
HTTP_REFERER
 
QUERY_STRING
 
SERVER_SOFT
WARE

 
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_NA
ME
 
TIME_MIN

 
THE_REQUEST
 
SERVER_PORT
 
TIME_SEC

 
REQUEST_METHOD
 
SERVER_PROTOCOL
 
TIME_WDAY

 
REQUEST_SCHEME
 
REMOTE_ADDR
 
TIME

 
REQUES
T_URI
 
REMOTE_USER
<
a name="1026586"> 
ENV:variablename

 
REQUEST_FILENAME
 
 
 
 

Table 8-6 lists the SSL variables for SSLRequire varname.
 
 <
strong>Table 8-6 SSL Variables for SSLRequire Varname  

<
td class="Formal">SSL_SERVER_S_DN_OU



 
SSL Variables
 
SSL Variables
 
SSL Variables


 
HTTPS
 
SSL_PROTOCOL
 
SSL_CIP
HER_ALGKEYSIZE

 
SSL_CIPHER
 
SSL_CIPHER_EXPORT
 
SSL_VERSION_INTERFACE

 
SSL_CIPHER_USEKEYSIZE
 
SSL_VERSION_LIBRARY
 
<
p class="TB">SSL_SESSION_ID

 
SSL_CLIENT_V_END
 
SSL_CL
IENT_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_Ema
il
 
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_CLIE
NT_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<
/td>

 
SSL_SERVER_S_D
N_C
 
SSL_SERVERT_S_DN_ST
 
SSL_SERVER_S_DN
 

 
SSL_SERVER_S_DN_CN
 
SSL_SERV
ER_S_DN_O

 
SSL_SERVER_S_DN_I
 
SSL_SERVER_S_DN_G<
/td>
 
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 n
ot 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 w
ay to speed up parallel request processing.
 



 Category
 Value<
/font>


 
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 establis
hed 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-per
formance Shared Memory Cyclic Buffer (SHMCB) session cache to synchronize the local SSL memory caches of the server processes. The pe
rformance 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
 
SS
LSessionCache none

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



 Category
 Value


 
Syn
tax
 
SSLSessionCacheTimeout seconds<
/em>

 
Default

 
300

 
Context
 
server configuration

SSLVerifyClient
 
Specifies whether or not a client must present a certific
ate when connecting.
 



 Category
 Value


 
Valid Values



none: No client certifica
te is required
optional: Client may present a valid certificate
require: Client must present a valid certificate

 
Syntax
 
SSLVerifyClient level

 
Default
 
None

 
Context
 
server configuration, vi
rtual 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<
/td>
 
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 confi
guration, 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 obfusca
ted password. The obfuscated password is created with the command line tool iasobf. If you must use a regular wallet, Or
acle recommends that you use the obfuscated password instead of a cleartext password.
 



See Also:  
"Using the iasobf Utility"

<
table summary="" class="RuleInformal" border="1" width="100%" cellpadding="3" cellspacing="0" dir="ltr" title="">


 Category
 Value


 
Syntax
 
SSLWalletPassword password 
If no password is req
uired do not set this directive. 
Note: If a wallet created with the Auto Login feature of Or
acle Wallet Manager is used, then do not set this directive because these wallets do not require passwords.

 
Default
 
None

 
Context
 
server configuration, vir
tual 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, Oracl
e recommends that you get a SSO wallet instead. Refer to the Oracle Application Server 10g Security Guide for information on SSO wallet.

 

Us
ing mod_proxy Directives

 
The following directives are for mod_proxy support only:


SSLProxyCache
SS
LProxyCipherSuite
SSLProxyProtocol
<
li class="LB1" type="disc">SSLProxyWallet
SSLProxyWalletPassword
 
SSLProxyCache
 
Specifies whether the proxy cache w
ill be used. The proxy will use the same session as the SSL server uses.
 



 Category<
/font>
 Value


 
Syntax
 
SSLProxyCache on/off

 
Default
 
SSLProxyCache off<
/td>

 
Context

 
server configuration, virtual host

SSLProxyCipherSuite
 
Specifies the proxy server's cipher suite.
 

<
th class="Informal" align="left" valign="bottom" scope="col">Value


 Category  


 
Syntax
 
SSLCipherSuite cipher-spec



Default
 
None

 
Context
 
server configuration, virtual host

SSLProxyProtocol
 
Contro
ls the proxy server's SSL protocol flavors.
 



 Category
 Value<
/font>


 
Syntax
 
SSLProxyProtocol [+-] protoc
ol

 
Default
 
None

 
Context
 
server configuration, virtual host

SSLProxyWallet
 
Specifies the locati
on of the wallet containing the certificates to use when opening proxy connections.
 



 Categor
y
 Value


 
Syntax
 
SSLPr
oxyWallet wrl

 
Default
 
None


 
Context
 
server configuration, virtual host

SSLProxyWalletPassword

 
Specifies the proxy wallet password.
 



 Category
 Value<
/strong>



 
Syntax
 
SSLProxyWalletPassword password

 
<
p class="TB">Default
 
None

 
Context

 
server configuration, virtual host






Note:  
SSLP
roxyWalletPassword 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 Applic
ation Server 10g Security Guide for information on SSO wallet.


 

Using mod_ossl Directives
to Configure Client Authentication

 
This section provides instruction
s on how you can use the directives mentioned earlier to set up configurations that enable you to use client certificates for authent
icating 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:
SSLV
erifyClient require



Authen
ticating for a particular URL based on certificates, while allowing arbitrary clients to access the rest of the server 
<
a name="1021874">
To enable this, use the per-directory reconfiguration feature of mod_ossl. Sess
ion 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 passw
ord 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 too
l iasobf, which is located in ORACLE_HOME/Apache/Apache/bin, to generate an obfuscate
d 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 environm
ents is called osslpassword, which can be used in the same way as iasobf.
<
/div>









Previous


Next


Copyright © 2003 Oracle Corporation<
br>
All Rights Reserved.





Home


Book List



Contents


Index


Master Index<
/font>


Feedback

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.

Cipher Suite	Authentication	Data Integrity
`SSL_RSA_WITH_3DES_EDE_CBC_SHA`	`RSA`	`3DES EDE C BC`	`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`< /p>	`RSA`	`DES CBC`	`SHA`
`SSL_DH_anon_WITH_3DES_E DE_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`< /p>	`DH anon`	`RC4 40`	`MD5`
`SSL_DH_anon_EXPORT_W ITH_DES40_CBC_SHA`	`DH anon`	`DES40 CBC`	`SHA`

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:port number and `RSA` or `DSA`.
Syntax	`SSLPassPh raseDialog` type
Example	`SSLPassPhraseDia log exec:``/usr/local/apache/sbin/pfilter`
`SSLPassPhraseDialog` `builtin`
Context	server configuration

Standard Variables	Standard Variables< /font>
`HTTP_USER_AGENT`	`PATH_INFO`	`AUTH_TYPE`
`HTTP_REFERER`	`QUERY_STRING`	`SERVER_SOFT WARE`
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_NA ME`	`TIME_MIN`
`THE_REQUEST`	`SERVER_PORT`	TIME_SEC
`REQUEST_METHOD`	`SERVER_PROTOCOL`	`TIME_WDAY`
`REQUEST_SCHEME`	`REMOTE_ADDR`	`TIME`
`REQUES T_URI`	`REMOTE_USER`	< a name="1026586"> `ENV:variablename`
`REQUEST_FILENAME`

SSL Variables	SSL Variables	SSL Variables
`HTTPS`	`SSL_PROTOCOL`	`SSL_CIP HER_ALGKEYSIZE`
`SSL_CIPHER`	`SSL_CIPHER_EXPORT`	`SSL_VERSION_INTERFACE`
`SSL_CIPHER_USEKEYSIZE`	`SSL_VERSION_LIBRARY`	< p class="TB">`SSL_SESSION_ID`
`SSL_CLIENT_V_END`	`SSL_CL IENT_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_Ema il`	`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_CLIE NT_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` < /td>
`SSL_SERVER_S_D N_C`	`SSL_SERVERT_S_DN_ST`	`SSL_SERVER_S_DN`
`SSL_SERVER_S_DN_CN`	`SSL_SERV ER_S_DN_O`
`SSL_SERVER_S_DN_I`	`SSL_SERVER_S_DN_G` < /td>	`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`

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

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

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

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

Category	Value
Valid Values	`none`: Adds the cipher to the list `+` : Ad ds 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 fr om the list permanently
Example	`SSLCipherSuite` `ALL:!LO W:!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

Function	Tag	Meaning
Key exchange	`kRSA`	`RSA` key exchange
Key exchange	`kDHr`	Diffie-Hellman key exchange with RSA key
Authentication	`aNULL`	No authentication
Authentication	`RSA` authentication
Authentication	`aDH`	Diffie-Hellman authentication
Encryption	`eNULL`	No encryption
Encryption	`DES`	`DES encoding`
En cryption	`3DES`	Triple `DES` encoding
Encryption	`RC4`	`RC4` encoding
Data Integrity	`MD5`	`MD5` hash function
Data In tegrity	`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
< a name="1020935"> Aliases	`HIGH` < /td>	All ciphers using triple `DES`
Aliases	`RSA`	All ciphers using RSA key exchange
Aliases	`DH`	All ciphers using Diffie-Hellman key exchange

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

Category	Value
Syntax	`SSLVerifyClient` `path/to/filename`
Default	None
< p class="TB">Context	server configuration, virtual host

~~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 actio ns are logged. `trace`: Messages that summarize minor processing ac tions 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

Category	Value
Valid Values	`none`: Uses no mutex at all. Not recommended, because the mutex sync hronizes 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_mut ex`
Syntax	`SSLMutex` `type`
Default
Context	server configuration

Category	V alue
Valid Values	< code>StdEnvVars: Creates the standard set of CGI/SSI environment variables that are related to SSL. This is disabled by defaul t 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 th e 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 a re 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 t he 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 di stinguished 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 `SSLRequi re` 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 comb ination 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 directi ves are used in a per-directory context.`
Syntax	`SSLOptions` [+-] `option`
Default	None
Context	server configuration, virtual host, directory

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

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& nbsp;8-5 and Table 8-6 list standard and SSL variables. These are valid values for varname.
< /td>	function ::= funcname "(" funcargs ")" For funcname, the following function is available: < /a>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 expressio n.
Syntax	`SSLRequire` `expression`
Default	None
Context	directory< /p>

Category	Value< /font>
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 establis hed 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-per formance Shared Memory Cyclic Buffer (SHMCB) session cache to synchronize the local SSL memory caches of the server processes. The pe rformance 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	`SS LSessionCache` none

Category	Value
Syn tax	`SSLSessionCacheTimeout` `seconds`< /em>
Default	300
Context	server configuration

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

Category	Value
Syntax < /td>	`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 confi guration, virtual host

Category< /font>	Value
Syntax	`SSLProxyCache on/off`
Default	`SSLProxyCache off` < /td>
Context	server configuration, virtual host

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

Category	Value< /font>
Syntax	`SSLProxyProtocol [+-]` `protoc ol`
Default	`None`
Context	server configuration, virtual host

8 Man aging 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

Authenticatio n and Authorization Enforcement

< font face="Arial, Helvetica, sans-serif" color="#330099">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 D omain 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

Examp le 8-6 Controlling Access with Environment Variables

Example 8-7 Controlling Access with SetEnv

User Authentication and Authorization

Using mod_aut h to Authenticate Users

Table 8-1 Directives Descriptions

Using mod_os sl to Authenticate Users

Secur ity Services Implemented Within Oracle HTTP Server

Table 8-2 Differen ces between mod_ossl and mod_ssl

Using mod_ossl Directives

SSLAcceler ator

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 SSL Require Varname

< strong>Table 8-6 SSL Variables for SSLRequire Varname

SSLRequireSSL

SSLSessionCache

SSLSessionCacheTimeout

SSLVerifyClient

SSLWallet

SSLWalletPassword

Us ing mod_proxy Directives

SSLProxyCache

SSLProxyCipherSuite

SSLProxyProtocol

SSLProxyWallet

SSLProxyWalletPassword

Using mod_ossl Directives to Configure Client Authentication

Using the iasobf Utility

8
Man aging Security

Categor y	Value
Syntax	`SSLPr oxyWallet` `wrl`
Default	`None`
Context	server configuration, virtual host

Category	Value< /strong>
Syntax	`SSLProxyWalletPassword` password
< p class="TB">Default	`None`
Context	server configuration, virtual host