| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
changed:
* initialize deocder state when needed
* remove retransmission indicator support
|
|
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
|
|
* henrik/update-copyrightyear:
update copyright-year
|
|
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.
|
|
|
|
|
|
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+.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
See RFC 6066 section 3
|
|
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.
|
|
|
|
Common functions will be located in ssl_handshake.erl while
specific functions will be located in tls_handshake.erl and dtls_handshake.erl
|
|
This code is to 99 % written by Andreas Schultz only some small changes
to start integrating with OTPs DTLS solution.
|
|
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
|
