aboutsummaryrefslogtreecommitdiffstats
path: root/lib/ssl/src/ssl_handshake.erl
AgeCommit message (Collapse)Author
2017-07-07ssl: Try to make asn1 decode errors of certificates as specific as possibleIngela Anderton Andin
2017-07-07ssl,public_key: Provide details for CRL check failiures when revokation ↵Ingela Anderton Andin
state can not be determined
2017-05-19ssl: Add missing algorithm ecdh_ecdsaIngela Anderton Andin
2017-05-06ssl: Add hostname check of server certificateIngela Anderton Andin
When the server_name_indication is sent automatize the clients check of that the hostname is present in the servers certificate. Currently server_name_indication shall be on the dns_id format. If server_name_indication is disabled it is up to the user to do its own check in the verify_fun.
2017-05-04Update copyright yearRaimo Niskanen
2017-04-21ssl: TLS-1.2 clients will now always send hello messages on its own format.Ingela Anderton Andin
Note this is a change form how it works for earlier versions that will send the first hello message on the lowest supported version. From RFC 5246 Appendix E. Backward Compatibility E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 Since there are various versions of TLS (1.0, 1.1, 1.2, and any future versions) and SSL (2.0 and 3.0), means are needed to negotiate the specific protocol version to use. The TLS protocol provides a built-in mechanism for version negotiation so as not to bother other protocol components with the complexities of version selection. TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use compatible ClientHello messages; thus, supporting all of them is relatively easy. Similarly, servers can easily handle clients trying to use future versions of TLS as long as the ClientHello format remains compatible, and the client supports the highest protocol version available in the server. A TLS 1.2 client who wishes to negotiate with such older servers will send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in ClientHello.client_version. If the server does not support this version, it will respond with a ServerHello containing an older version number. If the client agrees to use this version, the negotiation will proceed as appropriate for the negotiated protocol. If the version chosen by the server is not supported by the client (or not acceptable), the client MUST send a "protocol_version" alert message and close the connection. If a TLS server receives a ClientHello containing a version number greater than the highest version supported by the server, it MUST reply according to the highest version supported by the server. A TLS server can also receive a ClientHello containing a version number smaller than the highest supported version. If the server wishes to negotiate with old clients, it will proceed as appropriate for the highest version supported by the server that is not greater than ClientHello.client_version. For example, if the server supports TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will proceed with a TLS 1.0 ServerHello. If server supports (or is willing to use) only versions greater than client_version, it MUST send a "protocol_version" alert message and close the connection. Whenever a client already knows the highest protocol version known to a server (for example, when resuming a session), it SHOULD initiate the connection in that native protocol. Note: some server implementations are known to implement version negotiation incorrectly. For example, there are buggy TLS 1.0 servers that simply close the connection when the client offers a version newer than TLS 1.0. Also, it is known that some servers will refuse the connection if any TLS extensions are included in ClientHello. Interoperability with such buggy servers is a complex topic beyond the scope of this document, and may require multiple connection attempts by the client. Earlier versions of the TLS specification were not fully clear on what the record layer version number (TLSPlaintext.version) should contain when sending ClientHello (i.e., before it is known which version of the protocol will be employed). Thus, TLS servers compliant with this specification MUST accept any value {03,XX} as the record layer version number for ClientHello. TLS clients that wish to negotiate with older servers MAY send any value {03,XX} as the record layer version number. Typical values would be {03,00}, the lowest version number supported by the client, and the value of ClientHello.client_version. No single value will guarantee interoperability with all old servers, but this is a complex topic beyond the scope of this document.
2017-01-26ssl: The certificate path may be used as a source to find intermediate CAs ↵Ingela Anderton Andin
for the CRL
2017-01-24ssl: Handle more than one DistributionPointIngela Anderton Andin
2016-11-02Add ECC curve selection order config in TLS serverFred Hebert
As per RFC 4492 Sec 5.1, the preferred order of selection of named curves is based on client preferences. Currently, the SSL application only picks entries according to the absolute order of entries as tracked in a hardcoded list in code. This patch changes things so that the client-specified order is preferred. It also allows a mode where the server can be configured to override the client's preferred order with its own, although the chosen ECC must still be within both lists. The configuration is done through the following options: - `eccs`, shared by clients and servers alike, allows the specification of the supported named curves, in their preferred order, and may eventually support more values for explicit primes and so on. - `honor_ecc_order`, a server-only option, is similar to `honor_cipher_order` and will, by default let the server pick the client-preferred ECC, and otherwise pick the server-preferred one. The default value for `eccs` is the same as before, although the server-chosen ECC now defaults to the client rather than previous choice. A function `ssl:eccs()` has been added that returns the highest supported ECCs for the library.
2016-09-12Merge branch 'ferd/bypass-pem-cache/PR-1143/OTP-13883' into maintIngela Anderton Andin
* ferd/bypass-pem-cache/PR-1143/OTP-13883: ssl: Add documentation of bypass_pem_cache application environment configuration ssl: Add new benchmarks to skip file for normal testing Adding PEM cache bypass benchmark entries Fixing CRL searching in cache bypass Add option to bypass SSL PEM cache
2016-09-05ssl: Refactor to use maps for the connection statesIngela Anderton Andin
2016-09-05ssl, dtls: Disable V2 compatibility clause from ↵Ingela Anderton Andin
ssl_handshake:update_handshake_history This proably a much bigger problem for DTLS than TLS, but should be disabled for both unless explicitly configured for TLS.
2016-09-05ssl: remove unused RecordCB argument from master_secretAndreas Schultz
Conflicts: lib/ssl/src/ssl_handshake.erl
2016-08-19Add option to bypass SSL PEM cacheFred Hebert
The current SSL implementation has a PEM cache running through the ssl manager process, whose primary role is caching CA chains from files on disk. This is intended as a way to save on disk operation when the requested certificates are often the same, and those cache values are both time-bound and reference-counted. The code path also includes caching the Erlang-formatted certificate as decoded by the public_key application The same code path is used for DER-encoded certificates, which are passed in memory and do not require file access. These certificates are cached, but not reference-counted and also not shared across connections. For heavy usage of DER-encoded certificates, the PEM cache becomes a central bottleneck for a server, forcing the decoding of every one of them individually through a single critical process. It is also not clear if the cache remains useful for disk certificates in all cases. This commit adds a configuration variable for the ssl application (bypass_pem_cache = true | false) which allows to open files and decode certificates in the calling connection process rather than the manager. When this action takes place, the operations to cache and return data are replaced to strictly return data. To provide a transparent behaviour, the 'CacheDbRef' used to keep track of the certificates in the cache is replaced by the certificates itself, and all further lookup functions or folds can be done locally. This has proven under benchmark to more than triple the performance of the SSL application under load (once the session cache had also been disabled).
2016-08-09ssl: Conform to dialyzer specIngela Anderton Andin
2016-07-25Merge branch 'maint-18' into maintRaimo Niskanen
Conflicts: OTP_VERSION erts/doc/src/notes.xml erts/vsn.mk lib/common_test/doc/src/notes.xml lib/common_test/vsn.mk lib/ssl/doc/src/notes.xml lib/ssl/src/ssl.appup.src lib/ssl/vsn.mk lib/stdlib/test/ets_SUITE.erl otp_versions.table
2016-07-21Improve version selectionRaimo Niskanen
Use the list of versions that the server allows and among those choose the highest version that is not higher than the client's version. Note that this chosen version might be lower than the client's version, but is used to improve interoperability. Patch suggested by Dimitry Borisov refering to RFC 5246 appendix E.1.
2016-07-08ssl: Correct handling of signature algorithm selectionIngela Anderton Andin
In TLS-1.2 the selection of the servers algorithms and the the possible selection of algorithms for the client certificate verify message have different requirements.
2016-06-15Merge branch 'ingela/ssl/dtls-next-step-flights/OTP-13678'Ingela Anderton Andin
* ingela/ssl/dtls-next-step-flights/OTP-13678: dtls: Avoid dialyzer errors dtls: add implementation for msg sequence dtls: Remove TODO dtls: sync dtls_record DTLS version and crypto handling with TLS dtls: handle Hello and HelloVerify's in dtls_handshake dtls: rework/simplify DTLS fragment decoder dtls: add support first packet and HelloVerifyRequest dtls: sync handle_info for connection close with TLS dtls: sync handling of ClientHello with TLS dtls: rework handshake flight encodeing dtls: implement next_tls_record dtls: sync init and initial_state with tls_connection dtls: update start_fsm for new ssl_connection API ssl: introduce the notion of flights for dtls and tls ssl: move available_signature_algs to ssl_handshake
2016-06-14Merge branch 'legoscia/ssl_crl_hash_dir-bis/PR-982/OTP-13530'Ingela Anderton Andin
* legoscia/ssl_crl_hash_dir-bis/PR-982/OTP-13530: Skip crl_hash_dir_expired test for LibreSSL Add ssl_crl_hash_dir module Function for generating OpenSSL-style name hashes Add public_key:pkix_match_dist_point Improve formatting for crl_{check,cache} options Add issuer arg to ssl_crl_cache_api lookup callback Conflicts: lib/public_key/test/public_key_SUITE.erl
2016-06-13ssl: move available_signature_algs to ssl_handshakeAndreas Schultz
available_signature_algs is also needed for DTLS, move it into a shared place and export it. Conflicts: lib/ssl/src/tls_handshake.erl
2016-06-09ssl: Use cipher suite's PRF in prf/5Kenneth Lakin
Use the negotiated cipher suite's PRF algorithm in calls to ssl:prf/5, rather than a hard-coded one. For TLS 1.0 the PRF algorithm was hard-coded to MD5/SHA1. This was correct 100% of the time. For TLS 1.1 and 1.2 the PRF algorithm was hard-coded to SHA256. This was correct only some of the time for TLS 1.2 and none of the time for TLS 1.1. Because the TLS handshake code calls tls_v1:prf/5 through another path, the handshaking process used the negotiated PRF and did not encounter this bug. A new test (prf) has been added to ssl_basic_SUITE to guard against future breakage.
2016-05-31ssl: Remove error logger reportsIngela Anderton Andin
We do not want error reports that can leek secret information into the logs.
2016-05-31ssl: Better error handling of keys rejected by cryptoIngela Anderton Andin
2016-05-31Improve SSL diagnosticsAlexey Lebedeff
There are a lot of cases where `ssl` application just returns unhelpful `handshake failure` or `internal error`. This patch tries to provide better diagnostics so operator can debug his SSL misconfiguration without doing hardcore erlang debugging. Here is an example escript that incorrectly uses server certificate as a client one: https://gist.github.com/binarin/35c34c2df7556bf04c8a878682ef3d67 With the patch it is properly reported as an error in "extended key usage".
2016-05-05ssl: Use cipher suite's PRF in prf/5Kenneth Lakin
Use the negotiated cipher suite's PRF algorithm in calls to ssl:prf/5, rather than a hard-coded one. For TLS 1.0 the PRF algorithm was hard-coded to MD5/SHA1. This was correct 100% of the time. For TLS 1.1 and 1.2 the PRF algorithm was hard-coded to SHA256. This was correct only some of the time for TLS 1.2 and none of the time for TLS 1.1. Because the TLS handshake code calls tls_v1:prf/5 through another path, the handshaking process used the negotiated PRF and did not encounter this bug. A new test (prf) has been added to ssl_basic_SUITE to guard against future breakage.
2016-04-13Merge branch 'henrik/update-copyrightyear'Henrik Nord
* henrik/update-copyrightyear: update copyright-year
2016-04-06ssl: Add option signature_algsIngela Anderton Andin
In TLS-1.2 The signature algorithm and the hash function algorithm used to produce the digest that is used when creating the digital signature may be negotiated through the signature algorithm extension RFC 5246. We want to make these algorithm pairs configurable. In connections using lower versions of TLS these algorithms are implicit defined and can not be negotiated or configured. DTLS is updated to not cause dialyzer errors, but needs to get a real implementation later.
2016-04-06ssl: Add option signature_algsIngela Anderton Andin
In TLS-1.2 The signature algorithm and the hash function algorithm used to produce the digest that is used when creating the digital signature may be negotiated through the signature algorithm extension RFC 5246. We want to make these algorithm pairs configurable. In connections using lower versions of TLS these algorithms are implicit defined and can not be negotiated or configured. DTLS is updated to not cause dialyzer errors, but needs to get a real implementation later.
2016-04-01Add issuer arg to ssl_crl_cache_api lookup callbackMagnus Henoch
Change the ssl_crl_cache_api callback specification, passing the certificate issuer name as an argument to the lookup callback function. Support the previous API too, for the time being. The purpose of this change is to accomodate CRL cache modules that index CRLs by issuer name, not by distribution point URL. While in most cases such lookups could be performed using the select/2 callback function, that doesn't work when the CRL in question contains an Issuing Distribution Point (IDP) extension, since RFC 5280 specifies different processing rules for CRLs specified in a distribution point (DP) and other CRLs. For the latter, a DP is assumed that most likely will not match the IDP of the CRL. In order to accommodate cache modules that index CRLs by issuer name, let's pass them the issuer as well.
2016-03-15update copyright-yearHenrik Nord
2016-02-17Be suspicious of certificates without CRL DPsMagnus Henoch
Previously, if certificate revocation checking was turned on, and a certificate didn't contain a CRL Distribution Points extension, and there was no relevant CRL in the cache, then ssl_handshake:crl_check would accept the certificate even if the crl_check option was set to reject certificates for which the revocation status could not be determined. With this change, such certificates will only be accepted if the crl_check option was set to best_effort. The process for CRL validation is described in section 6.3 of RFC 5280. The text doesn't mention any special treatment to be given to certificates without distribution points: it just says "For each distribution point..." (section 6.3.3), which would leave the revocation status undetermined, unless there were "any available CRLs not specified in a distribution point but issued by the certificate issuer". Thus the result of this algorithm should be UNDETERMINED in this case, not UNREVOKED, and the crl_check option should govern how the implementation reacts to this result.
2015-06-18Change license text to APLv2Bruce Yinhe
2015-06-02Merge branch 'maint'Henrik Nord
Conflicts: OTP_VERSION lib/inets/test/httpd_SUITE.erl lib/inets/vsn.mk lib/ssh/src/ssh.erl lib/ssh/vsn.mk lib/ssl/src/ssl.appup.src lib/ssl/vsn.mk
2015-05-29ssl: Correct handling of bad input to premaster_secret calculationIngela Anderton Andin
alert records needs to be thrown from ssl_handshake:premaster_secret/[2/3] so that operations will end up in the catch clause of the invokation of certify_client_key_exchange/3 in ssl_connection.erl, and hence terminate gracefully and not continue to try and calculate the master secret with invalid inputs and crash.
2015-04-20ssl: Ignore signature_algorithm (TLS 1.2 extension) sent to TLS 1.0/1 serverAndreas Schultz
pre TLS 1.2 server should ignore the signature_algorithms extension. The server code would attempt to select the signature/hash algorithm even when using TLS 1.0 or 1.1. Instead it should simply use the default algorithm on those versions.
2015-04-20ssl: Adjust to public_key application removing legacy compact_bit_string switchIngela Anderton Andin
2015-03-17ssl: Add TLS-ALPN supportLoïc Hoguin
This commit adds support for RFC7301, application-layer protocol negotiation. ALPN is the standard based approach to the NPN extension, and is required for HTTP/2. ALPN lives side by side with NPN and provides an equivalent feature but in this case it is the server that decides what protocol to use, not the client. When both ALPN and NPN are sent by a client, and the server is configured with both ALPN and NPN options, ALPN will always take precedence. This behavior can also be found in the OpenSSL implementation of ALPN. ALPN and NPN share the ssl:negotiated_protocol/1 function for retrieving the negotiated protocol. The previously existing function ssl:negotiated_next_protocol/1 still exists, but has been deprecated and removed from the documentation. The tests against OpenSSL require OpenSSL version 1.0.2+.
2015-03-11ssl: Dialyzer fixesIngela Anderton Andin
2015-03-09ssl: Integrate public_key CRL verification with the ssl applicationIngela Anderton Andin
2014-09-25Merge branch 'maint'Ingela Anderton Andin
2014-09-24ssl: Servers may include an empty SNI-extensionIngela Anderton Andin
2014-09-10Merge branch 'maint'Ingela Anderton Andin
2014-09-09ssl, public_key: Add new option partial_chainIngela Anderton Andin
Check that the certificate chain ends with a trusted ROOT CA e.i. a self-signed certificate, but provide an option partial_chain to enable the application to define an intermediat CA as trusted. TLS RFC says: "unknown_ca A valid certificate chain or partial chain was received, but the certificate was not accepted because the CA certificate could not be located or couldn't be matched with a known, trusted CA. This message is always fatal." and also states: "certificate_list This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case." X509 RFC says: "The selection of a trust anchor is a matter of policy: it could be the top CA in a hierarchical PKI, the CA that issued the verifier's own certificate(s), or any other CA in a network PKI. The path validation procedure is the same regardless of the choice of trust anchor. In addition, different applications may rely on different trust anchors, or may accept paths that begin with any of a set of trust anchors."
2014-09-03ssl: implement AES128-GCM suitesAndreas Schultz
2014-08-19ssl: Fix boolean expressionIngela Anderton Andin
2014-08-18ssl: Fix broken contractIngela Anderton Andin
2014-08-08ssl: Correct handling of certificate_types in Certificate RequestsIngela Anderton Andin
FROM TLS 1.2 RFC: The interaction of the certificate_types and supported_signature_algorithms fields is somewhat complicated. certificate_types has been present in TLS since SSLv3, but was somewhat underspecified. Much of its functionality is superseded by supported_signature_algorithms. The following rules apply: - Any certificates provided by the client MUST be signed using a hash/signature algorithm pair found in supported_signature_algorithms. - The end-entity certificate provided by the client MUST contain a key that is compatible with certificate_types. If the key is a signature key, it MUST be usable with some hash/signature algorithm pair in supported_signature_algorithms. - For historical reasons, the names of some client certificate types include the algorithm used to sign the certificate. For example, in earlier versions of TLS, rsa_fixed_dh meant a certificate signed with RSA and containing a static DH key. In TLS 1.2, this functionality has been obsoleted by the supported_signature_algorithms, and the certificate type no longer restricts the algorithm used to sign the certificate. For example, if the server sends dss_fixed_dh certificate type and {{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply with a certificate containing a static DH key, signed with RSA- SHA1.
2014-06-01ssl: parse SNI in received client hello recordsAndrás Veres-Szentkirályi
2014-04-23ssl: Refactor so that there is only one source for the default hashsign valuesIngela Anderton Andin
Also fix DTLS call to supply its corresponding TLS version