| Age | Commit message (Collapse) | Author |
|---|
|
Emulate active once in such a way that data recived by the TLS
connection process, but not fetch via active once option
by the user, can be delivered at next active once before final close.
|
|
|
|
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 .
|
|
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.
|
|
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.
|
|
* ingela/ssl/ECC-selection-fix/OTP-13918:
ssl: Correct ECC curve selection, the error could cause default to always be selected.
|
|
selected.
|
|
Several handshake events may be received in the same TLS packet. Then there
will be several events pushed to the gen_statems internal queue.
New events already in the socket-buffer should not be processed
if there are more unprocessed handshake events in next_event queue.
We need to handle this in the next_record/1 function.
|
|
|
|
|
|
|
|
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 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
|
|
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
|
|
|
|
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).
|
|
|
|
|
|
Also reduce timing issues in tests
|
|
* 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.
|
|
|
|
|
|
|
|
willing to support
Refactor highest_protocol_version so that code is symmetrical with lowest_protocol_version. For clarity and possible future use cases of highest_protocol_version/2
|
|
Add possibility to downgrade an SSL/TLS connection to a tcp connection,
and give back the socket control to a user process.
Add application setting to be able to change fatal alert shutdown
timeout, also shorten the default timeout. The fatal alert timeout is
the number of milliseconds between sending of a fatal alert and
closing the connection. Waiting a little while improves the
peers chances to properly receiving the alert so it may
shutdown gracefully.
|
|
|
|
* ferd/deny-client-renegotiation:
Add disable client-initiated renegotiation option
Conflicts:
lib/ssl/doc/src/ssl.xml
lib/ssl/src/ssl.erl
OTP-12815
|
|
Client-initiated renegotiation is more costly for the server than the
client, and this feature can be abused in denial of service attempts.
Although the ssl application already takes counter-measure for these
(via cooldown periods between renegotiations), it can be useful to
disable the feature entirely.
This patch adds the `{client_renegotiation, boolean()}' option to the
server-side of the SSL application (defaulting to `true' to be
compatible with the current behaviour).
The option disables the ability to do any renegotiation at all in the
protocol's state, reusing the existing denial code, but without opening
the code path that sets up a timed message to eventually reopen it up.
|
|
Dialyzer warned about the incorrect match of Packets. Code
was refactored and the problem avoided in the process.
Dialyzer warned that the empty tuple is not a function as the contract
said it should be. Changed the handling of the sni_fun default value to be
undefined and added it to the contract.
|
|
The newly added function sni_fun allows dynamic update of SSL options
like keys and certificates depending on different SNI hostname, rather
than a predefined rules of SSL options.
|
|
|
|
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+.
|
|
disable option
|
|
disable option
Conflicts:
lib/ssl/src/ssl_cipher.erl
lib/ssl/src/ssl_record.erl
lib/ssl/src/tls_record.erl
lib/ssl/test/ssl_cipher_SUITE.erl
|
|
|
|
|
|
crashes.
|
|
|
|
|
|
|
|
|
|
If a client sends some garbage in ssl record instead of
valid fragment, server crashes with function_clause while
receiving next record from client.
This patch makes server raise handshake failure instead of
crashing and exposing internal state to user code.
|
|
Negotiated version is now always passed to ssl_handshake:select_hashsign
because ssl_handshake:select_cert_hashsign has different rsa defaults on
tlsv1.2 and older versions.
|
|
Generalize last warning alert function clause
|
|
The server code erroneously took the list of curves supported by the
client from it's own hello extension, effectively breaking curve
selection all together.
Also the default fallback secp256k1 curve is not supported by
all clients. secp256r1 is recommended as part of the NIST Suite B
cryptographic suites. The chances are much better that all clients
support it, so use that as fallback.
|
