Age | Commit message (Collapse) | Author |
|
|
|
|
|
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
|
|
|
|
* 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
|
|
|
|
|
|
If no SNI is available and the hostname is an IP-address also check
for IP-address match. This check is not as good as a DNS hostname check
and certificates using IP-address are not recommended.
|
|
|
|
|
|
If no SNI is available and the hostname is an IP-address also check
for IP-address match. This check is not as good as a DNS hostname check
and certificates using IP-address are not recommended.
|
|
|
|
|
|
state can not be determined
|
|
|
|
When the server_name_indication is sent automatize the
clients check of that the hostname is present in the
servers certificate. Currently server_name_indication shall
be on the dns_id format. If server_name_indication is disabled
it is up to the user to do its own check in the verify_fun.
|
|
|
|
Note this is a change form how it works for earlier versions that will
send the first hello message on the lowest supported version.
From RFC 5246
Appendix E. Backward Compatibility
E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0
Since there are various versions of TLS (1.0, 1.1, 1.2, and any
future versions) and SSL (2.0 and 3.0), means are needed to negotiate
the specific protocol version to use. The TLS protocol provides a
built-in mechanism for version negotiation so as not to bother other
protocol components with the complexities of version selection.
TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
compatible ClientHello messages; thus, supporting all of them is
relatively easy. Similarly, servers can easily handle clients trying
to use future versions of TLS as long as the ClientHello format
remains compatible, and the client supports the highest protocol
version available in the server.
A TLS 1.2 client who wishes to negotiate with such older servers will
send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
ClientHello.client_version. If the server does not support this
version, it will respond with a ServerHello containing an older
version number. If the client agrees to use this version, the
negotiation will proceed as appropriate for the negotiated protocol.
If the version chosen by the server is not supported by the client
(or not acceptable), the client MUST send a "protocol_version" alert
message and close the connection.
If a TLS server receives a ClientHello containing a version number
greater than the highest version supported by the server, it MUST
reply according to the highest version supported by the server.
A TLS server can also receive a ClientHello containing a version
number smaller than the highest supported version. If the server
wishes to negotiate with old clients, it will proceed as appropriate
for the highest version supported by the server that is not greater
than ClientHello.client_version. For example, if the server supports
TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
proceed with a TLS 1.0 ServerHello. If server supports (or is
willing to use) only versions greater than client_version, it MUST
send a "protocol_version" alert message and close the connection.
Whenever a client already knows the highest protocol version known to
a server (for example, when resuming a session), it SHOULD initiate
the connection in that native protocol.
Note: some server implementations are known to implement version
negotiation incorrectly. For example, there are buggy TLS 1.0
servers that simply close the connection when the client offers a
version newer than TLS 1.0. Also, it is known that some servers will
refuse the connection if any TLS extensions are included in
ClientHello. Interoperability with such buggy servers is a complex
topic beyond the scope of this document, and may require multiple
connection attempts by the client.
Earlier versions of the TLS specification were not fully clear on
what the record layer version number (TLSPlaintext.version) should
contain when sending ClientHello (i.e., before it is known which
version of the protocol will be employed). Thus, TLS servers
compliant with this specification MUST accept any value {03,XX} as
the record layer version number for ClientHello.
TLS clients that wish to negotiate with older servers MAY send any
value {03,XX} as the record layer version number. Typical values
would be {03,00}, the lowest version number supported by the client,
and the value of ClientHello.client_version. No single value will
guarantee interoperability with all old servers, but this is a
complex topic beyond the scope of this document.
|
|
for the CRL
|
|
|
|
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.
|
|
* ferd/bypass-pem-cache/PR-1143/OTP-13883:
ssl: Add documentation of bypass_pem_cache application environment configuration
ssl: Add new benchmarks to skip file for normal testing
Adding PEM cache bypass benchmark entries
Fixing CRL searching in cache bypass
Add option to bypass SSL PEM cache
|
|
|
|
ssl_handshake:update_handshake_history
This proably a much bigger problem for DTLS than TLS, but should be
disabled for both unless explicitly configured for TLS.
|
|
Conflicts:
lib/ssl/src/ssl_handshake.erl
|
|
The current SSL implementation has a PEM cache running through the ssl
manager process, whose primary role is caching CA chains from files on
disk. This is intended as a way to save on disk operation when the
requested certificates are often the same, and those cache values are
both time-bound and reference-counted. The code path also includes
caching the Erlang-formatted certificate as decoded by the public_key
application
The same code path is used for DER-encoded certificates, which are
passed in memory and do not require file access. These certificates are
cached, but not reference-counted and also not shared across
connections.
For heavy usage of DER-encoded certificates, the PEM cache becomes a
central bottleneck for a server, forcing the decoding of every one of
them individually through a single critical process. It is also not
clear if the cache remains useful for disk certificates in all cases.
This commit adds a configuration variable for the ssl application
(bypass_pem_cache = true | false) which allows to open files and decode
certificates in the calling connection process rather than the manager.
When this action takes place, the operations to cache and return data
are replaced to strictly return data.
To provide a transparent behaviour, the 'CacheDbRef' used to keep track
of the certificates in the cache is replaced by the certificates itself,
and all further lookup functions or folds can be done locally.
This has proven under benchmark to more than triple the performance of
the SSL application under load (once the session cache had also been
disabled).
|
|
|
|
Conflicts:
OTP_VERSION
erts/doc/src/notes.xml
erts/vsn.mk
lib/common_test/doc/src/notes.xml
lib/common_test/vsn.mk
lib/ssl/doc/src/notes.xml
lib/ssl/src/ssl.appup.src
lib/ssl/vsn.mk
lib/stdlib/test/ets_SUITE.erl
otp_versions.table
|
|
Use the list of versions that the server allows and among those choose
the highest version that is not higher than the client's version.
Note that this chosen version might be lower than the client's version,
but is used to improve interoperability.
Patch suggested by Dimitry Borisov refering to RFC 5246 appendix E.1.
|
|
In TLS-1.2 the selection of the servers algorithms and the the
possible selection of algorithms for the client certificate verify
message have different requirements.
|