aboutsummaryrefslogtreecommitdiffstats
path: root/lib/ssl/src/ssl_handshake.erl
AgeCommit message (Collapse)Author
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-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
2014-04-23ssl: always pass negotiated version when selecting hashsignDanil Zagoskin
Negotiated version is now always passed to ssl_handshake:select_hashsign because ssl_handshake:select_cert_hashsign has different rsa defaults on tlsv1.2 and older versions.
2014-04-23ssl: TLSv1.2: proper default sign algo for RSADanil Zagoskin
2014-04-16ssl: Select supported cipher suites for the negotiated SSL/TLS-versionIngela Anderton Andin
When selecting the available cipher suites for the server all cipher suites for the highest supported SSL/TLS-version would be selected, and not all supported for the negotiated SSL/TLS-version. This could lead to that faulty clients could negotiate cipher suites that they can not support. This change will enable the faulty client to negotiate another cipher suite that it can support.
2014-03-25ssl: Improve type specsIngela Anderton Andin
Conflicts: lib/ssl/src/dtls_record.erl
2014-03-14ssl: Server now ignores client ECC curves that it does not support instead ofIngela Anderton Andin
crashing. When TLS client sends Supported Elliptic Curves Client Hello Extension the server shall select a curve supported by both sides or refuse to negotiate the use of an ECC cipher suite.
2014-02-25ssl: Fix compiler warningsIngela Anderton Andin
2014-01-28Fix incorrect use of public_key:private_key/0 typeTuncer Ayaz
public_key:private_key/0 was referenced but undefined, and lib/ssl had a local definition of private_key/0. To fix that, make the following changes: * add public_key:private_key/0 type * document public_key/0 and private_key/0 * fix incorrect definitions and references
2014-01-28Merge branch 'ia/Vagabond/adt-honor-cipher-order/OTP-11621'Ingela Anderton Andin
* ia/Vagabond/adt-honor-cipher-order/OTP-11621: Implement 'honor_cipher_order' SSL server-side option
2014-01-22ssl: Incorrect inputed cipherlist lead server to think that the clientIngela Anderton Andin
did not support secure renegotiation
2014-01-21Implement 'honor_cipher_order' SSL server-side optionAndrew Thompson
HonorCipherOrder as implemented in Apache, nginx, lighttpd, etc. This instructs the server to prefer its own cipher ordering rather than the client's and can help protect against things like BEAST while maintaining compatability with clients which only support older ciphers. This code is mostly written by Andrew Thompson, only the test case was added by Andreas Schultz.
2014-01-14ssl: fix elliptic curve selection in server modeAndreas Schultz
The server code erroneously took the list of curves supported by the client from it's own hello extension, effectively breaking curve selection all together. Also the default fallback secp256k1 curve is not supported by all clients. secp256r1 is recommended as part of the NIST Suite B cryptographic suites. The chances are much better that all clients support it, so use that as fallback.
2013-12-02ssl: Refactor APIIngela Anderton Andin
New design : ssl - Main tls - Reflect tls specific semantics dtls - Reflect dtls specific semantics
2013-12-02ssl, public_key: Dialyzer fixesIngela Anderton Andin
2013-12-02ssl: Refactor premaster secret handlingIngela Anderton Andin
2013-12-02ssl: Refactor connection and handshake handlingIngela Anderton Andin
2013-11-06Add a new server_name_indication option to ssl:connectJulien Barbot
- Set to disable to explicitly disable SNI support. - Set to a hostname when upgrading from TCP to TLS.
2013-11-06Add SSL Server Name Indication (SNI) client supportJulien Barbot
See RFC 6066 section 3
2013-10-14ssl: Honor TLS client ECC extensionIngela Anderton Andin
Also the server should only send ECC point formats extension not ECC curve extension.
2013-09-10ssl: Refactor TLS/DTLS record handlingIngela Anderton Andin
2013-09-10ssl: Dialyzer fixesIngela Anderton Andin
2013-09-10ssl: Solve rebase issuesIngela Anderton Andin
2013-09-10ssl: DTLS record handlingIngela Anderton Andin
Also refactor so that TLS and DTLS can have common functions when possible.
2013-09-10ssl: Refactor to provide common handshake functions for TLS/DTLSIngela Anderton Andin
Common functions will be located in ssl_handshake.erl while specific functions will be located in tls_handshake.erl and dtls_handshake.erl
2013-06-04ssl: Structural perarparation to support DTLSIngela Anderton Andin
Also phase in tls module as main API instead of ssl. To make API clearer. As TLS is the new protocol name. Maybe keep some API functions in ssl
2013-06-04ssl: Rename ssl_certificate_db to ssl_pkix_db for clarityIngela Anderton Andin
Conflicts: lib/ssl/src/ssl.app.src lib/ssl/src/ssl_manager.erl
2013-05-20ssl, public_key, crypto: crypto:algorithms/0 -> crypto:supports/0Ingela Anderton Andin
2013-05-08ssl: Only send ECC-hello extension if ECC-cipher suites are advertisedIngela Anderton Andin
2013-05-08crypto: Deprecate functions, update doc and specsIngela Anderton Andin