Age | Commit message (Collapse) | Author |
|
- Add function for special handling of default values of
"signature_algs" in TLS 1.3.
This change adds default values for "signature_algs" even for
TLS 1.3 clients as they must send the "signature_algs" extension
when a server authenticates itself via a certificate.
- Use "signature schemes" as default instead of the old
hash-signature algorithms tuple when using TLS 1.3.
Change-Id: I296593b16610fd7a18a4ae3f3bac63c2fad06fbd
|
|
- Fix handling of hello versions. TLS 1.3 ClientHello will use
TLS 1.3 encoding.
- Fix encoding/decoding of TLS records when record protection
has not yet been engaged (NULL cipher).
Change-Id: I7511d1a7751f1ec8c2f2f2fb3d21ddf80a3f428b
|
|
Removed strongest Diffie-Hellman groups from defaults (ffdhe3072,
ffdhe4096, ffdhe6144, ffdhe8192) in order to reduce the time spent
with calculating the keys for the key_share extension.
Change-Id: I1cc1914ea4c5093f694989b0153c1bd1c8840eef
|
|
|
|
Change-Id: I42d7779bb3558aa3a2bea5be065c559d01c0a32b
|
|
Change-Id: I4b382a7907247cc2099951fdefa40f1511b1123e
|
|
Implementations of TLS 1.3 which choose to support prior versions of
TLS SHOULD support TLS 1.2. That is, a TLS 1.3 ClientHello shall
advertise support for TLS 1.2 ciphers in order to be able to connect
to TLS 1.2 servers.
This commit changes the list of the advertised cipher suites to
include old TLS 1.2 ciphers.
Change-Id: Iaece3ac4b66a59dfbe97068b682d6010d74522b8
|
|
Change-Id: I8a5c11b3503b44cfc6cbd6e4fd8ff3005a8669dd
|
|
This commit filters out cipher suites not to be used in TLS-1.3
We still need to add new cipher suites for TLS-1.3 and possible
add new information to the suite data structure.
|
|
Conflicts:
lib/ssl/src/tls_v1.erl
|
|
|
|
- Add 'tlsv1.3' to the available versions. It can be used to
trigger experimental behavior while implementing TLS 1.3.
- Add dummy clauses for handling version {3,4} of TLS.
- Update ssl_logger to handle unknown versions of TLS.
Change-Id: I564ffa47dca18b59f0dc16c9809dfd7adaf2d333
|
|
|
|
* ingela/ssl/no-chacha-default-for-now/ERL-538/OTP-14882:
ssl: Remove chacha ciphers form default for now
|
|
We have discovered interoperability problems, ERL-538, that we
believe needs to be solved in crypto.
|
|
|
|
|
|
|
|
* ingela/ssl/cacha-default/OTP-14382:
ssl: Cacha is currently not tested enough to be most prefered.
|
|
|
|
|
|
|
|
AES256 was preferred over 3DES already, so this only makes sure AES128
is preferred over 3DES also. This changes the default but probably
nobody will notice as a better algorithm will be chosen anyhow.
|
|
|
|
As per RFC 4492 Sec 5.1, the preferred order of selection of named
curves is based on client preferences.
Currently, the SSL application only picks entries according to the
absolute order of entries as tracked in a hardcoded list in code.
This patch changes things so that the client-specified order is
preferred. It also allows a mode where the server can be configured to
override the client's preferred order with its own, although the chosen
ECC must still be within both lists.
The configuration is done through the following options:
- `eccs`, shared by clients and servers alike, allows the specification
of the supported named curves, in their preferred order, and may
eventually support more values for explicit primes and so on.
- `honor_ecc_order`, a server-only option, is similar to
`honor_cipher_order` and will, by default let the server pick the
client-preferred ECC, and otherwise pick the server-preferred one.
The default value for `eccs` is the same as before, although the
server-chosen ECC now defaults to the client rather than previous
choice.
A function `ssl:eccs()` has been added that returns the highest
supported ECCs for the library.
|
|
* 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.
|
|
|
|
DES is not considered secure.
Also correct 'Server Name Indication' support description.
|
|
|
|
|
|
|
|
|
|
algorithms
With the addition of more ciphers that are not supported in all
configurations, using a manually prefiltered cipher list (e.g. EC vs.
non-EC ciphers) becomes to complex. Replace the manual split with
ssl_cipher:filter_suites/1 in all places.
Conflicts:
lib/ssl/src/ssl.erl
lib/ssl/src/tls_v1.erl
|
|
Conflicts:
lib/ssl/src/dtls_record.erl
|
|
crashing.
When TLS client sends Supported Elliptic Curves Client Hello Extension
the server shall select a curve supported by both sides or refuse to
negotiate the use of an ECC cipher suite.
|
|
Newer OpenSSL versions allow to selectively disable GF2m elliptic curves.
Selectively enable GF2m curves is support for them is available.
|
|
|
|
Also refactor so that TLS and DTLS can have common functions when possible.
|