Age | Commit message (Collapse) | Author |
|
Extention handling need some fixes to work
correctly for ALPN and SSL-3.0 only client/servers
do not support extensions
|
|
Regroup testes after functionality making it easier to
test all variants (all protocols, all cert types etc).
Also extend OpenSSL interop
|
|
* peterdmv/ssl/fix-handshake-hello/ERL-975/OTP-15888:
ssl: Fix negative tests in ssl_basic_SUITE
ssl: Fix run_client_error/1 in ssl_test_lib
ssl: Fix ssl_handshake:extension_value/1
|
|
Handle new TLS 1.2/1.3 extensions.
|
|
* peterdmv/ssl/tls12-java11-interop/ERL-973/OTP-15887:
ssl: Add interop test
ssl: Improve handling of signature algorithms
|
|
TLS 1.2 ClientHello caused handshake failure in the TLS 1.2 server
if the signature_algorithms_cert extension contained legacy algorithms.
Update TLS 1.2 server to properly handle legacy signature algorithms
in the signature_algorithms_cert extension.
Update TLS 1.3 client so that it can send legacy algorithms in its
signature_algorithms_cert extension.
|
|
* 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/doc-types-and-specs/OTP-15746:
ssl: Add type specs for http_packet()
ssl: Fix type specs of ssl_internal.hrl
ssl: Fix type specs of internal handshake functions
ssl: Fix dialyzer warnings
eldap: Fix dialyzer warnings
ssl: Fix missing anchor warning
public_key: Accept digest types 'sha1' and 'sha'
inet: Document type inet:stat_option()
ssl: Changed function specs and ssl.xml
ssl: Update standards_compliance.xml
OTP-15775
OTP-15776
OTP-15777
Change-Id: Ibe8e8263d6557eaa40cc0681a7ce3fcb373a4120
|
|
Change-Id: I99cd0bebd80b3e55fd522457fa126e5bc198657b
|
|
|
|
Change-Id: I4764b5f2172f000d13c267e9002789fa6e09c58c
|
|
Implement validation of client certificates in state
'wait_cert'.
Implement state 'wait_cv'.
Clean up handler functions.
Change-Id: I5c410bf7afe34632f27fabcd61670764fedb105d
|
|
handshake_history() was specified as {[binary()], [binary[]]},
although its real type was {iodata(), iodata()}, dialyzer did
not give a warning until a new function matched out an element
of handshake_history and used it as input data for crypto:hash/2.
Change-Id: I60660e7296a52bf69bd7198a4cffee8338907726
|
|
Refactor state 'start' and handler functions.
Send 'hello_retry_request' if ClientHello does not contain
sufficient information.
Change-Id: I9fccb38aff5ba88bff75887261e8b1487bd64e17
|
|
Conflicts:
lib/ssl/doc/src/ssl.xml
lib/ssl/src/ssl.erl
|
|
|
|
Conflicts:
lib/ssl/doc/src/ssl.xml
lib/ssl/src/ssl.erl
lib/ssl/src/ssl_cipher_format.erl
lib/ssl/src/tls_handshake.erl
|
|
|
|
Change-Id: Ia18cda4e2b43dc863a24ac4838718adc788b08b1
|
|
Encode length of supported_versions in one octet instead of two.
Change-Id: If24b38f3d2a40f0aa7152bb05bc0392efca6454c
|
|
Change-Id: I5cc6b470ea19e32dd5516a86fe6750c5b51d5368
|
|
Change-Id: I465760b7001692367c68839219745e40abafdfa8
|
|
* maint:
ssl: Fix encoding/decoding of the SRP extension
Change-Id: I3b5887cf01b1a538c65d0c66da4d4ccf7793478d
|
|
* 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
|
|
Conflicts:
lib/ssl/src/ssl_handshake.erl
|
|
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.
|
|
This change adds the capability to the TLS 1.3 server to process
ClientHello messages and answer with ServerHello.
Change-Id: I13f6cfac932574300338e7301c6162252a591c70
|
|
Use signature schemes in the "signature_algs" extension when
creating TLS 1.3 ClientHello extensions.
Change-Id: I1402bec659c70352a4a2200146911fd4246d2fe2
|
|
Change-Id: Ie7409675dd7a35825f32822df259286bbb95fd62
|
|
|
|
|
|
- Updated message generators:
ClientHello, ServerHello and EncryptedExtensions
- Fixed encoding of the extensions 'signature_algorithms' and
'signature_algorithms_cert'
- Updated empty extension definitions
Change-Id: I9415e2d022744b9ed4667d20aee2553637ed49f8
|
|
Change-Id: I42d7779bb3558aa3a2bea5be065c559d01c0a32b
|
|
Change-Id: I4b382a7907247cc2099951fdefa40f1511b1123e
|
|
The option 'signature_algs_cert' is not set by default.
Change-Id: Ib87cedc5e48b3ac7a36a30bc7caa08d3193f12fa
|
|
Implement handling of the signature algorithms extension described by
RFC 8446. This commit updates the behavior of legacy TLS versions to
align them with RFC 8446 (TLS 1.3) and RFC 5246 (TLS 1.2).
- TLS 1.0/1.1 clients validate the client certificate against the
certificate_type field of the CertificateRequest message.
- TLS 1.2 client verifies the hash/signature algorithm pair of the
client certificate when processing a CertificateRequest. Old
behavior only checked the signature algorithms.
- TLS 1.2 server verifies that the server certificate is signed by
a hash/signature algorithm pair that appears in the
"singature_algorithms" or "signature_algorithms_cert" (RFC 8446)
extensions of the ClientHello.
Change-Id: I3e0a0d7408984f5e5b1233968934fe34d64eb2b7
|
|
|
|
As TLS 1.3 introduces more extensions in other places than in hello messages
we like to have generalize extension handling encode/decode with some
hello wrappers.
Also extend property tests of handshake encod/decode
|
|
|
|
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.
|
|
Change-Id: I8a5c11b3503b44cfc6cbd6e4fd8ff3005a8669dd
|
|
* maint:
ssl: Fix dialyzer errors detected when crypto.erl is typed
|