aboutsummaryrefslogtreecommitdiffstats
path: root/lib/ssl/src/ssl.erl
AgeCommit message (Collapse)Author
2017-08-24ssl: DTLS packet supportIngela Anderton Andin
Test that DTLS handles "high" level packet types as http-packet types. Low level packet type as {packet, 2} we will consider later if they should be relevant to support or not.
2017-08-23ssl: Adjust ALPN and next protocol to work with DTLSIngela Anderton Andin
2017-07-10Correct type specification in ssl:prf/5Vance Shipley
Current implementation expects Seed to be a list. Correct type specification to match.
2017-06-10dtls: Handle getopts and setopts for DTLSIngela Anderton Andin
2017-05-16ssl: Adopt setopts and getopts for DTLSIngela 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-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-16ssl: Remove deprecated functionsIngela Anderton Andin
2017-03-10dtls: Correct version checkIngela Anderton Andin
2017-03-06dtls: Correct dialyzer spec and postpone inclusion of testIngela Anderton Andin
The new_options_in_accept test is not working yet, however DTLS is still work in progress and we want to make a progress merge to avoid merge conflicts with other progress of the ssl application.
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-01-19ssl: Move PEM cache to a dedicated processIngela Anderton Andin
The PEM cache handling has proven to be too disruptive of the manager process.
2017-01-17ssl: Handle really big handshake packagesIngela Anderton Andin
If a handshake message is really big it could happen that the ssl process would hang due to failing of requesting more data from the socket. This has been fixed. Also added option to limit max handshake size. It has a default value that should be big enough to handle normal usage and small enough to mitigate DoS attacks.
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-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-06-09Add ssl:getstat/1 and ssl:getstat/2Loïc Hoguin
These functions call getstat on the underlying TCP socket. The only way to do this before now was to use a hack, either by looking inside the #sslsocket{} record directly, or by not using the SSL listen/accept functions and upgrading from a TCP socket that is kept around for the purpose of calling getstat later on.
2016-06-03ssl: Add option to phase out support for sslv2 client helloIngela Anderton Andin
ssl servers can recognize sslv2 client hellos to interop with clients that support higher version of SSL/TLS but also offers sslv2 Conflicts: lib/ssl/src/tls_connection.erl
2016-05-31ssl:recv timeout() can be 0Joe DeVivo
gen_tcp:recv allows this, and if you're doing something like Transport:recv(Socket, 0, 0), TCP will work and SSL will exit with function_clause There were other cases of this throughout the module. This PR cleans them all up.
2016-05-26ssl: Add BEAST mitigation selection optionKenneth Lakin
Some legacy TLS 1.0 software does not tolerate the 1/n-1 content split BEAST mitigation technique. This commit adds a beast_mitigation SSL option (defaulting to one_n_minus_one) to select or disable the BEAST mitigation technique. Valid option values are (one_n_minus_one | zero_n | disabled).
2016-05-12ssl: Refactor to make code easier to understandIngela Anderton Andin
2016-05-03ssl: Use gen_statem instead of gen_fsmIngela Anderton Andin
Also reduce timing issues in tests
2016-04-25ssl: Corrections to cipher suite handlingIngela Anderton Andin
It was not possible to mix ssl 3 and 4 tuple cipher suites in the ciphers option. Some ssl_cipher:suite/1 clauses wrongly returned 3-tuples that should have been 4 tuples Conflicts: lib/ssl/test/ssl_basic_SUITE.erl
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-25Merge branch 'legoscia/fix-ssl-example/PR-976/OTP-13363' into maintIngela Anderton Andin
* legoscia/fix-ssl-example/PR-976/OTP-13363: ssl: Modernize utility function Fix ssl example
2016-02-25Merge branch 'legoscia/critical-extension-verify-none' into maintHenrik Nord
* legoscia/critical-extension-verify-none: ssl: with verify_none, accept critical extensions OTP-13377
2016-02-23ssl: Modernize utility functionIngela Anderton Andin
Use application:ensure_all_started/2 instead of hard coding dependencies
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.
2016-02-17ssl: with verify_none, accept critical extensionsMagnus Henoch
When establishing a TLS connection with {verify, verify_none}, if the server has a certificate with a critical extension, for example a "Netscape Cert Type" extension, certificate verification would fail, which is surprising given that the name of the option suggests that no verification would be performed. With this change, certificate extensions marked as critical are ignored when using verify_none.
2015-12-07Merge branch 'rlipscombe/rl-ssl-options' into maintHenrik Nord
* rlipscombe/rl-ssl-options: Ensure single 'raw' option is handled correctly Pass 'raw' options through OTP-13166
2015-10-02Pass 'raw' options throughRoger Lipscombe
In Erlang R16B03-1, I've been passing raw options to ssl:listen as follows, and it's been working fine: % The constants are defined elsewhere. LOpts = [{raw, ?IPPROTO_TCP, ?TCP_MAXSEG, <<MSS:32/native>>} | ...], {ok, LSocket} = ssl:listen(0, LOpts) In Erlang 17.3, this fails with {option_not_a_key_value_tuple,{raw,6,2,<<64,2,0,0>>}} I originally reported this in http://erlang.org/pipermail/erlang-questions/2014-October/081226.html I need to pass this particular raw option to ssl:listen, because it needs to be applied when the socket is first opened -- between inet:open and prim_inet:listen -- it cannot be applied later by setopts. This means that it needs to be done by inet_tcp:listen/2 -- well, actually by inet:open/8, but... Otherwise it's racey -- a client could connect between prim_inet:listen and the setopts call. The MSS option is advertised in the SYN,ACK packet, and can't be changed later.
2015-09-16ssl: Better timeout gaurdsIngela Anderton Andin
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-09-08Accept 'ECPrivateKey' as a ssl key optionYuki Ito
2015-06-18Change license text to APLv2Bruce Yinhe
2015-06-10Merge branch 'ferd/deny-client-renegotiation'Henrik Nord
* ferd/deny-client-renegotiation: Add disable client-initiated renegotiation option Conflicts: lib/ssl/doc/src/ssl.xml lib/ssl/src/ssl.erl OTP-12815
2015-06-03Add disable client-initiated renegotiation optionFred Hebert
Client-initiated renegotiation is more costly for the server than the client, and this feature can be abused in denial of service attempts. Although the ssl application already takes counter-measure for these (via cooldown periods between renegotiations), it can be useful to disable the feature entirely. This patch adds the `{client_renegotiation, boolean()}' option to the server-side of the SSL application (defaulting to `true' to be compatible with the current behaviour). The option disables the ability to do any renegotiation at all in the protocol's state, reusing the existing denial code, but without opening the code path that sets up a timed message to eventually reopen it up.
2015-05-12ssl: Refactored and corrected sni_fun handlingIngela Anderton Andin
Dialyzer warned about the incorrect match of Packets. Code was refactored and the problem avoided in the process. Dialyzer warned that the empty tuple is not a function as the contract said it should be. Changed the handling of the sni_fun default value to be undefined and added it to the contract.
2015-05-12ssl: add option sni_funQijiang Fan
The newly added function sni_fun allows dynamic update of SSL options like keys and certificates depending on different SNI hostname, rather than a predefined rules of SSL options.
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: deny recursively defined sni_hostsQijiang Fan
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
2015-03-05Merge branch 'maint'Ingela Anderton Andin
Conflicts: lib/ssl/src/ssl_cipher.erl lib/ssl/test/ssl_basic_SUITE.erl