| Age | Commit message (Collapse) | Author |
|---|
|
From RFC 6347:
4.1.2.7. Handling Invalid Records
Unlike TLS, DTLS is resilient in the face of invalid records (e.g.,
invalid formatting, length, MAC, etc.). In general, invalid
records SHOULD be silently discarded, thus preserving the
association; however, an error MAY be logged for diagnostic
purposes. Implementations which choose to generate an alert
instead, MUST generate fatal level alerts to avoid attacks where
the attacker repeatedly probes the implementation to see how it
responds to various types of error. Note that if DTLS is run over
UDP, then any implementation which does this will be extremely
susceptible to denial-of-service (DoS) attacks because UDP forgery
is so easy. Thus, this practice is NOT RECOMMENDED for such
transports.
|
|
|
|
|
|
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.
|
|
Consideration of which Epoch a message belongs to is needed in the
dtls_connection:next_record function too.
|
|
|
|
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.
|
|
Make sure to use current epoch as input to send_handshake_flight.
|
|
|
|
* ingela/dtls/opts:
ssl: Adopt setopts and getopts for DTLS
|
|
|
|
|
|
See RFC 6347 section 3.3
|
|
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
Erlang distribution requiers a reliable transport, which udp is not.
Maybe could be interesting later when SCTP support is added to DTLS.
|
|
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.
|
|
|
|
DTLS does not support stream ciphers and needs diffrent
handling of the "#ssl_socket{}" handle .
|
|
|
|
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.
|
|
selected.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
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).
|
|
|
|
Make real solution later. For now we want to move forward without dialyzer
errors.
|
|
Conflicts:
lib/ssl/src/dtls_connection.erl
lib/ssl/src/ssl_record.erl
|
|
|
|
The actual user of this API is the UDP socket multiplexer which will
be added later.
Conflicts:
lib/ssl/src/dtls_connection.erl
|
|
|
|
|
|
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
|
|
Conflicts:
lib/ssl/src/dtls_connection.erl
|
|
Sync initial_state overall functionality with TLS and
add a few DTLS specific initalizers.
Conflicts:
lib/ssl/src/dtls_connection.erl
|
|
|
|
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
|
|
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).
|
|
DTLS is not in working mode yet, but the gen_statem rewrite should make
completion easier.
|
|
Also reduce timing issues in tests
|
|
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.
|
