| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
Stream ciphers are not valid fro DTLS
|
|
Conflicts:
lib/ssl/src/ssl_cipher.erl
lib/ssl/src/ssl_handshake.erl
|
|
This is a preparation for improvements to come in option handling and
support for TLS-1.3
|
|
RFC: ecdhe_psk cipher suites
OTP-14547
|
|
This is mainly fixing the test suites so that they test the intended cipher
suites, issue reported in ERL-460.
Also ssl_cipher:anonymous_suites was corrected for DTLS.
|
|
Add the GCM ciphers from draft-mattsson-tls-ecdhe-psk-aead and the
specification for the CCM cipher (but leave them commented out as
we don't support CCM yet).
|
|
|
|
|
|
AEAD handling
|
|
|
|
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.
|
|
Adapted from commit 675ee6860d2c273bcc6c6a0536634a107e2a3d9f.
Conflicts:
lib/ssl/src/ssl_cipher.erl
|
|
* ingela/ssl/cipher-type-spec:
ssl: Adjust cipher type to conform to implementation
|
|
|
|
* RoadRunnr/crypto/no-rc4/PR-1169/OTP-13896:
disable RC4 in SSL when crypto doesn't support it
Fix compilation when OpenSSL doesn't support RC4
Conflicts:
lib/crypto/c_src/crypto.c
|
|
Test suite did not take TLS-version in to account. Also
some anonymous suites where included incorrectly in some TLS versions.
|
|
|
|
There are a lot of cases where `ssl` application just returns unhelpful
`handshake failure` or `internal error`. This patch tries to provide
better diagnostics so operator can debug his SSL misconfiguration
without doing hardcore erlang debugging.
Here is an example escript that incorrectly uses server certificate as a
client one:
https://gist.github.com/binarin/35c34c2df7556bf04c8a878682ef3d67
With the patch it is properly reported as an error in "extended key
usage".
|
|
Correct conversion errors form commit d2381e1a8d7cd54f7dc0a5105d172460b005a8fb
|
|
It was not possible to mix ssl 3 and 4 tuple cipher suites in the
ciphers option.
Some ssl_cipher:suite/1 clauses wrongly returned 3-tuples that
should have been 4 tuples
Conflicts:
lib/ssl/test/ssl_basic_SUITE.erl
|
|
ssl already used crypto:strong_rand_bytes/1 for most operations as
its use cases are mostly cryptographical. Now crypto:strong_rand_bytes/1
will be used everywhere.
However crypto:rand_bytes/1 was used as fallback if
crypto:strong_rand_bytes/1 throws low_entropy, this
will no longer be the case. This is a potential incompatibility.
The fallback was introduced a long time ago for interoperability reasons.
Now days this should not be a problem, and if it is, the security
compromise is not acceptable anyway.
|
|
* 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.
|
|
|
|
|
|
Older SSL/TLS versions have cipher suites
that look like {key_exchange(), cipher(), MAC::hash()}
and the hash function used by the PRF (Pseudo Random function)
is implicit and always the same for that protocol version.
In TLS 1.2 a cipher suite is
{key_exchange(), cipher(), MAC::hash(), PRF::hash()}.
Internally a cipher suite is always a four tuple but
for backwards compatibility older cipher suites
will be presented as a three tuples, however new cipher suites
should be presented as four tuples.
|
|
Make sure that options only relevant for one role (client|server) is set
to undefined when the other role is invoked. As there are many options to
ssl, and many are optional, we choose to filter out all undefined options
to avoid overwhelming the user with not relevant information.
This way there is no need for any special handling of the role specific options
which is also nice.
|
|
DES is not considered secure.
Also correct 'Server Name Indication' support description.
|
|
|
|
|
|
TLS hash_sign algorithms may have proprietary values see
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
We should add callbacks to let applications handle them.
But for now we do not want to crash if they are present and
let other algorithms be negotiated.
|
|
Conflicts:
lib/ssl/src/ssl_cipher.erl
lib/ssl/test/ssl_basic_SUITE.erl
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
When selecting the available cipher suites for the server all cipher suites
for the highest supported SSL/TLS-version would be selected, and not
all supported for the negotiated SSL/TLS-version. This could lead
to that faulty clients could negotiate cipher suites that they
can not support. This change will enable the faulty client to negotiate
another cipher suite that it can support.
|
|
Conflicts:
lib/ssl/src/dtls_record.erl
|
|
|
|
|
