aboutsummaryrefslogtreecommitdiffstats
path: root/lib/ssl/src/ssl_connection.erl
AgeCommit message (Collapse)Author
2017-11-16ssl: Align code of main modules implementing the gen_statem behaviourIngela Anderton Andin
2017-10-17Merge branch 'ingela/ssl/extend-hostname-check/OTP-14632/OTP-14655' into maintIngela Anderton Andin
* ingela/ssl/extend-hostname-check/OTP-14632/OTP-14655: ssl: Fix test cases to work on all test platforms public_key: Fix dialyzer spec ssl: Sessions must be registered with SNI if exists ssl: Extend hostname check to fallback to checking IP-address public_key, ssl: Handles keys so that APIs are preserved correctly
2017-10-16 ssl: Use ?FUNCTION_NAMEIngela Anderton Andin
Use ?FUNCTION_NAME macro to enhance code as we will not back-port this version of the ssl application to versions pre OTP 19.
2017-10-13ssl: Sessions must be registered with SNI if existsIngela Anderton Andin
2017-10-13ssl: Extend hostname check to fallback to checking IP-addressIngela Anderton Andin
If no SNI is available and the hostname is an IP-address also check for IP-address match. This check is not as good as a DNS hostname check and certificates using IP-address are not recommended.
2017-09-30dtls: Compleate DTLS renegotiate implementationIngela Anderton Andin
2017-09-01ssl: Add the role (server or client) to the alert messageIngela Anderton Andin
It is desirable to be as specific as possible in the info message, so there can be no mistake if the alert is form the peer or generated by us. This use to be an error message, but it is better to make it an info message as sending an ALERT ending the connection is an expected behaviour.
2017-08-23ssl: negotiated_hashsign/4 expects TLS version to function correctlyIngela Anderton Andin
Only DTLS specific code deals with DTLS version, when common code is used the DTLS version should be converted to the corresponding TLS version.
2017-08-10Merge pull request #1507 from vances/issue-erl-442Ingela Andin
Correct type specification in ssl:prf/5
2017-07-10Correct type specification in ssl:prf/5Vance Shipley
Current implementation expects Seed to be a list. Correct type specification to match.
2017-07-07ssl: Enhance error loggingIngela Anderton Andin
2017-05-16ssl: Adopt setopts and getopts for DTLSIngela Anderton Andin
2017-05-12Merge branch 'maint'Hans Nilsson
Conflicts: OTP_VERSION lib/inets/vsn.mk lib/ssl/vsn.mk
2017-05-11removed ct:pal call in ssl_connectionJoe DeVivo
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-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-10Update copyright yearRickard Green
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.