diff options
Diffstat (limited to 'lib/ssl/doc/src')
| -rw-r--r-- | lib/ssl/doc/src/book.xml | 2 | ||||
| -rw-r--r-- | lib/ssl/doc/src/notes.xml | 267 | ||||
| -rw-r--r-- | lib/ssl/doc/src/ssl.xml | 307 | ||||
| -rw-r--r-- | lib/ssl/doc/src/ssl_distribution.xml | 10 | ||||
| -rw-r--r-- | lib/ssl/doc/src/ssl_protocol.xml | 12 | ||||
| -rw-r--r-- | lib/ssl/doc/src/ssl_session_cache_api.xml | 20 | ||||
| -rw-r--r-- | lib/ssl/doc/src/using_ssl.xml | 2 |
7 files changed, 487 insertions, 133 deletions
diff --git a/lib/ssl/doc/src/book.xml b/lib/ssl/doc/src/book.xml index 85d6b56b26..ecfb915b44 100644 --- a/lib/ssl/doc/src/book.xml +++ b/lib/ssl/doc/src/book.xml @@ -4,7 +4,7 @@ <book xmlns:xi="http://www.w3.org/2001/XInclude"> <header titlestyle="normal"> <copyright> - <year>1999</year><year>2009</year> + <year>1999</year><year>2011</year> <holder>Ericsson AB. All Rights Reserved.</holder> </copyright> <legalnotice> diff --git a/lib/ssl/doc/src/notes.xml b/lib/ssl/doc/src/notes.xml index 95e968aa22..52ee9c086a 100644 --- a/lib/ssl/doc/src/notes.xml +++ b/lib/ssl/doc/src/notes.xml @@ -4,7 +4,7 @@ <chapter> <header> <copyright> - <year>1999</year><year>2010</year> + <year>1999</year><year>2011</year> <holder>Ericsson AB. All Rights Reserved.</holder> </copyright> <legalnotice> @@ -31,7 +31,270 @@ <p>This document describes the changes made to the SSL application. </p> - <section><title>SSL 4.0</title> + <section><title>SSL 4.1.4</title> + + <section><title>Improvements and New Features</title> + <list> + <item> + <p> + Reduced memory footprint of an ssl connection.</p> + <p> + Handshake hashes, premaster secret and "public_key_info" + does not need to be saved when the connection has been + established. The own certificate is no longer duplicated + in the state.</p> + <p> + Own Id: OTP-9021</p> + </item> + <item> + <p> + Add the option {hibernate_after, int()} to ssl:connect + and ssl:listen</p> + <p> + Own Id: OTP-9106</p> + </item> + </list> + </section> + +</section> + +<section><title>SSL 4.1.3</title> + + <section><title>Fixed Bugs and Malfunctions</title> + <list> + <item> + <p> + Fixed error in cache-handling fix from ssl-4.1.2</p> + <p> + Own Id: OTP-9018 Aux Id: seq11739 </p> + </item> + <item> + <p> + Verification of a critical extended_key_usage-extension + corrected</p> + <p> + Own Id: OTP-9029 Aux Id: seq11541 </p> + </item> + </list> + </section> + +</section> + +<section><title>SSL 4.1.2</title> + + <section><title>Fixed Bugs and Malfunctions</title> + <list> + <item> + <p> + The ssl application caches certificate files, it will now + invalidate cache entries if the diskfile is changed.</p> + <p> + Own Id: OTP-8965 Aux Id: seq11739 </p> + </item> + <item> + <p> + Now runs the terminate function before returning from the + call made by ssl:close/1, as before the caller of + ssl:close/1 could get problems with the reuseaddr option.</p> + <p> + Own Id: OTP-8992</p> + </item> + </list> + </section> + +</section> + +<section><title>SSL 4.1.1</title> + + <section><title>Fixed Bugs and Malfunctions</title> + <list> + <item> + <p> + Correct handling of client certificate verify message + When checking the client certificate verify message the + server used the wrong algorithm identifier to determine + the signing algorithm, causing a function clause error in + the public_key application when the key-exchange + algorithm and the public key algorithm of the client + certificate happen to differ.</p> + <p> + Own Id: OTP-8897</p> + </item> + </list> + </section> + + + <section><title>Improvements and New Features</title> + <list> + <item> + <p> + For testing purposes ssl now also support some anonymous + cipher suites when explicitly configured to do so.</p> + <p> + Own Id: OTP-8870</p> + </item> + <item> + <p> + Sends an error alert instead of crashing if a crypto + function for the selected cipher suite fails.</p> + <p> + Own Id: OTP-8930 Aux Id: seq11720 </p> + </item> + </list> + </section> + +</section> + +<section><title>SSL 4.1</title> + + <section><title>Improvements and New Features</title> + <list> + <item> + <p> + Updated ssl to ignore CA certs that violate the asn1-spec + for a certificate, and updated public key asn1 spec to + handle inherited DSS-params.</p> + <p> + Own Id: OTP-7884</p> + </item> + <item> + <p> + Changed ssl implementation to retain backwards + compatibility for old option {verify, 0} that shall be + equivalent to {verify, verify_none}, also separate the + cases unknown ca and selfsigned peer cert, and restored + return value of deprecated function + public_key:pem_to_der/1.</p> + <p> + Own Id: OTP-8858</p> + </item> + <item> + <p> + Changed the verify fun so that it differentiate between + the peer certificate and CA certificates by using + valid_peer or valid as the second argument to the verify + fun. It may not always be trivial or even possible to + know when the peer certificate is reached otherwise.</p> + <p> + *** POTENTIAL INCOMPATIBILITY ***</p> + <p> + Own Id: OTP-8873</p> + </item> + </list> + </section> + +</section> + +<section><title>SSL 4.0.1</title> + + <section><title>Fixed Bugs and Malfunctions</title> + <list> + <item> + <p> + The server now verifies the client certificate verify + message correctly, instead of causing a case-clause.</p> + <p> + Own Id: OTP-8721</p> + </item> + <item> + <p> + The client hello message now always include ALL available + cipher suites (or those specified by the ciphers option). + Previous implementation would filter them based on the + client certificate key usage extension (such filtering + only makes sense for the server certificate).</p> + <p> + Own Id: OTP-8772</p> + </item> + <item> + <p> + Fixed handling of the option {mode, list} that was broken + for some packet types for instance line.</p> + <p> + Own Id: OTP-8785</p> + </item> + <item> + <p> + Empty packets were not delivered to the client.</p> + <p> + Own Id: OTP-8790</p> + </item> + <item> + <p> Building in a source tree without prebuilt platform + independent build results failed on the SSL examples + when: </p> <list><item> cross building. This has been + solved by not building the SSL examples during a cross + build. </item><item> building on Windows. </item></list> + <p> + Own Id: OTP-8791</p> + </item> + <item> + <p> + Fixed a handshake error which occurred on some ssl + implementations.</p> + <p> + Own Id: OTP-8793</p> + </item> + </list> + </section> + + + <section><title>Improvements and New Features</title> + <list> + <item> + <p> + Revise the public_key API - Cleaned up and documented the + public_key API to make it useful for general use, also + changed ssl to use the new API.</p> + <p> + Own Id: OTP-8722</p> + </item> + <item> + <p> + Added support for inputing certificates and keys directly + in DER format these options will override the pem-file + options if specified.</p> + <p> + Own Id: OTP-8723</p> + </item> + <item> + <p> + To gain interoperability ssl will not check for padding + errors when using TLS 1.0. It is first in TLS 1.1 that + checking the padding is an requirement.</p> + <p> + Own Id: OTP-8740</p> + </item> + <item> + <p> + Changed the semantics of the verify_fun option in the + ssl-application so that it takes care of both application + handling of path validation errors and verification of + application specific extensions. This means that it is + now possible for the server application in verify_peer + mode to handle path validation errors. This change moved + some functionality earlier in ssl to the public_key + application.</p> + <p> + Own Id: OTP-8770</p> + </item> + <item> + <p> + Added the functionality so that the verification fun will + be called when a certificate is considered valid by the + path validation to allow access to each certificate in + the path to the user application. Also try to verify + subject-AltName, if unable to verify it let the + application verify it.</p> + <p> + Own Id: OTP-8825</p> + </item> + </list> + </section> + +</section> + +<section><title>SSL 4.0</title> <section><title>Improvements and New Features</title> <list> diff --git a/lib/ssl/doc/src/ssl.xml b/lib/ssl/doc/src/ssl.xml index def61bcf03..60ea4d547f 100644 --- a/lib/ssl/doc/src/ssl.xml +++ b/lib/ssl/doc/src/ssl.xml @@ -1,10 +1,10 @@ -<?xml version="1.0" encoding="latin1" ?> +<?xml version="1.0" encoding="iso-8859-1" ?> <!DOCTYPE erlref SYSTEM "erlref.dtd"> <erlref> <header> <copyright> - <year>1999</year><year>2010</year> + <year>1999</year><year>2011</year> <holder>Ericsson AB. All Rights Reserved.</holder> </copyright> <legalnotice> @@ -69,10 +69,13 @@ </p> <p> <c>ssloption() = {verify, verify_type()} | + {verify_fun, {fun(), term()}} | {fail_if_no_peer_cert, boolean()} {depth, integer()} | - {certfile, path()} | {keyfile, path()} | {password, string()} | - {cacertfile, path()} | {dhfile, path()} | {ciphers, ciphers()} | + {cert, der_encoded()}| {certfile, path()} | + {key, der_encoded()} | {keyfile, path()} | {password, string()} | + {cacerts, [der_encoded()]} | {cacertfile, path()} | + |{dh, der_encoded()} | {dhfile, path()} | {ciphers, ciphers()} | {ssl_imp, ssl_imp()} | {reuse_sessions, boolean()} | {reuse_session, fun()} </c></p> @@ -91,6 +94,8 @@ <p><c>verify_type() = verify_none | verify_peer</c></p> <p><c>path() = string() - representing a file path.</c></p> + + <p><c>der_encoded() = binary() -Asn1 DER encoded entity as an erlang binary.</c></p> <p><c>host() = hostname() | ipaddress()</c></p> @@ -109,7 +114,7 @@ <p><c>ciphersuite() = {key_exchange(), cipher(), hash()}</c></p> - <p><c>key_exchange() = rsa | dhe_dss | dhe_rsa + <p><c>key_exchange() = rsa | dhe_dss | dhe_rsa | dh_anon </c></p> <p><c>cipher() = rc4_128 | des_cbc | '3des_ede_cbc' @@ -121,115 +126,57 @@ <p><c>ssl_imp() = new | old - default is new.</c></p> </section> - -<section> - <title>SSL OPTION DESCRIPTIONS</title> + + <section> + <title>SSL OPTION DESCRIPTIONS - COMMON for SERVER and CLIENT</title> + + <p>Options described here are options that are have the same + meaning in the client and the server. + </p> <taglist> - <tag>{verify, verify_type()}</tag> - <item> If <c>verify_none</c> is specified x509-certificate - path validation errors at the client side - will not automatically cause the connection to fail, as - it will if the verify type is <c>verify_peer</c>. See also - the option verify_fun. - Servers only do the path validation if <c>verify_peer</c> is set to - true, as it then will - send a certificate request to - the client (this message is not sent if the verify option is - <c>verify_none</c>) and you may then also want to specify - the option <c>fail_if_no_peer_cert</c>. - </item> - <tag>{fail_if_no_peer_cert, boolean()}</tag> - <item>Used together with {verify, verify_peer} by a ssl server. - If set to true, - the server will fail if the client does not have a certificate - to send, e.i sends a empty certificate, if set to false it will - only fail if the client sends a invalid certificate (an empty - certificate is considered valid). - </item> + <tag>{cert, der_encoded()}</tag> + <item> The DER encoded users certificate. If this option + is supplied it will override the certfile option.</item> - <tag>{verify_fun, fun(ErrorList) -> boolean()}</tag> - <item>Used by the ssl client to determine if - x509-certificate path validations errors are acceptable or - if the connection should fail. Defaults to: - -<code> -fun(ErrorList) -> - case lists:foldl(fun({bad_cert,unknown_ca}, Acc) -> - Acc; - (Other, Acc) -> - [Other | Acc] - end, [], ErrorList) of - [] -> - true; - [_|_] -> - false - end -end -</code> - I.e. by default if the only error found was that the CA-certificate - holder was unknown this will be accepted. - - Possible errors in the error list are: - {bad_cert, cert_expired}, {bad_cert, invalid_issuer}, - {bad_cert, invalid_signature}, {bad_cert, name_not_permitted}, - {bad_cert, unknown_ca}, - {bad_cert, cert_expired}, {bad_cert, invalid_issuer}, - {bad_cert, invalid_signature}, {bad_cert, name_not_permitted}, - {bad_cert, cert_revoked} (not implemented yet), - {bad_cert, unknown_critical_extension} or {bad_cert, term()} - </item> - + <tag>{certfile, path()}</tag> + <item>Path to a file containing the user's certificate.</item> - <tag>{validate_extensions_fun, fun()}</tag> - <item> - This options makes it possible to supply a fun to validate - possible application specific certificate extensions - during the certificat path validation. This option - will be better documented onec the public_key API is more - mature. - </item> + <tag>{key, der_encoded()}</tag> + <item> The DER encoded users private key. If this option + is supplied it will override the keyfile option.</item> - <tag>{depth, integer()}</tag> - <item>Specifies the maximum - verification depth, i.e. how far in a chain of certificates the - verification process can proceed before the verification is - considered to fail. Peer certificate = 0, CA certificate = 1, - higher level CA certificate = 2, etc. The value 2 thus means - that a chain can at most contain peer cert, CA cert, next CA - cert, and an additional CA cert. The default value is 1. - </item> - - <tag>{certfile, path()}</tag> - <item>Path to a file containing the - user's certificate. Optional for clients but note - that some servers requires that the client can certify - itself. </item> <tag>{keyfile, path()}</tag> <item>Path to file containing user's private PEM encoded key. As PEM-files may contain several entries this option defaults to the same file as given by certfile option.</item> + <tag>{password, string()}</tag> <item>String containing the user's password. Only used if the private keyfile is password protected. </item> + + <tag>{cacerts, [der_encoded()]}</tag> + <item> The DER encoded trusted certificates. If this option + is supplied it will override the cacertfile option.</item> + <tag>{cacertfile, path()}</tag> <item>Path to file containing PEM encoded CA certificates (trusted certificates used for verifying a peer certificate). May be omitted if you do not want to verify the peer.</item> - <tag>{dhfile, path()}</tag> - <item>Path to file containing PEM encoded Diffie Hellman parameters, - for the server to use if a cipher suite using Diffie Hellman key exchange - is negotiated. If not specified hardcode parameters will be used. - </item> - <tag>{ciphers, ciphers()}</tag> - <item>The function <c>ciphers_suites/0</c> can - be used to find all available ciphers. + <item>The cipher suites that should be supported. The function + <c>cipher_suites/0</c> can be used to find all available + ciphers. Additionally some anonymous cipher suites ({dh_anon, + rc4_128, md5}, {dh_anon, des_cbc, sha}, {dh_anon, + '3des_ede_cbc', sha}, {dh_anon, aes_128_cbc, sha}, {dh_anon, + aes_256_cbc, sha}) are supported for testing purposes and will + only work if explicitly enabled by this option and they are supported/enabled + by the peer also. </item> <tag>{ssl_imp, ssl_imp()}</tag> @@ -237,13 +184,165 @@ end new. </item> + <tag>{secure_renegotiate, boolean()}</tag> + <item>Specifies if to reject renegotiation attempt that does + not live up to RFC 5746. By default secure_renegotiate is + set to false i.e. secure renegotiation will be used if possible + but it will fallback to unsecure renegotiation if the peer + does not support RFC 5746. + </item> + + <tag>{depth, integer()}</tag> + <item>Specifies the maximum + verification depth, i.e. how far in a chain of certificates the + verification process can proceed before the verification is + considered to fail. Peer certificate = 0, CA certificate = 1, + higher level CA certificate = 2, etc. The value 2 thus means + that a chain can at most contain peer cert, CA cert, next CA + cert, and an additional CA cert. The default value is 1. + </item> + + <tag>{verify_fun, {Verifyfun :: fun(), InitialUserState :: term()}}</tag> + <item> + <p>The verification fun should be defined as:</p> + + <code> +fun(OtpCert :: #'OTPCertificate'{}, Event :: {bad_cert, Reason :: atom()} | + {extension, #'Extension'{}}, InitialUserState :: term()) -> + {valid, UserState :: term()} | {valid_peer, UserState :: term()} | + {fail, Reason :: term()} | {unknown, UserState :: term()}. + </code> + + <p>The verify fun will be called during the X509-path + validation when an error or an extension unknown to the ssl + application is encountered. Additionally it will be called + when a certificate is considered valid by the path validation + to allow access to each certificate in the path to the user + application. Note that the it will differentiate between the + peer certificate and CA certificates by using valid_peer or + valid as the second argument to the verify fun. See <seealso + marker="public_key:cert_records">the public_key User's + Guide</seealso> for definition of #'OTPCertificate'{} and + #'Extension'{}.</p> + + <p>If the verify callback fun returns {fail, Reason}, the + verification process is immediately stopped and an alert is + sent to the peer and the TLS/SSL handshake is terminated. If + the verify callback fun returns {valid, UserState}, the + verification process is continued. If the verify callback fun + always returns {valid, UserState}, the TLS/SSL handshake will + not be terminated with respect to verification failures and + the connection will be established. If called with an + extension unknown to the user application the return value + {unknown, UserState} should be used.</p> + + <p>The default verify_fun option in verify_peer mode:</p> + + <code> +{fun(_,{bad_cert, _} = Reason, _) -> + {fail, Reason}; + (_,{extension, _}, UserState) -> + {unknown, UserState}; + (_, valid, UserState) -> + {valid, UserState}; + (_, valid_peer, UserState) -> + {valid, UserState} + end, []} + </code> + + <p>The default verify_fun option in verify_none mode:</p> + + <code> +{fun(_,{bad_cert, _}, UserState) -> + {valid, UserState}; + (_,{extension, _}, UserState) -> + {unknown, UserState}; + (_, valid, UserState) -> + {valid, UserState}; + (_, valid_peer, UserState) -> + {valid, UserState} + end, []} + </code> + +<p>Possible path validation errors: </p> + +<p> {bad_cert, cert_expired}, {bad_cert, invalid_issuer}, {bad_cert, invalid_signature}, {bad_cert, unknown_ca},{bad_cert, selfsigned_peer}, {bad_cert, name_not_permitted}, {bad_cert, missing_basic_constraint}, {bad_cert, invalid_key_usage}</p> + </item> + + <tag>{hibernate_after, integer()|undefined}</tag> + <item>When an integer-value is specified, the <code>ssl_connection</code> + will go into hibernation after the specified number of milliseconds + of inactivity, thus reducing its memory footprint. When + <code>undefined</code> is specified (this is the default), the process + will never go into hibernation. + </item> + </taglist> + + </section> + + <section> + <title>SSL OPTION DESCRIPTIONS - CLIENT SIDE</title> + + <p>Options described here are client specific or has a slightly different + meaning in the client than in the server.</p> + + <taglist> + <tag>{verify, verify_type()}</tag> + <item> In verify_none mode the default behavior will be to + allow all x509-path validation errors. See also the verify_fun + option. + </item> <tag>{reuse_sessions, boolean()}</tag> - <item>Specifies if ssl sessions should be reused - when possible. + <item>Specifies if client should try to reuse sessions + when possible. </item> - <tag>{reuse_session, fun(SuggestedSessionId, - PeerCert, Compression, CipherSuite) -> boolean()}</tag> + </taglist> + </section> + + <section> + <title>SSL OPTION DESCRIPTIONS - SERVER SIDE</title> + + <p>Options described here are server specific or has a slightly different + meaning in the server than in the client.</p> + + <taglist> + + <tag>{dh, der_encoded()}</tag> + <item>The DER encoded Diffie Hellman parameters. If this option + is supplied it will override the dhfile option. + </item> + + <tag>{dhfile, path()}</tag> + <item>Path to file containing PEM encoded Diffie Hellman parameters, + for the server to use if a cipher suite using Diffie Hellman key exchange + is negotiated. If not specified default parameters will be used. + </item> + + <tag>{verify, verify_type()}</tag> + <item>Servers only do the x509-path validation in verify_peer + mode, as it then will send a certificate request to the client + (this message is not sent if the verify option is verify_none) + and you may then also want to specify the option + fail_if_no_peer_cert. + </item> + + <tag>{fail_if_no_peer_cert, boolean()}</tag> + <item>Used together with {verify, verify_peer} by a ssl server. + If set to true, the server will fail if the client does not have + a certificate to send, i.e. sends a empty certificate, if set to + false it will only fail if the client sends a invalid + certificate (an empty certificate is considered valid). + </item> + + <tag>{reuse_sessions, boolean()}</tag> + <item>Specifies if the server should agree to reuse sessions + when the clients request to do so. See also the reuse_session + option. + </item> + + <tag>{reuse_session, fun(SuggestedSessionId, + PeerCert, Compression, CipherSuite) -> boolean()}</tag> <item>Enables the ssl server to have a local policy for deciding if a session should be reused or not, only meaning full if <c>reuse_sessions</c> is set to true. @@ -252,14 +351,6 @@ end and CipherSuite of type ciphersuite(). </item> - <tag>{secure_renegotiate, boolean()}</tag> - <item>Specifies if to reject renegotiation attempt that does - not live up to RFC 5746. By default secure_renegotiate is - set to false e.i. secure renegotiation will be used if possible - but it will fallback to unsecure renegotiation if the peer - does not support RFC 5746. - </item> - </taglist> </section> @@ -316,7 +407,7 @@ end <v>Reason = term()</v> </type> <desc> <p>Upgrades a gen_tcp, or equivalent, - connected socket to a ssl socket e.i performs the + connected socket to a ssl socket i.e. performs the client-side ssl handshake.</p> </desc> </func> @@ -559,12 +650,12 @@ end </type> <desc> <p> Upgrades a gen_tcp, or - equivalent, socket to a ssl socket e.i performs the + equivalent, socket to a ssl socket i.e. performs the ssl server-side handshake.</p> - <p><note>Note that the listen socket should be in {active, false} mode + <p><warning>Note that the listen socket should be in {active, false} mode before telling the client that the server is ready to upgrade and calling this function, otherwise the upgrade may - or may not succeed depending on timing.</note></p> + or may not succeed depending on timing.</warning></p> </desc> </func> diff --git a/lib/ssl/doc/src/ssl_distribution.xml b/lib/ssl/doc/src/ssl_distribution.xml index 4067fb8a22..7bcc12eb5f 100644 --- a/lib/ssl/doc/src/ssl_distribution.xml +++ b/lib/ssl/doc/src/ssl_distribution.xml @@ -1,10 +1,10 @@ -<?xml version="1.0" encoding="latin1" ?> +<?xml version="1.0" encoding="iso-8859-1" ?> <!DOCTYPE chapter SYSTEM "chapter.dtd"> <chapter> <header> <copyright> - <year>2000</year><year>2009</year> + <year>2000</year><year>2010</year> <holder>Ericsson AB. All Rights Reserved.</holder> </copyright> <legalnotice> @@ -36,7 +36,7 @@ <note><p>Note this documentation is written for the old ssl implementation and - will be updated for the new one once this functionallity is + will be updated for the new one once this functionality is supported by the new implementation.</p></note> </p> @@ -55,7 +55,7 @@ all participating Erlang nodes in a distributed system must use this distribution module.</p> <p>The security depends on how the connections are set up, one can - use key files or certificates to just get a crypted + use key files or certificates to just get a encrypted connection. One can also make the SSL package verify the certificates of other nodes to get additional security. Cookies are however always used as they can be used to @@ -179,7 +179,7 @@ Eshell V5.0 (abort with ^G) <c>certfile</c> can (and usually needs to) be specified as <c>client_certfile</c> and <c>server_certfile</c>. The <c>client_certfile</c> is used when the distribution initiates a - connection to another node and the <c>server_cerfile</c> is used + connection to another node and the <c>server_certfile</c> is used when accepting a connection from a remote node. </p> <p>The command line argument for specifying the SSL options is named <c>-ssl_dist_opt</c> and should be followed by an even number of diff --git a/lib/ssl/doc/src/ssl_protocol.xml b/lib/ssl/doc/src/ssl_protocol.xml index 726b9a4eeb..6936408881 100644 --- a/lib/ssl/doc/src/ssl_protocol.xml +++ b/lib/ssl/doc/src/ssl_protocol.xml @@ -1,10 +1,10 @@ -<?xml version="1.0" encoding="latin1" ?> +<?xml version="1.0" encoding="iso-8859-1" ?> <!DOCTYPE chapter SYSTEM "chapter.dtd"> <chapter> <header> <copyright> - <year>2003</year><year>2009</year> + <year>2003</year><year>2010</year> <holder>Ericsson AB. All Rights Reserved.</holder> </copyright> <legalnotice> @@ -44,7 +44,7 @@ <section> <title>Security overview</title> - <p>To achive authentication and privacy the client and server will + <p>To achieve authentication and privacy the client and server will perform a TLS Handshake procedure before transmitting or receiving any data. During the handshake they agree on a protocol version and cryptographic algorithms, they generate shared secrets using public @@ -56,7 +56,7 @@ <title>Data Privacy and Integrity</title> <p>A <em>symmetric key</em> algorithm has one key only. The key is - used for both encryption and decryption. These algoritms are fast + used for both encryption and decryption. These algorithms are fast compared to public key algorithms (using two keys, a public and a private one) and are therefore typically used for encrypting bulk data. @@ -66,7 +66,7 @@ for each connection and are based on a secret negotiated in the TLS handshake. </p> - <p>The TLS handsake protocol and data transfer is run on top of + <p>The TLS handshake protocol and data transfer is run on top of the TLS Record Protocol that uses a keyed-hash MAC (Message Authenticity Code), or HMAC, to protect the message's data integrity. From the TLS RFC "A Message Authentication Code is a @@ -85,7 +85,7 @@ with the private key of the issuer of the certificate. A chain of trust is build by having the issuer in its turn being certified by an other certificate and so on until you reach the - so called root certificate that is self signed e.i. issued + so called root certificate that is self signed i.e. issued by itself.</p> <p>Certificates are issued by <em>certification diff --git a/lib/ssl/doc/src/ssl_session_cache_api.xml b/lib/ssl/doc/src/ssl_session_cache_api.xml index 7b70c6cf34..e0b07961fb 100644 --- a/lib/ssl/doc/src/ssl_session_cache_api.xml +++ b/lib/ssl/doc/src/ssl_session_cache_api.xml @@ -1,4 +1,4 @@ -<?xml version="1.0" encoding="latin1" ?> +<?xml version="1.0" encoding="iso-8859-1" ?> <!DOCTYPE erlref SYSTEM "erlref.dtd"> <erlref> @@ -25,7 +25,7 @@ </header> <module>ssl_session_cache_api</module> <modulesummary>Defines the API for the TLS session cache so - that the datastorge scheme can be replaced by + that the data storage scheme can be replaced by defining a new callback module implementing this API.</modulesummary> <section> @@ -56,7 +56,7 @@ <v> Key = key()</v> </type> <desc> - <p> Delets a cache entry. Will only be called from the cache + <p> Deletes a cache entry. Will only be called from the cache handling process. </p> </desc> @@ -85,10 +85,10 @@ <v></v> </type> <desc> - <p>Performes possible initializations of the cache and returns + <p>Performs possible initializations of the cache and returns a reference to it that will be used as parameter to the other api functions. Will be called by the cache handling processes - init function, hence puting the same requierments on it as + init function, hence putting the same requirements on it as a normal process init function. </p> </desc> @@ -96,16 +96,16 @@ <func> <name>lookup(Cache, Key) -> Entry</name> - <fsummary> Looks up a cach entry.</fsummary> + <fsummary> Looks up a cache entry.</fsummary> <type> <v> Cache = cache_ref()</v> <v> Key = key()</v> <v> Entry = session() | undefined </v> </type> <desc> - <p>Looks up a cach entry. Should be callable from any - process. - </p> + <p>Looks up a cache entry. Should be callable from any + process. + </p> </desc> </func> @@ -127,7 +127,7 @@ <func> <name>terminate(Cache) -> _</name> <fsummary>Called by the process that handles the cache when it - is aboute to terminat.</fsummary> + is about to terminate.</fsummary> <type> <v>Cache = term() - as returned by init/0</v> </type> diff --git a/lib/ssl/doc/src/using_ssl.xml b/lib/ssl/doc/src/using_ssl.xml index 4bdd8f97b4..605290b6f9 100644 --- a/lib/ssl/doc/src/using_ssl.xml +++ b/lib/ssl/doc/src/using_ssl.xml @@ -4,7 +4,7 @@ <chapter> <header> <copyright> - <year>2003</year><year>2009</year> + <year>2003</year><year>2011</year> <holder>Ericsson AB. All Rights Reserved.</holder> </copyright> <legalnotice> |