| Age | Commit message (Collapse) | Author |
|---|
|
Make sure to use current epoch as input to send_handshake_flight.
|
|
|
|
An UDP socket does note have a connection and should
not recive econnreset, however this happens on on some windows versions.
Just ignoring it appears to make things work as expected!
|
|
|
|
* ingela/dtls/opts:
ssl: Adopt setopts and getopts for DTLS
|
|
|
|
|
|
* ingela/dtls/replay-protect/OTP-14077:
dtls: Implement replay protection
|
|
See RFC 6347 section 3.3
|
|
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.
|
|
|
|
|
|
* ingela/ssl/cacha-default/OTP-14382:
ssl: Cacha is currently not tested enough to be most prefered.
|
|
|
|
|
|
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.
|
|
AEAD handling
|
|
|
|
|
|
|
|
* ingela/ssl/dtls-cookie/OTP-14076:
dtls: Implement DTLS cookie secret generation
|
|
Conflicts:
OTP_VERSION
erts/vsn.mk
lib/crypto/c_src/crypto.c
lib/crypto/src/crypto.erl
lib/ssh/src/ssh.erl
|
|
|
|
|
|
Emulate active once in such a way that data recived by the TLS
connection process, but not fetch via active once option
by the user, can be delivered at next active once before final close.
|
|
* ingela/ssl/dtls-frag:
dtls: Handle overlapping fragments
|
|
Fragment reassembling needs to handle that a smaller
fragment then sent originally might overlap an earlier
received fragment.
|
|
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.
|
|
|
|
|
|
|
|
|
|
* ingela/ssl/next-maint-version:
ssl: Version update
|
|
'dtlsv1.2' should not be included in MIN_DATAGRAM_SUPPORTED_VERSIONS
as this is the default when crypto does not have sufficient support for
'tlsv1.2' and 'dtlsv1.2'
|
|
The new_options_in_accept test is not working yet, however DTLS is still
work in progress and we want to make a progress merge to avoid merge conflicts
with other progress of the ssl application.
|
|
Erlang distribution requiers a reliable transport, which udp is not.
Maybe could be interesting later when SCTP support is added to DTLS.
|
|
Change retransmissions timers to use gen_statem state timeouts. We do
not need a retransmission timer in the state connection as data traffic in
DTLS over UDP is not retransmitted. If the last flight before
transitioning into connection is lost, it will be resent when the peer
resends its last flight. This will also make hibernation testing more
straight forward.
We need more adjustments later to handle a reliable DTLS transport
such as SCTP.
|
|
|
|
DTLS does not support stream ciphers and needs diffrent
handling of the "#ssl_socket{}" handle .
|
|
|
|
AES256 was preferred over 3DES already, so this only makes sure AES128
is preferred over 3DES also. This changes the default but probably
nobody will notice as a better algorithm will be chosen anyhow.
|
|
* fix-source-typos: (25 commits)
Fixed typos in system/doc
Fixed typos in lib/xmerl
Fixed typos in lib/wx
Fixed typos in lib/stdlib
Fixed typos in lib/snmp
Fixed typos in lib/ssl
Fixed typos in lib/ssh
Fixed typos in PKCS-8.asn1 file
Fixed typos in lib/parsetools
Fixed typos in lib/orber
Fixed typos in lib/mnesia
Fixed typos in lib/megaco
Fixed typos in lib/kernel
Fixed typos in lib/jinterface
Fixed typos in lib/inets
Fixed typos in lib/hipe
Fixed typos in lib/eunit
Fixed typos in lib/erl_interface
Fixed typos in lib/eldap
Fixed typos in lib/edoc
...
|
|
|
|
Valid SSL 3.0 or TLS hellos might accidentally match SSL 2.0 format
(and sometimes the other way around before inspecting data)
so we need to match SSL 3.0 and TLS first and only match SSL 2.0
hellos when flag to support it is set.
|
|
Use map instead of large tuple, which was not an option when the code
was written originally. More simplifications along these lines may
be done later to the state record.
|
|
Move of PEM cache to own process was flawed and not all PEM files
where cached properly. We must properly handle both the ditributed
and the normal mode of the ssl application.
|
|
* ingela/ssl/key-ext-validate/ERL-338/OTP-14141:
ssl: The certificate path may be used as a source to find intermediate CAs for the CRL
ssl: Handle more than one DistributionPoint
ssl: Correct ssl_certificate:validate/3
|
|
for the CRL
|
