From 0af20bdcfb54a648d4b0c907565171a46afd1457 Mon Sep 17 00:00:00 2001 From: Ingela Anderton Andin Date: Thu, 30 Apr 2015 09:47:45 +0200 Subject: ssl: Align with application naming rules ssl SSL crypto Crypto stdlib STDLIB kernel Kernel public_key Public Key --- lib/ssl/doc/src/ssl.xml | 29 ++++++++++++----------- lib/ssl/doc/src/ssl_app.xml | 16 ++++++------- lib/ssl/doc/src/ssl_distribution.xml | 38 +++++++++++++++---------------- lib/ssl/doc/src/ssl_protocol.xml | 10 ++++---- lib/ssl/doc/src/ssl_session_cache_api.xml | 4 ++-- 5 files changed, 48 insertions(+), 49 deletions(-) (limited to 'lib') diff --git a/lib/ssl/doc/src/ssl.xml b/lib/ssl/doc/src/ssl.xml index c5fe8b69a4..14873848d1 100644 --- a/lib/ssl/doc/src/ssl.xml +++ b/lib/ssl/doc/src/ssl.xml @@ -45,7 +45,7 @@ but can be configured. Ephemeral Diffie-Hellman cipher suites are supported, but not Diffie Hellman Certificates cipher suites. - Elliptic Curve cipher suites are supported if the crypto + Elliptic Curve cipher suites are supported if the Crypto application supports it and named curves are used. Export cipher suites are not supported as the @@ -63,7 +63,7 @@
DATA TYPES -

The following data types are used in the functions for ssl:

+

The following data types are used in the functions for SSL:

@@ -81,7 +81,7 @@

For valid options, see the inet(3) and gen_tcp(3) manual pages - in kernel.

+ in Kernel.

ssloption()

= {verify, verify_type()}

@@ -261,7 +261,7 @@ atom()}} |

The verification fun is called during the X509-path - validation when an error or an extension unknown to the ssl + validation when an error or an extension unknown to the SSL application is encountered. It is also called when a certificate is considered valid by the path validation to allow access to each certificate in the path to the user @@ -382,7 +382,7 @@ marker="public_key:public_key#pkix_path_validation-3">public_key:pkix_path_valid

TLS protocol versions supported by started clients and servers. This option overrides the application environment option protocol_version. If the environment option is not set, it defaults - to all versions, except SSL-3.0, supported by the ssl application. + to all versions, except SSL-3.0, supported by the SSL application. See also ssl(6).

 {hibernate_after, integer()|undefined} @@ -999,21 +999,21 @@ fun(srp, Username :: string(), UserState :: term()) -> start() -> start(Type) -> ok | {error, Reason} - Starts the sslapplication. + Starts the SSL application. Type = permanent | transient | temporary -

Starts the ssl application. Default type +

Starts the SSL application. Default type is temporary.

 stop() -> ok - Stops the ssl application. + Stops the SSL application. -

Stops the ssl application.

+

Stops the SSL application.

 @@ -1055,16 +1055,16 @@ fun(srp, Username :: string(), UserState :: term()) -> versions() -> [versions_info()] Returns version information relevant for the - ssl application. + SSL application. versions_info() = {app_vsn, string()} | {supported | available, [protocol()] -

Returns version information relevant for the ssl +

Returns version information relevant for the SSL application.

app_vsn - The application version of the ssl application. + The application version of the SSL application. supported TLS/SSL versions supported by default. @@ -1077,8 +1077,8 @@ fun(srp, Username :: string(), UserState :: term()) -> . available - All TLS/SSL versions supported by the ssl application. - TLS 1.2 requires sufficient support from the crypto + All TLS/SSL versions supported by the SSL application. + TLS 1.2 requires sufficient support from the Crypto application. @@ -1094,4 +1094,3 @@ fun(srp, Username :: string(), UserState :: term()) ->
- diff --git a/lib/ssl/doc/src/ssl_app.xml b/lib/ssl/doc/src/ssl_app.xml index 43c69ba377..f17f5cb9fe 100644 --- a/lib/ssl/doc/src/ssl_app.xml +++ b/lib/ssl/doc/src/ssl_app.xml @@ -35,21 +35,21 @@
DEPENDENCIES -

The ssl application uses the public_key and - crypto application to handle public keys and encryption, hence - these applications must be loaded for the ssl application to work. +

The SSL application uses the public_key and + Crypto application to handle public keys and encryption, hence + these applications must be loaded for the SSL application to work. In an embedded environment this means they must be started with - application:start/[1,2] before the ssl application is + application:start/[1,2] before the SSL application is started.

CONFIGURATION

The application environment configuration parameters in this section - are defined for the ssl application. For more information + are defined for the SSL application. For more information about configuration parameters, see the application(3) - manual page in kernel.

+ manual page in Kernel.

The environment parameters can be set on the command line, for example:

@@ -60,7 +60,7 @@ ssl:protocol() ]]>.

Protocol supported by started clients and servers. If this option is not set, it defaults to all - protocols currently supported by the ssl application. + protocols currently supported by the SSL application. This option can be overridden by the version option to ssl:connect/[2,3] and ssl:listen/2.

 @@ -91,7 +91,7 @@
ERROR LOGGER AND EVENT HANDLERS -

The ssl applications uses the default OTP error logger to log unexpected errors and TLS alerts. The logging of TLS alerts may be turned off with the log_alert option.

+

The SSL application uses the default OTP error logger to log unexpected errors and TLS alerts. The logging of TLS alerts may be turned off with the log_alert option.

diff --git a/lib/ssl/doc/src/ssl_distribution.xml b/lib/ssl/doc/src/ssl_distribution.xml index c9f7b1b27f..effb304938 100644 --- a/lib/ssl/doc/src/ssl_distribution.xml +++ b/lib/ssl/doc/src/ssl_distribution.xml @@ -38,11 +38,11 @@ connection-based protocol as bearer. However, a module that implements the protocol-specific parts of the connection setup is needed. The default distribution module is inet_tcp_dist - in the kernel application. When starting an + in the Kernel application. When starting an Erlang node distributed, net_kernel uses this module to set up listen ports and connections.

-

In the ssl application, an exra distribution +

In the SSL application, an exra distribution module, inet_tls_dist, can be used as an alternative. All distribution connections will use SSL and all participating Erlang nodes in a distributed system must use @@ -57,7 +57,7 @@ Step 1: Build boot scripts including the - ssl application. + SSL application. Step 2: Specify the distribution module for net_kernel. Step 3: Specify the security options and other @@ -74,8 +74,8 @@ see the sasl documentation. This is only an example of what can be done.

-

The simplest boot script possible includes only the kernel - and stdlib applications. Such a script is located in the +

The simplest boot script possible includes only the Kernel + and STDLIB applications. Such a script is located in the bin directory of the Erlang distribution. The source for the script is found under the Erlang installation top directory under /start_clean.rel]]>.

@@ -84,12 +84,12 @@

Copy that script to another location (and preferably another name).

 -

Add the applications crypto, public_key, and - ssl with their current version numbers after the - stdlibapplication.

 +

Add the applications Crypto, Public Key, and + SSL with their current version numbers after the + STDLIB application.

 -

The following shows an example .rel file with ssl +

The following shows an example .rel file with SSL added:

{release, {"OTP APN 181 01","R15A"}, {erts, "5.9"}, @@ -132,27 +132,27 @@ Eshell V5.0 (abort with ^G) 1> whereis(ssl_manager). <0.41.0> ]]> -

The whereis function-call verifies that the ssl +

The whereis function-call verifies that the SSL application is started.

As an alternative to building a bootscript, you can explicitly - add the path to the ssl ebin directory on the command + add the path to the SSL ebin directory on the command line. This is done with command-line option -pa. This - works as the ssl application does not need to be started for the - distribution to come up, as a clone of the ssl application is - hooked into the kernel application. So, as long as the - ssl application code can be reached, the distribution starts. + works as the SSL application does not need to be started for the + distribution to come up, as a clone of the SSL application is + hooked into the Kernel application. So, as long as the + SSL application code can be reached, the distribution starts. The -pa method is only recommended for testing purposes.

-

The clone of the ssl application must +

The clone of the SSL application must enable the use of the SSL code in such an early bootstage as needed to set up the distribution. However, this makes it - impossible to soft upgrade the ssl application.

 + impossible to soft upgrade the SSL application.

Specifying Distribution Module for net_kernel -

The distribution module for ssl is named inet_tls_dist +

The distribution module for SSL is named inet_tls_dist and is specified on the command line with option -proto_dist. The argument to -proto_dist is to be the module name without suffix _dist. So, this distribution @@ -172,7 +172,7 @@ Eshell V5.0 (abort with ^G) (ssl_test@myhost)1>

However, a node started in this way refuses to talk - to other nodes, as no ssl parameters are supplied + to other nodes, as no SSL parameters are supplied (see the next section).

diff --git a/lib/ssl/doc/src/ssl_protocol.xml b/lib/ssl/doc/src/ssl_protocol.xml index 20f53c98e1..cc49515066 100644 --- a/lib/ssl/doc/src/ssl_protocol.xml +++ b/lib/ssl/doc/src/ssl_protocol.xml @@ -32,19 +32,19 @@ ssl_protocol.xml -

The Erlang ssl application implements the SSL/TLS protocol +

The Erlang SSL application implements the SSL/TLS protocol for the currently supported versions, see the ssl(3) manual page.

-

By default ssl is run over the TCP/IP protocol even +

By default SSL/TLS is run over the TCP/IP protocol even though you can plug in any other reliable transport protocol with the same Application Programming Interface (API) as the - gen_tcp module in kernel.

+ gen_tcp module in Kernel.

If a client and a server wants to use an upgrade mechanism, such as defined by RFC 2817, to upgrade a regular TCP/IP connection to an SSL - connection, this is supported by the Erlang ssl API. This can be + connection, this is supported by the Erlang SSL application API. This can be useful for, for example, supporting HTTP and HTTPS on the same port and implementing virtual hosting.

@@ -143,7 +143,7 @@ connections. Sessions are used to avoid the expensive negotiation of new security parameters for each connection."

-

Session data is by default kept by the ssl application in a +

Session data is by default kept by the SSL application in a memory storage, hence session data is lost at application restart or takeover. Users can define their own callback module to handle session data storage if persistent data storage is diff --git a/lib/ssl/doc/src/ssl_session_cache_api.xml b/lib/ssl/doc/src/ssl_session_cache_api.xml index 9cd16c5f58..c89d3874a1 100644 --- a/lib/ssl/doc/src/ssl_session_cache_api.xml +++ b/lib/ssl/doc/src/ssl_session_cache_api.xml @@ -108,8 +108,8 @@ API functions. Is called by the cache handling processes init function, hence putting the same requirements on it as a normal process init function. This function is - called twice when starting the ssl application, once with - the role client and once with the role server, as the ssl + called twice when starting the SSL application, once with + the role client and once with the role server, as the SSL application must be prepared to take on both roles.

-- cgit v1.2.3