aboutsummaryrefslogtreecommitdiffstats
path: root/lib/ssl/src/ssl_connection.erl
AgeCommit message (Collapse)Author
2018-07-10ssl: Correct connection_information on ECC-curvesIngela Anderton Andin
2018-07-10ssl: Avoid hardcoding of cipher suites and fix ECDH suite handlingIngela Anderton Andin
ECDH suite handling did not use the EC parameters form the certs as expected. Conflicts: lib/ssl/src/ssl_cipher.erl
2018-04-27ssl: Proper handling of clients that choose to send an emptyIngela Anderton Andin
answer to a certificate request Solves ERL-599
2018-02-09ssl: Add the unexpected message to #alert{}Jean-Sébastien Pédron
... in handle_common_event(), instead of passing it to handle_own_alert() after wrapping it in a tuple with `StateName` (i.e. `{StateName, Msg}`). The `StateName` is passed to handle_normal_shutdown() and to alert_user(). The latter has a clause matching it against `connection`. Unfortunately, when the argument was in fact `{StateName, Msg}`, another clause was executed which dropped the `active` flag value and forced it to `false`, even if the state was actually `connection`. It meant that later in send_or_reply(), the alert was not propagated to the user, even though it should (`active` set to `true` or `once`). Now that handle_common_event() always passes the actual `StateName`, the problem is fixed. ERL-562
2017-12-05ssl: Use maps for cipher suites internallyIngela Anderton Andin
This is a preparation for improvements to come in option handling and support for TLS-1.3
2017-12-01Merge branch 'ingela/ssl/timing' into maintIngela Anderton Andin
* ingela/ssl/timing: ssl: Align timing just in case
2017-11-28ssl: Align timing just in caseIngela Anderton Andin
2017-11-24ssl: Use genstamtem properlyIngela Anderton Andin
2017-11-23Merge branch 'maint-20' into maintIngela Anderton Andin
* maint-20: Updated OTP version Update release notes Update version numbers public_key: verify ip (both v4 and v6) public_key: Added IP4 address checks to hostname_verification tests 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 ssl: Use ?FUNCTION_NAME ssl: Prepare for release ssl: Countermeasurements for Bleichenbacher attack Conflicts: lib/public_key/doc/src/public_key.xml lib/public_key/test/public_key_SUITE.erl lib/public_key/test/public_key_SUITE_data/pkix_verify_hostname_subjAltName_IP.pem lib/public_key/test/public_key_SUITE_data/verify_hostname_ip.conf lib/ssl/src/dtls_connection.erl lib/ssl/src/ssl_connection.erl lib/ssl/src/ssl_handshake.erl
2017-11-22Merge branch ↵Erlang/OTP
'ingela/maint-20/ssl/extend-hostname-check/OTP-14632/OTP-14655/OTP-14766' into maint-20 * ingela/maint-20/ssl/extend-hostname-check/OTP-14632/OTP-14655/OTP-14766: 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 ssl: Use ?FUNCTION_NAME
2017-11-16ssl: Align code of main modules implementing the gen_statem behaviourIngela Anderton Andin
2017-11-09ssl: Sessions must be registered with SNI if existsIngela Anderton Andin
2017-11-09ssl: 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-11-09 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-11-09ssl: Countermeasurements for Bleichenbacher attackIngela 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
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-27 06:40:54 +0000