aboutsummaryrefslogtreecommitdiffstats
path: root/lib/ssl/src/ssl_connection.erl
AgeCommit message (Collapse)Author
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-03-21ssl: Add connection information itemsIngela Anderton Andin
Add session_id and remove undocumented ssl:session_info/1 Add client_random, server_random and master_secret, they will not be included in ssl:connection_information/1 as they may affect the connections security if used recklessly.
2017-03-08Merge branch 'maint'Ingela Anderton Andin
2017-03-06dtls: Hibernation and retransmit timersIngela Anderton Andin
Change retransmissions timers to use gen_statem state timeouts. We do not need a retransmission timer in the state connection as data traffic in DTLS over UDP is not retransmitted. If the last flight before transitioning into connection is lost, it will be resent when the peer resends its last flight. This will also make hibernation testing more straight forward. We need more adjustments later to handle a reliable DTLS transport such as SCTP.
2017-03-06dtls: DTLS specific handling of socket and ciphersIngela Anderton Andin
DTLS does not support stream ciphers and needs diffrent handling of the "#ssl_socket{}" handle .
2017-02-14Fixed typos in lib/sslAndrew Dryga
2017-02-01ssl: Simplify configuration codeIngela Anderton Andin
Use map instead of large tuple, which was not an option when the code was written originally. More simplifications along these lines may be done later to the state record.
2016-12-19ssl: Correct terminate behaviourIngela Anderton Andin
When the terminate function is called explicitly, to make guarantees that for instance the reuseaddr option works as expected, we must make sure that the clean up code is not run again when gen_statem calls terminate. This check was broken in the rewrite from gen_fsm to gen_statem. Caused PEM cache errors, that in some cases would cause unexpected connection failures.
2016-12-05ssl: Implement DTLS state machineIngela Anderton Andin
Beta DTLS, not production ready. Only very basically tested, and not everything in the SPEC is implemented and some things are hard coded that should not be, so this implementation can not be consider secure. Refactor "TLS connection state" and socket handling, to facilitate DTLS implementation. Create dtls "listner" (multiplexor) process that spawns DTLS connection process handlers. Handle DTLS fragmentation. Framework for handling retransmissions. Replay Detection is not implemented yet. Alerts currently always handled as in TLS.
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-28ssl: Correct ECC curve selection, the error could cause default to always be ↵Ingela Anderton Andin
selected.
2016-09-05ssl: Refactor to use maps for the connection statesIngela Anderton Andin
2016-09-05ssl, dtls: Refactor sni handlingIngela Anderton Andin
2016-09-05dtls: Add protocol event handlingIngela Anderton Andin
2016-09-05ssl: Refactor code so that tls and dtls can share more codeIngela Anderton Andin
We want to share more alert and application data handling code. Some of the application data handling code, packet handling, will not be relevant for dtls, but this code can be excluded from dtls by options checking.
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: Make sure common code for TLS and DTLS uses the TLS VersionIngela Anderton Andin
When protocol version is proagated from the DTLS connection processes state into general ssl functions it must be converted to the corresponding TLS version.
2016-09-05ssl: remove unused RecordCB argument from master_secretAndreas Schultz
Conflicts: lib/ssl/src/ssl_handshake.erl
2016-09-05dtls: replace tls_record with RecordCB in connection_infoAndreas Schultz
Conflicts: lib/ssl/src/ssl_connection.erl
2016-08-29ssl: Remove clause that postponed unexpected messagesIngela Anderton Andin
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-13ssl: introduce the notion of flights for dtls and tlsAndreas Schultz
The flight concept was introduced by DTLS (RFC 4347) to optimize the packing of DTLS records into UDP packets. This change implments the flight concept in the the generic SSL connection logic and add the queue logic to the TLS and DTLS stack. The DTLS required resend handling is not implemented yet. While the flight handling is only required for DTSL, it turns out that the same mechanism can be usefull to TCP based TLS as well. With the current scheme each TLS record will be mapped into a separate TCP frame. This causes more TCP frames to be generate that necessary. On fast network this will have no impact, but reducing the number of frames and thereby the number of round trips can result in significant speedups on slow and unreliable networks. Conflicts: lib/ssl/src/tls_connection.erl
2016-06-03ssl: Reject unrequested client certIngela Anderton Andin
2016-06-01ssl: simplyfy code using gen_statemIngela 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-19ssl: Setopts should be allowed in all statesIngela Anderton Andin
2016-05-09Merge branch 'kennethlakin/tls-use-negotiated-prf/PR-1042/OTP-13546'Ingela Anderton Andin
* kennethlakin/tls-use-negotiated-prf/PR-1042/OTP-13546: ssl: Use cipher suite's PRF in prf/5
2016-05-05ssl: Add reinitialization of handshake data lost in gen_statem refactorizationIngela Anderton Andin
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-05-03ssl: Use gen_statem instead of gen_fsmIngela Anderton Andin
Also reduce timing issues in tests
2016-04-25ssl: Remove use of crypto:rand_bytes/1Ingela Anderton Andin
ssl already used crypto:strong_rand_bytes/1 for most operations as its use cases are mostly cryptographical. Now crypto:strong_rand_bytes/1 will be used everywhere. However crypto:rand_bytes/1 was used as fallback if crypto:strong_rand_bytes/1 throws low_entropy, this will no longer be the case. This is a potential incompatibility. The fallback was introduced a long time ago for interoperability reasons. Now days this should not be a problem, and if it is, the security compromise is not acceptable anyway.
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-22ssl: Include options form connect/listen/accept in connection_information/[1,2]Ingela Anderton Andin
Make sure that options only relevant for one role (client|server) is set to undefined when the other role is invoked. As there are many options to ssl, and many are optional, we choose to filter out all undefined options to avoid overwhelming the user with not relevant information. This way there is no need for any special handling of the role specific options which is also nice.
2015-12-03ssl: Measure elapsed time with erlang:monotonic_timeIngela Anderton Andin
2015-10-28Avoid crash for SSL connections with nonexistent keyfileMagnus Henoch
Starting an SSL connection with a nonexistent keyfile will obviously return an error: > ssl:connect("www.google.com", 443, [{keyfile, "nonexistent"}]). {error,{options,{keyfile,"nonexistent",{error,enoent}}}} But it also generates an error report with the following backtrace: ** Reason for termination = ** {badarg,[{ets,select_delete, [undefined,[{{{undefined,'_','_'},'_'},[],[true]}]], []}, {ets,match_delete,2,[{file,"ets.erl"},{line,700}]}, {ssl_pkix_db,remove_certs,2,[{file,"ssl_pkix_db.erl"},{line,243}]}, {ssl_connection,terminate,3, [{file,"ssl_connection.erl"},{line,941}]}, {tls_connection,terminate,3, [{file,"tls_connection.erl"},{line,335}]}, {gen_fsm,terminate,7,[{file,"gen_fsm.erl"},{line,610}]}, {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,532}]}, {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,240}]}]} This happens because the ssl_connection process receives its cert_db while handling the {start, Timeout} message, but if the handshake fails, the cert_db will never be inserted into the state data, and the terminate function will use 'undefined' as an ETS table name. Avoid this by checking for 'undefined' in the handle_trusted_certs_db function.
2015-09-16ssl: Improve shutdown logicIngela Anderton Andin
Add possibility to downgrade an SSL/TLS connection to a tcp connection, and give back the socket control to a user process. Add application setting to be able to change fatal alert shutdown timeout, also shorten the default timeout. The fatal alert timeout is the number of milliseconds between sending of a fatal alert and closing the connection. Waiting a little while improves the peers chances to properly receiving the alert so it may shutdown gracefully.
2015-06-18Change license text to APLv2Bruce Yinhe
2015-05-12ssl: add ssl:connection_information/[1,2]Qijiang Fan
This commit adds a new function, ssl:connection_information/[1,2] to retrive the connection information from a SSLSocket. And also, this deprecates a function ssl:connection_info/1, and reimplements connection_info/1 with the new function.
2015-05-12ssl: add SNI server supportQijiang Fan
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-09ssl: Integrate public_key CRL verification with the ssl applicationIngela Anderton Andin
2014-12-01ssl: Change code to reflect that state data may be secretIngela 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-06-12ssl: Fix dialyzer specs to reflect realityIngela Anderton Andin
2014-06-11ssl: Make sure change cipher spec is correctly handledIngela Anderton Andin
2014-05-27ssl: Add format_status function to ssl connection processIngela Anderton Andin
2014-05-26ssl: Add ssl options to listen options trackerIngela Anderton Andin
2014-05-26ssl: Move initIngela Anderton Andin