Encryption and integrity verification for Oracle Network transport

Transfer from http://blog.itpub.net/24052272/viewspace-2129175/

Test environment:

11.2.0.4 Winodows stand-alone

Application Scenarios:

Encryption and integrity checking of network transfer data between Oracle servers and clients.

By default, the data is transmitted in clear text, for example, through the Wireshark, sniffer and other network capture tools to capture the transmission of specific information.

It is not safe to have sensitive information.

Example:

For Chinese characters, hex codes can be converted into readable Chinese characters through many online conversion tools.

This information is valuable to those who understand the business.

There are two modes of client:

1. Connect to the database via Oracle client software

2. Connect Oracle database via JDBC Driver

Through the Oracle client scenario:

The primary method for enabling transport encryption and validation is through the server-side and client-Sqlnet.ora files.

Configuration method:
In theory, the Sqlnet.ora file needs to be modified on both the database server side and the Oracle client, but because the client side default transport encryption level is accepted, the default consistency check level is accepted, so you only need to set the following parameters on the server side to open the transport encryption and consistency checksum No need to set up the client side Sqlnet.ora (Knowledge Development section).

To edit the Sqlnet.ora file on the Oracle server side, add the parameters:
Sqlnet. Encryption_server = REQUIRED----Encryption level
Sqlnet. Encryption_types_server = rc4_256----encryption algorithm
Sqlnet. Crypto_checksum_server = REQUIRED---conformance performance check

After setting the parameters, it works for the newly established session.

Packets that are crawled after encryption are no longer plaintext:


For JDBC Connection scenarios:
Need to write code, not very understand, do not verify, the general format is as follows:
For example:

Drivermanager.registerdriver (New Oracle.jdbc.driver.OracleDriver ()); Properties Props = new properties ();p rops.put ("Oracle.net.encryption_client", "accepted");p Rops.put (" Oracle.net.encryption_types_client "," rc4_128 ");

Props.put ("Oracle.net.crypto_checksum_client", "REQUIRED");                This line is written according to official documents, not verified.

Props.put ("Oracle.net.crypto_checksum_types_client", "MD5");             This line is written according to the official document format, not validated

Props.put ("User", "XXX"); Props.put ("Password", "YYY"); Connection conn = Drivermanager.getconnection ("Jdbc:oracle:thin: @myhost: 1521:mysid", props);

Knowledge Development:
SERVER-side and client-side encryption-level parameters sqlnet.encryption_server| CLIENT
Level points

• Requested

• REQUIRED

• ACCEPTED

• Rejected

Server and client should be used in conjunction to ensure transmission encryption, simply summarize the following table:

Table 4-2 Encryption and Data Integrity negotiations

Client Setting	Server Setting	encryption and Data negotiation
Rejected	Rejected	OFF
ACCEPTED	Rejected	OFF
Requested	Rejected	OFF
REQUIRED	Rejected	Connection fails
Rejected	ACCEPTED	OFF
ACCEPTED	ACCEPTED	OFFFoot 1
Requested	ACCEPTED	On
REQUIRED	ACCEPTED	On
Rejected	Requested	OFF
ACCEPTED	Requested	On
Requested	Requested	On
REQUIRED	Requested	On
Rejected	REQUIRED	Connection fails
ACCEPTED	REQUIRED	On
Requested	REQUIRED	On
REQUIRED	REQUIRED	On

The consistency check is also divided into four levels:
sqlnet. Crypto_checksum_server| CLIENT

• Requested

• REQUIRED

• ACCEPTED

• Rejected

It also needs to be used together.

Parameter explanation:
Sqlnet. Crypto_checksum_client. The default setting is accepted.


Parameters


ACCEPTED-The client does not request the use of checksums, but if the server requests a checksum, the request. The compatible server parameters are rejected,requested and required.
Rejected-the client does not support the use of checksums. The compatible server parameters are rejected,accepted and requested.
Requested-the client prefers to use checksums, but if the server rejects their use, the problem is not enforced. The compatible server parameters are accepted,requested and required.
REQUIRED-The client requires a checksum, otherwise it is not connected. The compatible server parameters are accepted,requested and required.




Sqlnet. Crypto_checksum_server. The default setting is accepted.


Parameters


ACCEPTED-The server does not request the use of checksums, but if the client requests them, continue. The compatible server parameters are: rejected,requested and required.
Rejected-the server does not support the use of checksums at all. The compatible client parameters are rejected,accepted and requested.
Requested-the server prefers to use checksums, but if the client rejects their use, the problem is not enforced. The compatible client parameters are accepted,requested and required.
REQUIRED-The server requires a checksum, otherwise it is not connected. The compatible client parameters are accepted,requested and required.

Impact on performance:

Since encryption and decryption are bound to occupy a certain amount of performance resources, but the impact is not small, is a test result, excerpted from Http://www.orafaq.com/wiki/Network_Encryption

algorithm	None		MD5		SHA-1
	Time	%none	Time	%none	Time	%none
None	79.6 s		80.5 s	101%	82.4 S	104%
Des	104.7 s	132%	107.1 S	135%	108.2 s	136%
3des168	151.8 s	191%	153.9 s	193%	155.6 s	196%
AES128	88.8 S	112%	90.5 s	114%	92.1 s	116%
AES256	91.8 s	115%	93.5 S	117%	94.2 s	118%
rc4_128	81.6 s	103%	82.5 s	104%	85.0 s	107%
rc4_256	81.7 s	103%	82.8 s	104%	85.0 s	107%

Reference Documentation:
Http://docs.oracle.com/cd/B19306_01/network.102/b14268/asoconfg.htm#BBJBIECD

http://docs.oracle.com/cd/B19306_01/network.102/b14268/asojbdc.htm#i1006209

Http://www.orafaq.com/wiki/Network_Encryption

Http://www.toadworld.com/platforms/oracle/w/wiki/1719.sqlnet-ora-parameters

Encryption and integrity verification for Oracle Network transport