| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
* ingela/ssl/AEAD:
ssl, dtls: Refactor so that DTLS records are handled correctly together with AEAD handling
ssl, dtls: Correct integer type for sequence number
|
|
* ingela/ssl/test-data:
ssl: Rewrite test data generation
|
|
With the new help functions for creating test data we can simplify the
code. And sometimes corrections have been made so that the test actually
perform the test intended.
|
|
|
|
Removes spurious ">"
|
|
Enhance type-driven optimisation in beam_type.erl
|
|
Move travis dialyzer logic to script file
|
|
* lukas/erts/20_minor_fixes:
erts: Rebuild etc executables if config.h changes
erts: Fix new gcc warning in check io
kernel: Add mem check to prim_file:large_write tc
erts: Fix two compiler warnings on OS X
erts: Fix erts_debug:df function info output
erts: Get rid of some unused function warnings on os x
|
|
* lukas/erts/erlexec_docker_cpuset-cpus/OTP-14352:
erts: Fix erlexec to handle mismatch in sysconf and proc fs
|
|
This behaviour has been seen when using docker together with --cpuset-cpus.
|
|
|
|
|
|
|
|
|
|
* kill type information only for affected registers in get_map_elements
* bs_get_utf* will produce integers of unicode range
This optimises code created by Elixir compiler, where:
<<x::utf8,_::binary>> when x in 1..10
will compile the guard to
is_integer(X) andalso X >= 1 andalso X =< 10
This allows us to eliminate the is_integer check.
* bs_get_float will produce a float
* allow to carry type information over other bs instructions killing
only the affected registers
* kill only x registers after call_fun and apply instructions
|
|
HiPE: Fix --enable-native-libs --enable-m32-build
|
|
AGAIN
* sverker/remove-latin1-atom-encoding:
tools: Fix more assumptions in lcnt about external format
|
|
* bjorn/stdlib/erl_tar/OTP-14278:
erl_tar: Handle leading slashes and directory traversal attacks
Don't create absolute path names in tar files
|
|
Also tried to prepare for large creation.
|
|
Add re:version/0
OTP-14347
|
|
This fixes a mistake in 6d8c39229 where a few "enable_hipe=no" that
makes the build fail when building with both --enable-native-libs and
--enable-m32-build slipped through.
|
|
|
|
|
|
* hasse/stdlib/linter_check_dialyzer/OTP-14323:
stdlib: Add checks of the dialyzer attribute to the linter
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The same checks are also performed by the Dialyzer.
|
|
AEAD handling
|
|
|
|
* ingela/dtls/progress:
dtls: Correct cookie map name
dtls: Fix active once emulation for DTLS
|
|
|
|
|
|
* siri/make/include-path/ERL-395/OTP-14339:
[tools/make] Add current directory to include path
|
|
|
|
* sverker/remove-latin1-atom-encoding:
kernel: Fix erl_distribution_wb_SUITE:whitebox
kernel: Remove pg2_SUITE:compat
erts: Remove fun_r13_SUITE
stdlib: Remove test cases for R12 io protocol
kernel: Make DFLAG_UTF8_ATOMS mandatory
kernel: Rewrite distribution flag verification
tools: Update assumptions in lcnt about external atom format
stdlib: Tweak beam_lib_SUITE whitebox assumptions
orber: Remove hard dependency to external atom format
kernel: Try mend disk_log whitebox tests
erts: Mark latin1 atom encoding as deprecated
jinterface: Do not generate atoms on old latin1 external format
erl_interface: Do not generate atoms on old latin1 ext format
erts: Do not generate atoms on old latin1 external format
erts: Fix faulty ASSERT for failed dec_term
|
|
|
|
* ingela/openssl-version:
crypto: Update documentation to reflect new version policy
erts: Update configure check for OpenSSL
|
|
We should not assume that erl_tar will allow unpacking tar files
with absolute path names for archive members.
|
|
This is to ensure that files are recompiled if a .hrl file in the
current directory is changed.
|
|
* bjorn/compiler/unicode-atoms/OTP-14285:
Correct compile_SUITE:core_roundtrip/1
Atoms in Core Erlang must be encoded in UTF-8
|
|
|
|
Seems to solve some test case problems when heavily loaded
|
|
The test is supposed to compare the Core Erlang code that has been
printed and parsed back. It did compare and print any differences,
but it did not fail when there were differences.
Also fix problems with variable names and maps not comparing
equal when the inliner has been used.
|
