[irods/irods 2626] Replace "SSL" with "TLS" where appropriate

Author: alanking

docs/plugins/pluggable_authentication.md

@@ -2,7 +2,7 @@
 
 The authentication methods are now contained in plugins.  By default, similar to iRODS 3.3 and prior, iRODS comes with native iRODS challenge/response (password) enabled.  However, enabling an additional authentication mechanism is as simple as adding a file to the proper directory.  The server does not need to be restarted.
 
-By default, iRODS uses a secure password system for user authentication.  The user passwords are scrambled and stored in the iCAT database.  Additionally, iRODS supports user authentication via PAM (Pluggable Authentication Modules), which can be configured to support many things, including the LDAP or Active Directory (AD) authentication systems.  PAM and SSL have been configured 'available' out of the box with iRODS, but there is still some setup required to configure an installation to communicate with your external authentication server of choice.
+By default, iRODS uses a secure password system for user authentication.  The user passwords are scrambled and stored in the iCAT database.  Additionally, iRODS supports user authentication via PAM (Pluggable Authentication Modules), which can be configured to support many things, including the LDAP or Active Directory (AD) authentication systems.  PAM and TLS have been configured 'available' out of the box with iRODS, but there is still some setup required to configure an installation to communicate with your external authentication server of choice.
 
 The iRODS administrator can 'force' a particular authentication scheme for a rodsuser by 'blanking' the native password for the rodsuser.  There is currently no way to signal to a particular login attempt that it is using an incorrect scheme ([GitHub Issue #2005](https://github.com/irods/irods/issues/2005)).
 
@@ -24,7 +24,7 @@ For PAM Authentication, the iRODS user selects the new iRODS PAM authentication
 "irods_authentication_scheme": "pam_password",
 ~~~
 
-Then, the user runs 'iinit' and enters their system password.  To protect the system password, SSL (via OpenSSL) is used to encrypt the `iinit` session.
+Then, the user runs 'iinit' and enters their system password.  To protect the system password, TLS (via OpenSSL) is used to encrypt the `iinit` session.
 
 Configuring the operating system, the service name used for PAM is 'irods'.  An addition to /etc/pam.d/ is required if the fall-through behavior is not desired.
 
@@ -78,10 +78,10 @@ This will allow any username/password combination to successfully authenticate w
 
 With the permissive configuration working with irodsPamAuthCheck, the next step is to adjust your PAM configuration to your desired settings (LDAP, in this case). You will know that is correct when irodsPamAuthCheck behaves as you would expect when using LDAP username/passwords. iRODS uses irodsPamAuthCheck directly, so if it is working on the command line, it should work when run by iRODS.
 
-### Setting up SSL/TLS
+### Setting up TLS
 
-Since PAM requires the user's password in plaintext, iRODS relies on SSL encryption to protect these credentials.  PAM authentication makes use of SSL regardless of the iRODS Zone SSL configuration (meaning even if iRODS explicitly does *not* encrypt data traffic, PAM will use SSL during authentication).
+Since PAM requires the user's password in plaintext, iRODS relies on TLS encryption to protect these credentials.  PAM authentication makes use of TLS regardless of the iRODS Zone TLS configuration (meaning even if iRODS explicitly does *not* encrypt data traffic, PAM will use TLS during authentication).
 
-In order to use the iRODS PAM support, you also need to have SSL working between the iRODS client and server.
+In order to use the iRODS PAM support, you also need to have TLS working between the iRODS client and server.
 
-See [SSL/TLS Documentation](../../system_overview/ssl_and_tls) for instructions to set up SSL/TLS communications between iRODS clients and servers.
+See [TLS Documentation](../../system_overview/tls) for instructions to set up TLS communications between iRODS clients and servers.

docs/plugins/pluggable_network.md

@@ -1,8 +1,13 @@
 #
 
-iRODS now ships with both TCP and SSL network plugins enabled.  The SSL mechanism is provided via OpenSSL and wraps the activity from the TCP plugin.
+iRODS provides both TCP and TLS network plugins.
 
-The SSL parameters are tunable via the following `irods_environment.json` variables:
+!!! Note
+    The TLS network plugin is named the "SSL" plugin for legacy reasons. This documentation will use the term "TLS".
+
+The TLS mechanism is provided via OpenSSL and wraps the activity from the TCP plugin.
+
+The TLS parameters are tunable via the following `irods_environment.json` variables:
 
 ~~~
 "irods_client_server_negotiation": "request_server_negotiation",
@@ -17,17 +22,17 @@ The only valid value for 'irods_client_server_negotiation' at this time is 'requ
 
 The possible values for 'irods_client_server_policy' include:
 
-- CS_NEG_REQUIRE: This side of the connection requires an SSL connection
-- CS_NEG_DONT_CARE: This side of the connection will connect either with or without SSL
-- CS_NEG_REFUSE: (default) This side of the connection refuses to connect via SSL
+- CS_NEG_REQUIRE: This side of the connection requires an TLS connection
+- CS_NEG_DONT_CARE: This side of the connection will connect either with or without TLS
+- CS_NEG_REFUSE: (default) This side of the connection refuses to connect via TLS
 
 On the server side, the `core.re` has a default value of 'CS_NEG_DONT_CARE' in the acPreConnect() rule:
 
 ~~~
 acPreConnect(*OUT) { *OUT="CS_NEG_DONT_CARE"; }
 ~~~
 
-In order for a connection to be made, the client and server have to agree on the type of connection they will share.  When both sides choose `CS_NEG_DONT_CARE`, iRODS shows an affinity for security by connecting via SSL.  Additionally, it is important to note that all servers in an iRODS Zone are required to share the same SSL credentials (certificates, keys, etc.).  Maintaining per-route certificates is not supported at this time.
+In order for a connection to be made, the client and server have to agree on the type of connection they will share.  When both sides choose `CS_NEG_DONT_CARE`, iRODS shows an affinity for security by connecting via TLS.  Additionally, it is important to note that all servers in an iRODS Zone are required to share the same TLS credentials (certificates, keys, etc.).  Maintaining per-route certificates is not supported at this time.
 
-The remaining parameters are standard SSL parameters and made available through the EVP library included with OpenSSL.  You can read more about these remaining parameters at [https://www.openssl.org/docs/crypto/evp.html](https://www.openssl.org/docs/crypto/evp.html).
+The remaining parameters are standard TLS parameters and made available through the EVP library included with OpenSSL.  You can read more about these remaining parameters at [https://www.openssl.org/docs/crypto/evp.html](https://www.openssl.org/docs/crypto/evp.html).
 

docs/system_overview/configuration.md

@@ -523,16 +523,16 @@ This is the main iRODS configuration file defining the iRODS environment. Any ch
 {
     // (Optional)
     // Set to "request_server_negotiation" indicating advanced negotiation is desired,
-    // for use in enabling SSL and other technologies.
+    // for use in enabling TLS and other technologies.
     "irods_client_server_negotiation": "request_server_negotiation",
 
     // (Optional)
-    // Controls whether the client and server should use SSL/TLS for communication.
+    // Controls whether the client and server should use TLS for communication.
     //
     // The following values are supported:
-    // - CS_NEG_REFUSE:    Do not use SSL
-    // - CS_NEG_REQUIRE:   Demand SSL be used
-    // - CS_NEG_DONT_CARE: Let the server decide if SSL should be used
+    // - CS_NEG_REFUSE:    Do not use TLS
+    // - CS_NEG_REQUIRE:   Demand TLS be used
+    // - CS_NEG_DONT_CARE: Let the server decide if TLS should be used
     "irods_client_server_policy": "CS_NEG_REFUSE",
 
     // Number of seconds after which an existing connection in a connection pool is refreshed.

docs/system_overview/ssl_and_tls.md docs/system_overview/tls.mddocs/system_overview/ssl_and_tls.md renamed to docs/system_overview/tls.md

@@ -1,10 +1,11 @@
 #
 
-Throughout this page, "SSL" (or, Secure Sockets Layer) will be used interchangeably with "TLS" (or, Transport Layer Security).
+!!! Note
+    The TLS network plugin is named the "SSL" plugin for legacy reasons. This documentation will use the term "TLS".
 
-The SSL communication between client and iRODS server needs some basic setup in order to function properly.
+The TLS communication between client and iRODS server needs some basic setup in order to function properly.
 
-## Server SSL Setup
+## Server TLS Setup
 
 Much of the setup concerns getting a proper X.509 certificate setup on the server side, and setting up the trust for the server certificate on the client side. You can use either a self-signed certificate (best for testing) or a certificate from a trusted CA.
 
@@ -102,9 +103,9 @@ In order for the configuration to take effect, the iRODS server configuration mu
 irods@hostname:~/ $ kill -HUP $(cat /var/run/irods/irods-server.pid)
 ~~~
 
-## Client SSL Setup
+## Client TLS Setup
 
-The client may or may not require configuration at the SSL level, but there are a few parameters that can be set via `irods_environment.json` properties to customize the client SSL interaction if necessary. In many cases, if the server's certificate comes from a common CA, your system might already be configured to accept certificates from that CA, and you will not have to adjust the client configuration at all. For example, on Debian-based systems, the `/etc/ssl/certs` directory is used as a repository for system trusted certificates installed via an Ubuntu package. Many of the commercial certificate vendors such as VeriSign and AddTrust have their certificates already installed.
+The client may or may not require configuration at the TLS level, but there are a few parameters that can be set via `irods_environment.json` properties to customize the client TLS interaction if necessary. In many cases, if the server's certificate comes from a common CA, your system might already be configured to accept certificates from that CA, and you will not have to adjust the client configuration at all. For example, on Debian-based systems, the `/etc/ssl/certs` directory is used as a repository for system trusted certificates installed via an Ubuntu package. Many of the commercial certificate vendors such as VeriSign and AddTrust have their certificates already installed.
 
 ### Server Verification Settings
 
@@ -126,7 +127,7 @@ Then, the client library will only require certificate validation, but will not
 
 ### Encryption Settings
 
-The following SSL encryption settings are required in `irods_environment.json` on both sides of the connection (client and server) and the values must match:
+The following TLS encryption settings are required in `irods_environment.json` on both sides of the connection (client and server) and the values must match:
 
  - `irods_encryption_algorithm` (required) - EVP-supplied encryption algorithm for parallel transfer encryption
  - `irods_encryption_key_size` (required) - Key size for parallel transfer encryption

mkdocs.yml

@@ -54,7 +54,7 @@ nav:
     - Process Model: 'system_overview/process_model.md'
     - Control Plane: 'system_overview/control_plane.md'
     - Configuration: 'system_overview/configuration.md'
-    - SSL/TLS: 'system_overview/ssl_and_tls.md'
+    - TLS/SSL: 'system_overview/tls.md'
     - Users and Permissions: 'system_overview/users_and_permissions.md'
     - GenQuery: 'system_overview/genquery.md'
     - Backing Up: 'system_overview/backing_up.md'