aboutsummaryrefslogtreecommitdiffstats
path: root/lib/ssl/src/dtls_connection.erl
AgeCommit message (Collapse)Author
2017-07-07ssl: Enhance error loggingIngela Anderton Andin
2017-06-14Merge remote-tracking branch 'ingela/ingela/dtls/client-hello-verify/ERL-434'Hans Nilsson
2017-06-13dtls: Make HelloVerifyRequest version adhere to RFCIngela Anderton Andin
ERL-434 RFC6347 says about hello_verify_request version field as follow https://tools.ietf.org/html/rfc6347#page-16 The server_version field has the same syntax as in TLS. However, in order to avoid the requirement to do version negotiation in the initial handshake, DTLS 1.2 server implementations SHOULD use DTLS version 1.0 regardless of the version of TLS that is expected to be negotiated. But current DTLS server responses DTLS1.2 instead of DTLS1.0.
2017-06-13ssl: Correct epoch handlingIngela Anderton Andin
Consideration of which Epoch a message belongs to is needed in the dtls_connection:next_record function too.
2017-06-07dtls: Fetch next DTLS record when dropping resent handshake dataIngela Anderton Andin
2017-06-07dtls: Use enter actionsIngela Anderton Andin
Using enter actions for retransmission timers makes the code easier to understand. Previously the retransmission timer was incorrectly started in the connection state. Using enter actions feels like a cleaner approach than bloating the state with more flags.
2017-05-23dtls: Check for retransmitted changes_cipher_spec messagesIngela Anderton Andin
Make sure to use current epoch as input to send_handshake_flight.
2017-05-23dtls: Ask for next DTLS record when disregarding future packetIngela Anderton Andin
2017-05-16Merge branch 'ingela/dtls/opts'Ingela Anderton Andin
* ingela/dtls/opts: ssl: Adopt setopts and getopts for DTLS
2017-05-16ssl: Adopt setopts and getopts for DTLSIngela Anderton Andin
2017-05-16ssl: Remove debug printoutIngela Anderton Andin
2017-05-16dtls: Implement replay protectionIngela Anderton Andin
See RFC 6347 section 3.3
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-04-13dtls: Correct cookie map nameIngela Anderton Andin
2017-04-13dtls: Fix active once emulation for DTLSIngela Anderton Andin
2017-03-30dtls: Implement DTLS cookie secret generationIngela 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: Erlang distribution over DTLS is not supportedIngela Anderton Andin
Erlang distribution requiers a reliable transport, which udp is not. Maybe could be interesting later when SCTP support is added to DTLS.
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: Make sure retransmission timers are runIngela Anderton Andin
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-07Update copyright-yearErlang/OTP
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-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 close/5Ingela Anderton Andin
2016-09-05dtls: Add renegotiate/2Ingela 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-05dtls: Add reinit_handshake_data/1 to dtlsIngela Anderton Andin
The callback is invoke before entering state 'connection'. It allows a connection module to remove data from the connection state that is no longer needed (e.g. handshake history).
2016-08-02Rewrite SSL for gen_statem M:callback_mode/0Raimo Niskanen
2016-06-13dtls: Avoid dialyzer errorsIngela Anderton Andin
Make real solution later. For now we want to move forward without dialyzer errors.
2016-06-13dtls: add implementation for msg sequenceAndreas Schultz
Conflicts: lib/ssl/src/dtls_connection.erl lib/ssl/src/ssl_record.erl
2016-06-13dtls: Remove TODOIngela Anderton Andin
2016-06-13dtls: add support first packet and HelloVerifyRequestAndreas Schultz
The actual user of this API is the UDP socket multiplexer which will be added later. Conflicts: lib/ssl/src/dtls_connection.erl
2016-06-13dtls: sync handle_info for connection close with TLSAndreas Schultz
2016-06-13dtls: sync handling of ClientHello with TLSAndreas Schultz
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-06-13dtls: implement next_tls_recordAndreas Schultz
Conflicts: lib/ssl/src/dtls_connection.erl
2016-06-13dtls: sync init and initial_state with tls_connectionAndreas Schultz
Sync initial_state overall functionality with TLS and add a few DTLS specific initalizers. Conflicts: lib/ssl/src/dtls_connection.erl
2016-06-13dtls: update start_fsm for new ssl_connection APIAndreas Schultz
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-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-03ssl: Adapt DTLS to gen_statemIngela Anderton Andin
DTLS is not in working mode yet, but the gen_statem rewrite should make completion easier.
2016-05-03ssl: Use gen_statem instead of gen_fsmIngela Anderton Andin
Also reduce timing issues in tests
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.
2015-12-03ssl: Measure elapsed time with erlang:monotonic_timeIngela Anderton Andin