Age | Commit message (Collapse) | Author |
|
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
|
|
* origin/raimo/ssl-dist-bench/OTP-14657:
Write SSL distribution benchmarks
Polish SSL distribution
Handle whitebox test message
Correct distribution doc
Use SNI when connecting
Use -ssl_dist_optfile options
Read in -ssl_dist_optfile to ETS
Facilitate test certs with common root
Stop checking DNS name for SNI
|
|
|
|
|
|
|
|
* ingela/ssl/timing:
ssl: Align timing just in case
|
|
Conflicts:
lib/ssl/src/ssl_connection.erl
|
|
|
|
|
|
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
|
|
'ingela/maint-20/ssl/extend-hostname-check/OTP-14632/OTP-14655/OTP-14766' into maint-20
* ingela/maint-20/ssl/extend-hostname-check/OTP-14632/OTP-14655/OTP-14766:
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
|
|
|
|
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.
|
|
Use ?FUNCTION_NAME macro to enhance code as we will not back-port this
version of the ssl application to versions pre OTP 19.
|
|
|
|
|
|
* ingela/ssl/extend-hostname-check/OTP-14632/OTP-14655:
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
|
|
Conflicts:
lib/ssl/src/ssl_connection.erl
|
|
Use ?FUNCTION_NAME macro to enhance code as we will not back-port this
version of the ssl application to versions pre OTP 19.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
It is desirable to be as specific as possible in the info message, so
there can be no mistake if the alert is form the peer or generated by
us. This use to be an error message, but it is better to make it an
info message as sending an ALERT ending the connection is an expected
behaviour.
|
|
|
|
Only DTLS specific code deals with DTLS version, when common code
is used the DTLS version should be converted to the corresponding TLS version.
|
|
RFC: ecdhe_psk cipher suites
OTP-14547
|
|
* maint:
sys_core_fold: Fix unsafe optimization of non-variable apply
Correct type specification in ssl:prf/5
|
|
Correct type specification in ssl:prf/5
|
|
Fix a proliferated typo in ssl
|
|
|
|
|
|
whatever the SSL options say, when we negotiated a anonymous,
PSK or SRP cipher suites, client certificates and certificate
requests are not permitted.
|
|
Current implementation expects Seed to be a list.
Correct type specification to match.
|
|
|
|
|
|
Conflicts:
OTP_VERSION
lib/inets/vsn.mk
lib/ssl/vsn.mk
|
|
|
|
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.
|
|
Add session_id and remove undocumented ssl:session_info/1
Add client_random, server_random and master_secret, they will not be included
in ssl:connection_information/1 as they may affect the connections security if
used recklessly.
|