aboutsummaryrefslogtreecommitdiffstats
path: root/lib/ssl/src/dtls_handshake.erl
AgeCommit message (Collapse)Author
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-30dtls: Implement DTLS cookie secret generationIngela Anderton Andin
2017-03-23dtls: Handle overlapping fragmentsIngela Anderton Andin
Fragment reassembling needs to handle that a smaller fragment then sent originally might overlap an earlier received fragment.
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 .
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-09-05dtls: fix encoding of client hello cookieAndreas Schultz
2016-09-05ssl: Refactor to use maps for the connection statesIngela Anderton Andin
2016-06-13dtls: handle Hello and HelloVerify's in dtls_handshakeAndreas Schultz
2016-06-13dtls: rework/simplify DTLS fragment decoderAndreas Schultz
changed: * initialize deocder state when needed * remove retransmission indicator support
2016-06-13dtls: rework handshake flight encodeingAndreas Schultz
The MSS might change between sending the a flight and possible resend. We therefore have to be able to fragment the records differently for resent. Encoding and fragmenting of handshake record therefor needs to be done independently. With this change the handshake is encoded to it's full length first, then queued to a flight. The fragmentation is handled during assembly of the flights datagram. Conflicts: lib/ssl/src/dtls_connection.erl
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
2015-06-18Change license text to APLv2Bruce Yinhe
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+.
2014-03-25ssl: Avoid dialyzer warnings in dtls codeIngela Anderton Andin
Even if DTLS is not finished, e.i. not runnable yet we want to phase in the code together with refactoring of TLS code, but without introducing warnings in the release.
2014-03-25ssl: Refactor and start implementing dtls_connection.erlIngela Anderton Andin
2013-12-02Merge branch 'maint'Ingela Anderton Andin
2013-12-02ssl, public_key: Dialyzer fixesIngela Anderton Andin
2013-12-02ssl: Refactor connection and handshake handlingIngela Anderton Andin
2013-12-02ssl: Refactor handshake and record handlingIngela Anderton Andin
2013-11-11Merge branch 'maint'Fredrik Gustafsson
2013-11-06Add SSL Server Name Indication (SNI) client supportJulien Barbot
See RFC 6066 section 3
2013-09-29ssl: fix initialization of DTLS fragment reassemblerAndreas Schultz
The DTLS fragment reassembler use a list [{Start, End}] for the fragments. When the first received fragment was not the starting fragment, that list got initialized with [{Start, Length}], causing the merge of following fragment to fail.
2013-09-10ssl: Refactor TLS/DTLS record handlingIngela Anderton Andin
2013-09-10ssl: Refactor to provide common handshake functions for TLS/DTLSIngela Anderton Andin
Common functions will be located in ssl_handshake.erl while specific functions will be located in tls_handshake.erl and dtls_handshake.erl
2013-09-10ssl: Add DTLS handshake primitivs.Andreas Schultz
This code is to 99 % written by Andreas Schultz only some small changes to start integrating with OTPs DTLS solution.
2013-06-04ssl: Structural perarparation to support DTLSIngela Anderton Andin
Also phase in tls module as main API instead of ssl. To make API clearer. As TLS is the new protocol name. Maybe keep some API functions in ssl