Chapter 4. Security
4.1 XML threat protection
4.1.3 Network-level security
Network-level security such as SSL/TLS, IPSec, SMIME, and so on, ensure that the message is transported between service endpoints in a secure manner. The service riles on underlying transport for security, which is IP for the Internet. in fact, the security is applied for each IP socket in the communication channel. In that way, everything being sent through will be encrypted by the sender and will need to be decrypted by the receiver, making use of digital certificates. That is, even message fields that do not need protection will be encrypted. This protection is limited to point to point, between the sender and the receiver points. XML or other data easily tunnels through the transport layer—the Internet Protocol (IP)—using standard HTTPs. HTTPs provides a binary level protection to the entire traffic flow by encrypting then decrypting each TCP packet.
Figure 4-3 displays the protection at the transport protocol between two points, but security still matters behind the firewall.
Figure 4-3 Securing the communication point to point with TLS
HTTPS security stops here Back end Application Internet Service Requester App Service Requester App HTTPS To Gateway Firew all SECURE? SECURE SECURE? Business Partner Internet
The dialog between the client and server points is represented in Figure 4-4.
Figure 4-4 SSL dialog
SSL processing
SSL is a point-to-point security protocol supported by DataPower. Typically, this protection level is used to secure XML traffic through the Internet and inside the enterprise in certain circumstances. We can show how things are done by looking at the dialog between two points.
Client-to-device SSL
Figure 4-5 Client-to-device SSL communication
The main steps for this communication are:
1. The client sends a URL to the server beginning with https://.
2. The client wants to do SSL. The server sends the certificate to the client. 3. The client validates the certificate.
4. The expiration of the certificate is checked.
SD
Profes sional Workst at ion 6000
PR O
Client Device
Client Hello
Server Hello
Certificate*
Server Key exchange* CertificateRequest* ServerHelloDone
Verify it is a Client Hello Extract Client Random Select a CipherSuite and Compression Algorithm
Decrypt the Premaster Secret with server’s private key
Generate Master and other keys Indicates the Cipher Suite to be used for encrypted session to follow Decrypt and verify message content integrety with Cipher Suite and keys
ChangeCipherSpec Finished
Application Data
Verify protocol version Extract Server Random Extract select Cipher Suite and compression Algorithm
Verify Server Certificate Extract Public Key Recognize end of Server Hello Generate Premaster Secret
Decrypt and verify message content integrity with Cipher Suite and Keys Indicates the Cipher Suite to be used for encrypted session to follow
Application Data Certificate Verify* ChangeCipherSpec Certificate* ClientKeyExchange Finished * Optional Components
5. The identity in the certificate is checked to ensure that it is the same as that of the host that they are trying to reach.
6. The signer of certificate (could be signer chain) is checked against the trust store. 7. The certificate revocation list (CRL) is checked to see whether the certificate has been
revoked.
8. The client encrypts a random secret message using the server's certificate and sends an encrypted message to the server.
9. The server uses its private key to decrypt the message and sends it back to the client. 10.The client verifies that this matches the secret message that it encrypted.
11.The client is assured that it is talking to the correct server.
12.The client and server now negotiate ciphers and begin encrypted communications over the transport.
13.In some cases we use
mutual SSL
, where both client and server verify each other.Client-to-device SSL proxy profile
We need to configure the Crypto Identification Credentials from the DataPower console: 1. From Client-to-Device SSL Proxy Profile, choose Reverse(Server) Crypto Profile. 2. Select identification credential.
Device-to-server SSL
For device-to-server SSL:
1. The cryptographic certificate is supplied by the endpoint application server. 2. The DataPower device validates the certificate (often including certificate chain). 3. The matching private key is maintained by the endpoint application server.
4. The application server
may
request the certificate from the DataPower device and validate (mutual authentication).Figure 4-6 Device-to-server SSL communication
Client-to-server-via-device SSL
The main steps are:
1. The DataPower device SSL terminates the connection with the client and provides the certificate.
2. The DataPower device SSL initiates a new connection with the server.
X S 40 S S L-Encrypted Request SS L-Encrypted Reply W P M (AIX) E ndpo int Ap p S ervers X S 40 S S L-Encrypted Request SS L-Encrypted Reply W P M (AIX) E ndpo int Ap p S ervers
3. The DataPower device can use a back-end server certificate if the DataPower device has copies of the back-end server keys on board.
Figure 4-7 Client-to-server-via-device SSL communication
Device-to-external resource SSL
The main steps are:
1. The DataPower device SSL initiates a new connection with the external resource (config server, auth server, and so on)
Figure 4-8 Device-to-external resource SSL communication
2. The external resource provides the certificate and
may
ask the DataPower device for the certificate.3. The DataPower device validates the server certificate (actual certificate or CA certificate). 4. For the user agent configuration:
a. Given a URL match, the user agent invokes the selected SSL Proxy Profile for outbound connections.
b. The user agent invoked by the XML manager is used by the service. 5. SSL is applied:
– SSL proxy profiles (client, server, or both) may be used by: • XML firewall
• MultiProtocol Gateway (through Front Side Protocol Handler) • Web services proxy (through Front Side Protocol Handler) • User agent (launched by XML manager)
– SSL may be used through extension functions:
i. URL-Open now takes an SSL Proxy Profile Argument. ii. SOAP-Call takes an SSL Proxy Profile Argument. iii. LDAP-* takes an SSL Proxy Profile Argument. – Extension functions used by custom stylesheets
MQ and SSL
The steps are:
1. The remote MQ queue manager must first be configured to use SSL.
2. A client key is exported during that configuration process and uploaded to the DataPower device.
3. Both the key file and the password file must reside on the DataPower device.
4. The MQ queue manager object on the device must be configured to use the uploaded files.
5. The Cipher Suite Specification must agree with the remote QM.