aboutsummaryrefslogtreecommitdiffstats
path: root/lib/ssl/src/ssl.erl
AgeCommit message (Collapse)Author
2018-04-24ssl: Add new API functionsIngela Anderton Andin
2018-04-24ssl: Prepare to replace ssl:ssl_accept with ssl:handshakeIngela Anderton Andin
2018-03-27ssl: Correct ECC suite and DTLS ECC handlingIngela Anderton Andin
When test handling was corrected it was obvious that DTLS ECC handling was not compleated.
2018-03-09ssl: Remove interoperability option v2_hello_compatibleIngela Anderton Andin
2018-03-08ssl: Increase security with safer defaultIngela Anderton Andin
The interoperability option to fallback to insecure renegotiation now has to be explicitly turned on.
2018-02-07Merge branch 'maint'Ingela Anderton Andin
Conflicts: lib/ssl/doc/src/ssl.xml lib/ssl/src/ssl.erl lib/ssl/src/ssl_cipher.erl lib/ssl/test/ssl_basic_SUITE.erl lib/ssl/test/ssl_test_lib.erl
2018-02-07ssl: Make sure anonymous suites are handled separatelyIngela Anderton Andin
Preferably customized cipher suites will be based on the default value. But all may be used as base and hence it will be good to handle anonymous suites separately as they are intended for testing purposes.
2018-02-05ssl: Uses aead as mac value in AEAD cipher suitesIngela Anderton Andin
Authenticated encryption (AE) and authenticated encryption with associated data (AEAD, variant of AE) is a form of encryption which simultaneously provides confidentiality, integrity, and authenticity assurances on the data. This is more logical value then null that was used, this happened to work as the AEAD property was derived form other data, but it is confusing!
2018-02-05ssl: Add new API functions for cipher suite handlingIngela Anderton Andin
2018-01-17dtls: Add DTLS handling to utility functionsIngela Anderton Andin
2017-12-05Merge branch 'ingela/ssl/cipher-suites/OTP-14749' into maintIngela Anderton Andin
* ingela/ssl/cipher-suites/OTP-14749: ssl: Use maps for cipher suites internally
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-04Stop checking DNS name for SNIRaimo Niskanen
2017-11-08ssl: Add private key configuration for crypto engineIngela Anderton Andin
2017-10-18Merge branch 'ingela/dtls/no-packet-upd/OTP-14664' into maintIngela Anderton Andin
* ingela/dtls/no-packet-upd/OTP-14664: ssl: No support for packet option over unreliable transport
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-17ssl: No support for packet option over unreliable transportIngela 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-10-05ssl: Use new string functionsIngela Anderton Andin
The functions are not performance critical. Will be used when errors occurs, CRL data base is managed or legacy OpenSSL names are used for ciphers.
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