[PATCH 08/16] changing HOWTO information about OpenSSL into Groups

David Smith dsmith at eclipse.ncsc.mil
Fri Sep 21 22:11:09 UTC 2012


Signed-off-by: David Smith <dsmith at eclipse.ncsc.mil>
---
 RHEL6/input/system/network/ssl.xml |  106 ++++++++++++++++++++++--------------
 1 files changed, 64 insertions(+), 42 deletions(-)

diff --git a/RHEL6/input/system/network/ssl.xml b/RHEL6/input/system/network/ssl.xml
index 2ba4c6e..cf8b9da 100644
--- a/RHEL6/input/system/network/ssl.xml
+++ b/RHEL6/input/system/network/ssl.xml
@@ -1,50 +1,72 @@
 <Group id="network_ssl">
 <title>Secure Sockets Layer Support</title>
 <description>
-The Secure Sockets Layer (SSL) protocol provides encrypted and authenticated network communications, and
-many network services include support for it. Using SSL is recommended, especially to avoid any plaintext
-transmission of sensitive data, even over a local network. The SSL implementation included with the system is
-called OpenSSL. Recent implementations of SSL may also be referred to as Transport Layer Security (TLS).
-SSL uses public key cryptography to provide authentication and encryption.
+The Secure Sockets Layer (SSL) protocol provides encrypted and authenticated
+network communications, and many network services include support for it. Using
+SSL is recommended, especially to avoid any plaintext transmission of sensitive
+data, even over a local network. The SSL implementation included with the
+system is called OpenSSL. Recent implementations of SSL may also be referred to
+as Transport Layer Security (TLS).  SSL uses public key cryptography to provide
+authentication and encryption.
 <br /><br />
-Public key cryptography involves two keys, one called the public key and the other called the private key. These keys are mathematically related such that data encrypted with one key can only be decrypted by the other, and vice versa. As their names
-suggest, public keys can be distributed to anyone while a private key must remain known only to its owner.
-SSL uses certificates, which are files that hold cryptographic data: a public key, and a signature of that public
-key. In SSL authentication, a server presents a client with its certificate as a means of demonstrating that it
-is who it claims it is.
+Public key cryptography involves two keys, one called the public key and the
+other called the private key. These keys are mathematically related such that
+data encrypted with one key can only be decrypted by the other, and vice versa.
+As their names suggest, public keys can be distributed to anyone while a
+private key must remain known only to its owner.  SSL uses certificates, which
+are files that hold cryptographic data: a public key, and a signature of that
+public key. In SSL authentication, a server presents a client with its
+certificate as a means of demonstrating that it is who it claims it is.
+
 <br /><br />
-If everything goes correctly, the client can verify the server’s certificate by determining
-that the signature inside the certificate could only have been generated by a third party whom the client trusts.
-This third party is called a Certificate Authority (CA). Each client system should also have certificates from
-trusted CAs, and the client uses these CA certificates to verify the authenticity of the server’s certificate. After
-authenticating a server using its certificate and a CA certificate, SSL provides encryption by using the server
-certificate to securely negotiate a shared secret key.
+If everything goes correctly, the client can verify the server’s certificate by
+determining that the signature inside the certificate could only have been
+generated by a third party whom the client trusts.  This third party is called
+a Certificate Authority (CA). Each client system should also have certificates
+from trusted CAs, and the client uses these CA certificates to verify the
+authenticity of the server’s certificate. After authenticating a server using
+its certificate and a CA certificate, SSL provides encryption by using the
+server certificate to securely negotiate a shared secret key.
+
 <br /><br />
-If your server must communicate using SSL with systems that might not be able to securely accept a new CA
-certificate prior to any SSL communication, then paying an established CA (whose certificates your clients already
-have) to sign your server certificates is recommended. The steps for doing this vary by vendor. Once the signed
-certificates have been obtained, configuration of the services is the same whether they were purchased from a
-vendor or signed by your own CA.
+If your server must communicate using SSL with systems that might not be able
+to securely accept a new CA certificate prior to any SSL communication, then
+paying an established CA (whose certificates your clients already have) to sign
+your server certificates is recommended. The steps for doing this vary by
+vendor. Once the signed certificates have been obtained, configuration of the
+services is the same whether they were purchased from a vendor or signed by
+your own CA.
+
 <br /><br />
-For setting up an internal network and encrypting local traffic, creating your own CA to sign SSL certificates
-can be appropriate. The major steps in this process are:
+For setting up an internal network and encrypting local traffic, creating your
+own CA to sign SSL certificates can be appropriate. The major steps in this
+process are:
+
 <ol>
 <li>Create a CA to sign certificates</li>
 <li>Create SSL certificates for servers using that CA</li>
 <li>Enable client support by distributing the CA’s certificate</li>
 </ol>
 </description>
+
+
 <ref disa="1141,1148,1130,1131,1127,1128,1135,1129,1132,1142,1147,187" />
 
-<Rule id="network_ssl_create_ca">
+<Group id="network_ssl_create_ca">
 <title>Create a CA to Sign Certificates</title>
-<description>The following instructions apply to OpenSSL since it is included with the system, but creating a CA is possible
-with any standards-compliant SSL toolkit. The security of certificates depends on the security of the CA that
-signed them, so performing these steps on a secure machine is critical. The system used as a CA should be
-physically secure and not connected to any network. It should receive any certificate signing requests (CSRs) via
+<description>The following instructions apply to OpenSSL since it is included
+with the system, but creating a CA is possible with any standards-compliant SSL
+toolkit. The security of certificates depends on the security of the CA that
+signed them, so performing these steps on a secure machine is critical. The
+system used as a CA should be physically secure and not connected to any
+network. It should receive any certificate signing requests (CSRs) via
 removable media and output certificates onto removable media.
 <br /><br />
-The script <tt>/etc/pki/tls/misc/CA</tt> is included to assist in the process of setting up a CA. This script uses many settings in <tt>/etc/pki/tls/openssl.cnf</tt>. The settings in this file can be changed to suit your needs and allow easier selection of default settings, particularly in the <tt>[req distinguished name]</tt> section.
+The script <tt>/etc/pki/tls/misc/CA</tt> is included to assist in the process
+of setting up a CA. This script uses many settings in
+<tt>/etc/pki/tls/openssl.cnf</tt>. The settings in this file can be changed to
+suit your needs and allow easier selection of default settings, particularly in
+the <tt>[req distinguished name]</tt> section.
 <br /><br />
 To create the CA:
 <pre># cd /etc/pki/tls/misc
@@ -81,9 +103,9 @@ of the server certificate.
 <!--<ident cce="TODO" />-->
 <!--TODO:MANUAL<oval id="network_ssl_create_ca" />-->
 <ref nist="SC-12, SC-13" />  
-</Rule>
+</Group>
 
-<Rule id="network_ssl_create_ssl_certs">
+<Group id="network_ssl_create_ssl_certs">
 <title>Create SSL Certificates for Servers</title>
 <description>Creating an SSL certificate for a server involves the following steps:
 <ol>
@@ -103,9 +125,9 @@ Instructions on how to generate and sign SSL certificates are provided for the f
 <!--<ident cce="TODO" />-->
 <!--TODO:MANUAL<oval id="network_ssl_create_ssl_certs" />-->
 <ref nist="CM-6, SC-12, SC-13" />
-</Rule>
+</Group>
 
-<Rule id="network_ssl_enable_client_support">
+<Group id="network_ssl_enable_client_support">
 <title>Enable Client Support</title>
 <description>The system ships with certificates from well-known commercial CAs. If your server certificates were signed by one of these established CAs, then this step is not necessary since the clients should include the CA certificate already.
 If your servers use certificates signed by your own CA, some user applications will warn that the server’s certificate
@@ -116,9 +138,9 @@ application on every client system that will be connecting to an SSL-enabled ser
 <!--<ident cce="TODO" />-->
 <!--TODO:MANUAL<oval id="network_ssl_enable_client_support" />-->
 <ref nist="AC-3, AC-17, CM-6, SC-12, SC-13" disa="185" />
-</Rule>
+</Group>
 
-<Rule id="network_ssl_add_ca_firefox">
+<Group id="network_ssl_add_ca_firefox">
 <title>Adding a Trusted CA for Firefox</title>
 <description>To import a new CA certificate into Firefox:
 <ol>
@@ -135,9 +157,9 @@ web sites, e-mail users, and software developers and trust it for each according
 <!--<ident cce="TODO" />-->
 <!--TODO:MANUAL<oval id="network_ssl_add_ca_firefox" />-->
 <ref nist="AC-3, AC-17, CM-6, SC-12, SC-13" />
-</Rule>
+</Group>
 
-<Rule id="network_ssl_add_ca_thunderbird">
+<Group id="network_ssl_add_ca_thunderbird">
 <title>Adding a Trusted CA for Thunderbird</title>
 <description>To import a new CA certificate into Thunderbird:
 <ol>
@@ -154,9 +176,9 @@ web sites, e-mail users, and software developers and trust it for each according
 <!--<ident cce="TODO" />-->
 <!--TODO:MANUAL<oval id="network_ssl_add_ca_thunderbird" />-->
 <ref nist="AC-3, AC-17, CM-6, SC-12, SC-13" />
-</Rule>
+</Group>
 
-<Rule id="network_ssl_add_ca_evolution">
+<Group id="network_ssl_add_ca_evolution">
 <title>Adding a Trusted CA for Evolution</title>
 <description>To import a new CA certificate into Evolution:
 <ol>
@@ -173,9 +195,9 @@ web sites, e-mail users, and software developers and trust it for each according
 <!--<ident cce="TODO" />-->
 <!--TODO:MANUAL<oval id="network_ssl_add_ca_evolution" />-->
 <ref nist="AC-3, AC-17, CM-6, SC-12, SC-13" />
-</Rule>
+</Group>
 
-<Rule id="network_ssl_remove_certs">
+<Group id="network_ssl_remove_certs">
 <title>Remove Certificate Authorities, if Appropriate</title>
 <description>Survey the certificate authorities trusted by Firefox, Thunderbird, Evolution, or other network clients. The list of certificate authorities for each program can be found via GUI, as described in the previous sections.
 Remove the certificate authorities which are not appropriate for your network connectivity needs.
@@ -185,6 +207,6 @@ Internet-connected system.
 <!--<ident cce="TODO" />-->
 <!--TODO:MANUAL<oval id="network_ssl_remove_certs" />-->
 <ref nist="AC-3, AC-17, CM-6, SC-12, SC-13" />
-</Rule>
+</Group>
 
 </Group><!--<Group id="network_ssl">-->
-- 
1.7.1



More information about the scap-security-guide mailing list