| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* ingela/maint/ssl/ECC/ERIERL-210/OTP-15203:
ssl: Make sure that a correct cipher suite is selected
|
|
The keyexchange ECDHE-RSA requires an RSA-keyed server cert
(corresponding for ECDHE-ECDSA), the code did not assert this
resulting in that a incorrect cipher suite could be selected.
Alas test code was also wrong hiding the error.
|
|
|
|
|
|
|
|
The keyexchange ECDHE-RSA requires an RSA-keyed server cert
(corresponding for ECDHE-ECDSA), the code did not assert this
resulting in that a incorrect cipher suite could be selected.
Alas test code was also wrong hiding the error.
|
|
Transport accepted sockets that are in the error state, was not closed
properly.
|
|
|
|
|
|
The keyexchange ECDHE-RSA requires an RSA-keyed server cert
(corresponding for ECDHE-ECDSA), the code did not assert this
resulting in that a incorrect cipher suite could be selected.
Alas test code was also wrong hiding the error.
|
|
I did not find any legitimate use of "can not", however skipped
changing e.g RFCs archived in the source tree.
|
|
* peterdmv/ssl/version_downgrade_protection/OTP-15189:
ssl: Implement downgrade protection mechanism (TLS 1.3)
Change-Id: I29a281c1278509608fdea9b0346ad91c62f886a8
|
|
* maint:
Fix typo in xmerl_scan:string/1
Updated OTP version
Prepare release
ssl: Engine key trumps certfile option
inets: Prepare for release
inets: Improve error handling
|
|
* maint-20:
Updated OTP version
Prepare release
ssl: Engine key trumps certfile option
inets: Prepare for release
inets: Improve error handling
|
|
* peterdmv/ssl/version_extension_updates/OTP-15059:
ssl: Fix handling of TLS record versions
ssl: Update hello state (TLS 1.3)
ssl: Implement 'supported_versions' extension
ssl: Sort supported versions in handle_options
ssl: Add experimental version 'tlsv1.3'
Change-Id: I071d24242103cc066c5ee8154effc5ee01b04703
|
|
|
|
* ingela/ssl/engine-vs-certfile/ERLERL-211/OTP-15193:
ssl: Engine key trumps certfile option
|
|
If negotiating TLS 1.2, TLS 1.3 servers MUST set the last eight bytes
of their Random value to the bytes:
44 4F 57 4E 47 52 44 01
If negotiating TLS 1.1 or below, TLS 1.3 servers MUST and TLS 1.2
servers SHOULD set the last eight bytes of their Random value to the
bytes:
44 4F 57 4E 47 52 44 00
Change-Id: If35112f63f42a9af351f4ca9b1846fd3f5b08167
|
|
- Introduce new macro ALL_TLS_RECORD_VERSIONS to decouple
ALL_AVAILABLE_VERSIONS from the list of valid TLS record
versions. It consists of versions allowed in
TLSCiphertext.version (TLS 1.2 and prior) and
TLSCiphertext.legacy_record_version (TLS 1.3).
- TLS 1.3 sets TLSCiphertext.legacy_record_version to 0x0303
for all records generated other than an initial ClientHello,
where it MAY also be 0x0301.
- TLSPlaintext.legacy_record_version is ignored.
Change-Id: Iabb1a954ab21f8be012e6460ae99ab533e31e123
|
|
Update hello state to handle the "supported_versions" extension
defined by TLS 1.3:
- If "supported_versions" is present in ServerHello, the client
will aboirt the handshake with an "illegal_parameter" alert.
- If "supported_versions" is present in ClientHello, the server
will select a version from "supported_versions" and ignore
ClientHello.legacy_version. If it only supports versions
greater than "supported_versions", the server aborts the
handshake with a "protocol_version" alert.
- If "supported_versions" is absent in ClientHello, the server
negotiates the minimum of ClientHello.legacy_version and
TLS 1.2. If it only supports version greater than
ClientHello.legacy_version, the server aborts the handshake
with a "protocol_version" alert.
Change-Id: I16eef15d77bf21209c6cc103546ddddca518483b
|
|
Change-Id: I8bb015e97ab4c317ef380123cf94350ed509c36f
|
|
Sort supported versions (highest first) in handle options to
reflect the order expected by TLS 1.3.
Change-Id: I06bb43ac81eeaca681c122d815a024c8444e3726
|
|
- 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
|
|
|
|
|
|
|
|
|
|
|
|
IngelaAndin/ingela/ssl/unexpected-call/ERL-664/OTP-15174
ssl: Improve error handling
|
|
|
|
|
|
Conflicts:
lib/ssl/test/ssl_basic_SUITE.erl
|
|
|
|
Conflicts:
lib/ssl/test/ssl_ECC_SUITE.erl
|
|
Failing to recognize psk as an anonymous key exchange would fail the connection
when trying to decode an undefined certificate.
|
|
|
|
The Key Usage extension is described in section 4.2.1.3 of X.509, with the following possible flags:
KeyUsage ::= BIT STRING {
digitalSignature (0),
nonRepudiation (1), -- recent editions of X.509 have
-- renamed this bit to contentCommitment
keyEncipherment (2),
dataEncipherment (3),
keyAgreement (4),
keyCertSign (5),
cRLSign (6),
encipherOnly (7),
decipherOnly (8) }
In SSL/TLS, when the server certificate contains a RSA key, then:
either a DHE or ECDHE cipher suite is used, in which case the RSA key
is used for a signature (see section 7.4.3 of RFC 5246: the "Server
Key Exchange" message); this exercises the digitalSignature key usage;
or "plain RSA" is used, with a random value (the 48-byte pre-master
secret) being encrypted by the client with the server's public key
(see section 7.4.7.1 of RFC 5246); this is right in the definition of
the keyEncipherment key usage flag.
dataEncipherment does not apply, because what is encrypted is not
directly meaningful data, but a value which is mostly generated
randomly and used to derive symmetric keys. keyAgreement does not
apply either, because that one is for key agreement algorithms which
are not a case of asymmetric encryption (e.g. Diffie-Hellman). The
keyAgreement usage flag would appear in a certificate which contains a
DH key, not a RSA key. nonRepudiation is not used, because whatever is
signed as part of a SSL/TLS key exchange cannot be used as proof for a
third party (there is nothing in a SSL/TLS tunnel that the client
could record and then use to convince a judge when tring to sue the
server itself; the data which is exchanged within the tunnel is not
signed by the server).
When a ECDSA key is used then "keyAgreement" flag is needed for beeing
ECDH "capable" (as opposed to ephemeral ECDHE)
|
|
|
|
ECDH suite handling did not use the EC parameters form the certs
as expected.
Conflicts:
lib/ssl/src/ssl_cipher.erl
|
|
Fix test case code to use keyAgreement for ECDH_ECDSA
Conflicts:
lib/ssl/test/ssl_ECC.erl
lib/ssl/test/ssl_ECC_openssl_SUITE.erl
lib/ssl/test/ssl_to_openssl_SUITE.erl
|
|
When test handling was corrected it was obvious that DTLS ECC handling
was not compleated.
Conflicts:
lib/ssl/src/ssl.erl
lib/ssl/test/Makefile
lib/ssl/test/ssl_ECC.erl
lib/ssl/test/ssl_ECC_SUITE.erl
lib/ssl/test/ssl_ECC_openssl_SUITE.erl
|
|
When doing ssl:controlling_process on a ssl socket that has not
performed the TLS/DTLS handshake that call will succeed even though
the documentation stated otherwise. However if some other ssl option
was incorrect the call would hang. Now {error, closed} will be
returned in the latter case, which is logical independent on if it
should succeed or not in the former case. The former case will continue
to succeed, as it is not dependent of the TLS/DTLS connection being
established, and the documentation is altered slightly to not
explicitly disallow it. If the TLS/DTLS connection later fails and
the socket mode is active, the new controlling process will be
notified as expected.
|
|
|
|
IngelaAndin/ingela/ssl/no-ca-sign-restriction-TLS-1.2/ERL-381/OTP-15173
Ingela/ssl/no ca sign restriction tls 1.2/erl 381/otp 15173
|
|
|
|
|
|
|
|
|
|
|
