| Age | Commit message (Collapse) | Author |
|---|
|
* ingela/ssl/handshake-handling/ERL-968/OTP-15879:
ssl: Correct handshake handling
|
|
Solves ERL-968, a refactoring bug could cause part of a server key exchange message to
be appended, to an incorrectly duplicated, certificate handshake message. In the end
causing an ASN1 decoding error. That in turn did not end up the correct error handling branch.
|
|
Maybe we should only have specs for external APIs?!
This is a how to write spec problem that we have to address later.
|
|
Change-Id: I99cd0bebd80b3e55fd522457fa126e5bc198657b
Conflicts:
lib/ssl/src/ssl_handshake.erl
|
|
|
|
|
|
* peterdmv/ssl/fix-srp-encode-decode/ERL-790/OTP-15477:
ssl: Fix encoding/decoding of the SRP extension
Change-Id: Iee3276a60041a2c04c89385b2de2edb1cd81babd
|
|
The encoded value of the SRP extension length was bigger than the
actual length of the extension. This could cause interoperability
problems with third party SSL implementations.
This commit corrects the encoding and decoding of the SRP extension
length.
Change-Id: I78d118faab7f5d02b755a7d1e2e8561b86f5a15c
|
|
Use throw stratgy for erro handling in extension handling. Makes code consistent and easier to refactor.
Also fixes bug that an incorrect return value for gen_statem could be created when alert was a result
of handling renegotiation info extension.
|
|
|
|
If the peer sends an incomplete chain that we can reconstruct with
our known CA-certs it will be accepted.
We will assume that the peer honors the protocol and sends an orded
chain, however if validation fails we will try to order the chain in
case it was unorded. Will also handle that extraneous cert where present.
See Note form RFC 8446
Note: Prior to TLS 1.3, "certificate_list" ordering required each
certificate to certify the one immediately preceding it; however,
some implementations allowed some flexibility. Servers sometimes
send both a current and deprecated intermediate for transitional
purposes, and others are simply configured incorrectly, but these
cases can nonetheless be validated properly. For maximum
compatibility, all implementations SHOULD be prepared to handle
potentially extraneous certificates and arbitrary orderings from any
TLS version, with the exception of the end-entity certificate which
MUST be first.
|
|
Before only some PSK suites would be correctly negotiated and most PSK
ciphers suites would fail the connection.
PSK cipher suites are anonymous in the sense that they do not use
certificates except for rsa_psk.
|
|
|
|
The conversion code for different representations of cipher suites
is long an repetitive. We want to hide it in a module that does not
have other functions that we like to look at.
|
|
* maint-20:
Updated OTP version
Update release notes
Update version numbers
crypto: Fix crash in compute_key(ecdh, ...) on badarg
Relax add_table_copy restriction
Fixed #Ref ordering bug
Test #Ref ordering in lists and ets
Do NOT disc_load from ram_copies when master_node is set
ssl: Make sure that a correct cipher suite is selected
ssl: Correct handling of empty server SNI extension
|
|
* ingela/ssl/empty-sni/OTP-15168:
ssl: Correct handling of empty server SNI extension
|
|
|
|
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
|
|
|
|
|
|
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.
|
|
answer to a certificate request
Solves ERL-599
|
|
answer to a certificate request
Solves ERL-599
|
|
|
|
* ingela/ssl/no-sslv2-hello-support/OTP-14824:
ssl: Remove interoperability option v2_hello_compatible
|
|
* hasse/dialyzer/extra-range/OTP-14970:
ssl: Correct some specs
os_mon: Correct a spec
Fix broken spec in beam_asm
Dialyzer should not throw away spec information because of overspec
|
|
|
|
|
|
|
|
Anonymous cipher suites were broken altogether, and
there was an earlier issue where the server would send a signature
in the server key exchange if a certificate was configured, even
if an anonymous suite was actually negotiated.
Backport of PR-1729
|
|
|
|
completely deprecated operation with no effect.
|
|
|
|
|
|
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
|
|
Conflicts:
OTP_VERSION
|
|
* maint-20:
Updated OTP version
Update release notes
Update version numbers
public_key: verify ip (both v4 and v6)
public_key: Added IP4 address checks to hostname_verification tests
ssl: Fix test cases to work on all test platforms
public_key: Fix dialyzer spec
ssl: Sessions must be registered with SNI if exists
ssl: Extend hostname check to fallback to checking IP-address
public_key, ssl: Handles keys so that APIs are preserved correctly
ssl: Use ?FUNCTION_NAME
ssl: Prepare for release
ssl: Countermeasurements for Bleichenbacher attack
Conflicts:
lib/public_key/doc/src/public_key.xml
lib/public_key/test/public_key_SUITE.erl
lib/public_key/test/public_key_SUITE_data/pkix_verify_hostname_subjAltName_IP.pem
lib/public_key/test/public_key_SUITE_data/verify_hostname_ip.conf
lib/ssl/src/dtls_connection.erl
lib/ssl/src/ssl_connection.erl
lib/ssl/src/ssl_handshake.erl
|
|
|
|
Conflicts:
lib/ssl/src/dtls_connection.erl
lib/ssl/src/ssl_connection.erl
lib/ssl/src/ssl_handshake.erl
lib/ssl/src/tls_connection.erl
|
|
|
|
|
