Communication security is the confidentiality and integrity of the information sent over communications channels, such as TCP/IP-based networks.
Topics:
Parent topic: Securing the Microservices Architecture
Learn how you can refine communication security.
The communication security accepts any valid certificate during the connection handshake process. However, you may need to filter and reject otherwise valid certificates based on internal policies. For example, Finance may want to reject certificates issued to Human Resources even though the Human Resources certificates are cryptographically valid. To support this additional validation, the MA extends the standard certificate validation by adding a post-verification certificate Access Control List (ACL) management. This certificate ACL follows the general model used for network ACLs where the ACL is a map with the key identifying the governed element and a value indicating whether the element is allowed or denied. The certACL entry has a scopespecification that allows the ACL entry to be applied to specific identification elements within a certificate.
The configuration of a certificate ACL takes the form of an array of certACL entry configuration specification. Each specification minimally contains a permission statement indicating whether it allows or denies client connections from the specified address. The certACL entry specifications are processed in order and terminate as soon as the specified address is qualified. If the specified address does not qualify, processing continues with the next specification. Once a certificate is qualified, the certACL permissions dictate whether the certificate is allowed or denied. If a no certACL entry specification qualify the certificate of the client requesting connection, a default resolution of 'allow is assumed and the certificate is accepted.
CertACL Entry Syntax
certACL := '[' aclSpec [, aclSpec] ']' aclSpec := '{' perm [',' name [',' scope '}' perm := "permission" ':' [ "deny" | "allow" ] name := "name" ':' regex scope := "scope" ':' [ "subject-name" | "issuer-name" ] regex := ** Uses the dynamic regular expression syntax.
The regex syntax follows the ECMAScript definition. Defining a regular expression as a JSON node value requires that the any meta symbols used (like \s) have the \character escaped. You should take care when specifying name regular expression patterns to ensure that only the full match with the intended target pattern is matched. In the syntax, the patterns only full match with the intended target pattern CN=AdminClnt not CN=AdminClnt1, CN=AdminClntOther, CN=OtherAdminClnt, or CCN=OtherAdminClnt because the match pattern includes delimiter specifications that bound the pattern. These patterns assume a standard distinguished name format that allows no whitespace between the keyname and the value. The CN = AdminClnt non-standard pattern would not match.
Example 4-1 Allow All Certificates Example
"CertACL" : [ { "name" : "^(?:(?:\\s*,?)|.*[\\s,]+)(CN=AdminClnt)(?:(?:\\s*(,+\\s*.*))$|\\s$)", "permission" : "deny" } ]
Or
"CertACL" : [ { "name" : "^(?:(?:\\s*,?)|.*[\\s,]+)(CN=AdminClnt)(?:(?:\\s*(,+\\s*.*))$|\\s$)", "scope" : "subject-name", "permission" : "deny" } ]
Example 4-2 Deny certificates issued from Deploy2
"CertACL" : [ { "name" : "^(?:(?:\\s*,?)|.*[\\s,]+)(CN=Deploy2)(?:(?:\\s*(,+\\s*.*))$|\\s$)", "scope" : "issuer-name", "permission" : "deny" } ]
Example 4-3 Certificates Issued to Suspect or Any Certificate Issued ByDeploy2
"CertACL" : [ { "name" : "^(?:(?:\\s*,?)|.*[\\s,]+)(CN=Suspect)(?:(?:\\s*(,+\\s*.*))$|\\s$)", "scope" : "subject-name", "permission" : "deny" }, { "name" : "^(?:(?:\\s*,?)|.*[\\s,]+)(CN=Deploy2)(?:(?:\\s*(,+\\s*.*))$|\\s$)", "scope" : "issuer-name", "permission" : "deny" } ]
Parent topic: Communication Security
Review the supported security protocols.
Transport Layer Security (TLS) Protocols
The following are the supported security protocol versions and these are the available values that you can use when setting the /config/securityDetails/network/common/protocolVersion security setting.
| Protocol Version ID | Notes |
|---|---|
|
|
|
|
|
|
|
|
Considered deprecated. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Oracle Recommends |
|
|
|
|
|
|
Your testing must ensure that all clients used for a particular TLS protocol version support the TLS version being tested because verification of client support for TLS version support is required. Diagnostically, the server log should be reviewed for the handshake protocol processing. The log should contain the protocol version being negotiated. If the client does not support the protocol version that the server is configured for, the server terminates the connection. You may not see an error message or indication overtly sent to the client that a protocol version failed. The failure may appear to the client as a network connection rejection or a certificate failure depending on how the client is set to handle the exception.
Note:
TLS protocols below the 1.0 version should not be used because of documented security defects.
TLS Security Cipher Suites
The following are the supported security cipher suites and these are the available values that you can use when setting the /config/securityDetails/network/common/cipherSuites security setting.
| Cipher Suite ID | Notes |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
Federal Information Processing Standards (FIPS) Compliant |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FIPS Compliant |
|
|
FIPS Compliant |
|
|
FIPS Compliant |
|
|
FIPS Compliant |
|
|
FIPS Compliant |
|
|
FIPS Compliant |
|
|
FIPS Compliant Elliptic Curve Cryptography (ECC) ciphers |
|
|
FIPS Compliant ECC ciphers |
|
|
FIPS Compliant ECC ciphers |
|
|
FIPS Compliant ECC ciphers |
|
|
FIPS Compliant ECC ciphers |
|
|
FIPS Compliant(?) ECC ciphers |
ECC ciphers are based on the algebraic structure of elliptic curves over finite fields. The elliptic curve discrete logarithm problem (ECDLP) assumes that finding the discrete logarithm of a random elliptic curve element with respect to a publicly known base point is infeasible. The benefit of ECC ciphers is that generally the key sizes are smaller compared to non-ECC cipher equivalents.
Parent topic: Communication Security
Learn how to configure a revocation list.
A Certificate Revocation List (CRLs) is a Privacy Enhance Mail (PEM) formatted file that contains information identifying the issuer of the revocation list followed by zero or more entries identifying certificate that have been revoked. A secured server is part of establishing a secure channel with a peer and will initiate a handshake with the peer. During this handshake security information and capabilities are negotiated and exchanged, which includes the one or both certificates of the participants. Depending on security configurations, one, both, or neither of the participants may present or require the presentation of the peer's certificate.
After receiving and verifying the validity of a peer's X.509 certificate, the receiving participant consults the currently configured CRL. The presence of an entry identifying the just-validated peer certificate causes the receiving participant to consider the remote participant's certificate as having been revoked. A revoked certificate is considered invalid for the purposes of authenticating the identity of the remote participant. A revoked certificate fails the integrity-check portion of the secure channel handshake and terminates the channel. Depending on the implementation that remote peer detects that an error occurred during certificate validation, but may not be informed of the specific cause.
The actual CRL consists of prolog and identifies the issuer of the CRL followed by zero or more entries. Each entry identifies a specific certificate by serial number along with security information relating to the date of revocation, the signature algorithm, and finger-print information.
For example:
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: /C=US/ST=CA/L=Redwood Shores/O=Oracle Corp/OU=Corporate Security/OU=Deployment Security/CN=Deploy1
Last Update: Feb 22 19:20:34 2017 GMT
Next Update: Mar 24 19:20:34 2017 GMT
CRL extensions:
X509v3 Authority Key Identifier:
keyid:7C:A0:BB:FB:6F:75:70:4B:B4:95:18:54:9C:1F:88:2E:A1:1B:EF:E4
X509v3 CRL Number:
4097
Revoked Certificates:
Serial Number: 1000
Revocation Date: Feb 22 19:20:34 2017 GMT
Signature Algorithm: sha256WithRSAEncryption
a6:e5:75:62:93:49:26:6e:79:f1:dd:90:94:bb:99:1c:3a:24:
99:63:82:d6:f1:56:72:98:cc:8f:6f:61:b8:a4:dd:21:0f:ae:
fa:38:78:c0:c9:bc:bc:87:61:15:35:e7:20:b8:5e:8f:6a:0a:
e1:58:e0:30:6d:df:03:8f:6f:de:0a:54:1c:f0:44:e5:28:48:
56:23:00:60:19:dd:e2:68:2d:35:2b:cc:62:85:b6:34:32:ce:
c3:f6:8a:b0:bb:b4:66:0e:85:8c:79:b2:32:5c:65:ac:47:99:
69:c5:bf:bb:ec:1e:7f:40:e2:1f:11:fa:2a:7c:d3:94:de:62:
e2:8b:de:15:04:2c:67:14:2e:b7:71:29:d5:e2:e1:ee:ac:c3:
a3:d0:20:41:a9:e0:6a:5b:90:28:35:5a:90:86:51:69:df:27:
af:3e:0f:c0:d2:32:ab:d2:7a:c5:16:29:f6:ec:04:dd:e7:6d:
8b:10:06:40:c0:08:32:39:50:33:c0:b9:86:b9:77:19:6f:a6:
49:65:54:f5:35:c8:27:08:f6:fa:91:3c:ae:2c:b5:c1:52:de:
42:2c:65:6c:ce:97:52:50:00:53:df:6d:1d:e6:38:9f:61:97:
d9:aa:60:1c:06:24:aa:f3:ac:8c:d6:85:ed:83:20:2f:50:5c:
f6:af:78:91:49:a5:b7:cb:96:6c:03:3a:e3:3d:dd:a9:d5:0f:
5f:3c:47:8c:78:33:65:09:65:8a:08:92:19:58:a1:93:7f:99:
ee:9d:f1:4a:30:21:63:24:5a:d4:6b:bd:e0:ec:0c:79:09:1f:
48:a6:39:87:92:0b:f7:25:8e:31:65:ee:10:28:45:bb:55:9c:
c8:64:49:fe:1d:78:6d:9a:09:67:6b:76:f4:3f:6a:b8:eb:c0:
0b:0c:ab:92:6d:f5:60:06:34:0f:ef:65:be:c8:af:1d:67:bc:
36:b7:d1:c0:ea:30:71:3b:2b:ba:16:dc:72:86:90:32:e3:59:
99:2c:33:7a:2f:63:77:ec:0d:70:89:52:0f:8f:29:13:fd:17:
18:49:56:65:8d:23:64:ba:e9:b6:74:56:40:9b:1c:65:17:ef:
bd:2c:77:d4:69:f6:f4:eb:df:a9:31:14:89:fc:1d:24:81:7d:
85:ba:1d:8f:8b:1b:0d:c2:a3:c2:ea:a5:6e:a2:a7:be:34:16:
a1:b8:16:a4:f2:32:5a:65:2d:85:14:be:73:6b:de:40:13:bd:
f1:3d:7e:65:14:3c:a8:ad:b7:4e:cb:41:53:f4:24:5a:4f:a1:
56:b6:33:65:f9:ef:b9:40:2d:26:ee:ba:57:d5:f5:75:1b:60:
8d:f2:24:36:e5:2a:c8:b3
-----BEGIN X509 CRL-----
MIIDKjCCARICAQEwDQYJKoZIhvcNAQELBQAwgZYxCzAJBgNVBAYTAlVTMQswCQYD
VQQIDAJDQTEXMBUGA1UEBwwOUmVkd29vZCBTaG9yZXMxFDASBgNVBAoMC09yYWNs
ZSBDb3JwMRswGQYDVQQLDBJDb3Jwb3JhdGUgU2VjdXJpdHkxHDAaBgNVBAsME0Rl
cGxveW1lbnQgU2VjdXJpdHkxEDAOBgNVBAMMB0RlcGxveTEXDTE3MDIyMjE5MjAz
NFoXDTE3MDMyNDE5MjAzNFowFTATAgIQABcNMTcwMjIyMTkyMDM0WqAwMC4wHwYD
VR0jBBgwFoAUfKC7+291cEu0lRhUnB+ILqEb7+QwCwYDVR0UBAQCAhABMA0GCSqG
SIb3DQEBCwUAA4ICAQCm5XVik0kmbnnx3ZCUu5kcOiSZY4LW8VZymMyPb2G4pN0h
D676OHjAyby8h2EVNecguF6PagrhWOAwbd8Dj2/eClQc8ETlKEhWIwBgGd3iaC01
K8xihbY0Ms7D9oqwu7RmDoWMebIyXGWsR5lpxb+77B5/QOIfEfoqfNOU3mLii94V
BCxnFC63cSnV4uHurMOj0CBBqeBqW5AoNVqQhlFp3yevPg/A0jKr0nrFFin27ATd
522LEAZAwAgyOVAzwLmGuXcZb6ZJZVT1NcgnCPb6kTyuLLXBUt5CLGVszpdSUABT
320d5jifYZfZqmAcBiSq86yM1oXtgyAvUFz2r3iRSaW3y5ZsAzrjPd2p1Q9fPEeM
eDNlCWWKCJIZWKGTf5nunfFKMCFjJFrUa73g7Ax5CR9IpjmHkgv3JY4xZe4QKEW7
VZzIZEn+HXhtmglna3b0P2q468ALDKuSbfVgBjQP72W+yK8dZ7w2t9HA6jBxOyu6
FtxyhpAy41mZLDN6L2N37A1wiVIPjykT/RcYSVZljSNkuum2dFZAmxxlF++9LHfU
afb069+pMRSJ/B0kgX2Fuh2PixsNwqPC6qVuoqe+NBahuBak8jJaZS2FFL5za95A
E73xPX5lFDyorbdOy0FT9CRaT6FWtjNl+e+5QC0m7rpX1fV1G2CN8iQ25SrIsw==
-----END X509 CRL-----
Typically, the CRL in compact form only includes the contents between the -----BEGIN X509 CRL----- and -----END X509 CRL----- delimiters. All other data outside these delimiters is ignored. You can embed a textual representation of the CRL in the CRL file without affecting the function of the CRL.
The use of CRLs is configured for each MA server individually The CRL configuration is composed of two properties:
/config/security/common/crlEnabledEnables or disables CRL processing.
If, however, /config/security/common/crlEnabled is enabled (true), then the /config/security/common/crlStore property must refer to a valid and well formed CRL.
/config/security/common/crlStoreWhen CRL processing is disabled (false), the remote participant's certificate is not checked against a CRL. When this is the case, you don’t need to set the /config/security/common/crlStore property.
A valid and well formed CRL file is either a PEM encoded CRL file that conforms to the RFC2380 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile or an empty file.
The following is a sample excerpt declaring and defining CRL processing for a secured server.
{
"config" : {
"security: {
"common" : {
"crlEnabled" : true,
"crlStore" : "file:/scratch/Tests.SCA/unittests/etc/ssl/RootCA/CAs/Deploy1/CRLs/empty_CRL.pem"
}
}
}
}
The CRL file may be updated or replace by other, presumably more current, versions while the server is running. Replacing the CRL file causes the next request CRL lookup to use the newly updated file.
Regardless of how the /config/security/common/crlEnabled property is set, CRL processing is disabled if the general security configuration of the server is disabled. For example, the value of the /config/security property is false).
One other configure setting that indirectly effects CRL processing is the /config/securityDetails/network/common/authMode property. This property controls whether the server requires the client to authenticate using a certificate or whether the server accepts optionally presented certificate or whether the server will ignore any presented client certificates. If a certificate is not required, not presented, or ignored by the server, then CRL processing is not used.
Parent topic: Communication Security
Review the supported security and cache headers.
The MA server accepts and returns HTTP envelopes that contain a set of headers that govern how the server, the client, and proxies handle the HTTP contents. For HTTP information, see:
Security Headers
The security headers that can be issue are:
The CSP is included as a header in server responses and defines how the client should handle the content sent by the server.
The default CSP header statement is:
Content-Security-Policy: script-src 'self' 'unsafe-eval' 'unsafe-inline'
The options are:
script-src:
unsafe-eval:
unsafe-inline:
The X-Frame-Options is included as headers in server responses and signals the client whether or not a user-agent should be allowed to render the content in an <frame>, <iframe>, or <object>. Websites use<frame> and <iframe> to create mash-ups or to embed part of one site. However, exposes the embedded site to Clickjack attacks. This directive disallows the client from rendering the content as embedded unless the content is from the same site (origin).
The default X-Frame-Options statement is:
X-Frame-Options: SAMEORIGIN
The option is SAMEORIGIN.
The X-XSS-Protection is included as a header in server responses and configure the user-agent's built in XSS (Cross-Site-Security)protection. The options are to enable, disable and can be combined with block and report.
The default X-XSS-Protection statement is:
X-XSS-Protection: 1; mode=block
The options are:
1: Enable the user-agent's protection mode.
2: Disable the user-agent's protection mode.
mode=block: Block the server's response if the content script was injected as user input.
mode-report=url: Report the potential XSS attack to the designated URL. Only supported by Chrome and WebKit.
The default X-Content-Type-Options statement is:
X-Content-Type-Options: nosniff
The option is nosniff.
Parent topic: Communication Security