| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Change scheduler responsiveness to 'check_schedulers'.
|
|
* legoscia/fix-ssl-example/PR-976/OTP-13363:
ssl: Modernize utility function
Fix ssl example
|
|
* bernardd/gen_tcp_export_socket:
Export gen_tcp:socket() type
OTP-13380
|
|
* kostis/hipe-icode-cleanup:
Fix dialyzer warning and some code refactoring
OTP-13379
|
|
* legoscia/crl-check-without-dp:
Be suspicious of certificates without CRL DPs
Refactor ssl_crl_SUITE: extract crl_verify_error/6
OTP-13378
|
|
* legoscia/critical-extension-verify-none:
ssl: with verify_none, accept critical extensions
OTP-13377
|
|
* benwilson512/better-maps-with:
Improved maps:with/2 and maps:without/2 algorithm
OTP-13376
|
|
Conflicts:
lib/eldap/src/eldap.erl
|
|
|
|
Fix mistakes found by 'xmllint'.
|
|
Use application:ensure_all_started/2 instead of hard coding dependencies
|
|
|
|
|
|
|
|
In addition, the heart API is extended with the following functions:
* heart:set_options/1
* heart:get_options/0
If heart:set_options([scheduler]) is set, heart will check
scheduler responsiveness before every heartbeat to the heart port.
|
|
|
|
|
|
|
|
|
|
As recently discussed on the erlang-questions mailing list, this
example fails to start the ssl application because ssl depends on asn1
nowadays. Let's future-proof this by using
application:ensure_all_started/1.
|
|
|
|
|
|
Conflicts:
lib/ssh/test/ssh_upgrade_SUITE.erl
|
|
|
|
|
|
* ia/ssl/connection_information/OTP-13232/OTP-13343:
ssl: Newer cipher suites now presented correctly
ssl: Include options form connect/listen/accept in connection_information/[1,2]
|
|
Older SSL/TLS versions have cipher suites
that look like {key_exchange(), cipher(), MAC::hash()}
and the hash function used by the PRF (Pseudo Random function)
is implicit and always the same for that protocol version.
In TLS 1.2 a cipher suite is
{key_exchange(), cipher(), MAC::hash(), PRF::hash()}.
Internally a cipher suite is always a four tuple but
for backwards compatibility older cipher suites
will be presented as a three tuples, however new cipher suites
should be presented as four tuples.
|
|
|
|
* dgud/observer/doc:
Observer: Editorial changes in documentation
|
|
|
|
Make sure that options only relevant for one role (client|server) is set
to undefined when the other role is invoked. As there are many options to
ssl, and many are optional, we choose to filter out all undefined options
to avoid overwhelming the user with not relevant information.
This way there is no need for any special handling of the role specific options
which is also nice.
|
|
|
|
|
|
|
|
If a ssh package contained more than one netconf end tag, then the
second end tag was never detected in ct_netconfc:handle_data. Instead
it was included in the XML data given to the xmerl parser, which then
failed with reason "\"]]>\" is not allowed in content".
This problem was introduced by OTP-13007.
|
|
* legoscia/ssl-doc-typos:
Fix typos in ssl.xml
OTP-13339
|
|
See also http://bugs.erlang.org/browse/ERL-95.
|
|
Previously, if certificate revocation checking was turned on, and a
certificate didn't contain a CRL Distribution Points extension, and
there was no relevant CRL in the cache, then ssl_handshake:crl_check
would accept the certificate even if the crl_check option was set to
reject certificates for which the revocation status could not be
determined. With this change, such certificates will only be accepted
if the crl_check option was set to best_effort.
The process for CRL validation is described in section 6.3 of RFC
5280. The text doesn't mention any special treatment to be given to
certificates without distribution points: it just says "For each
distribution point..." (section 6.3.3), which would leave the
revocation status undetermined, unless there were "any available CRLs
not specified in a distribution point but issued by the certificate
issuer". Thus the result of this algorithm should be UNDETERMINED in
this case, not UNREVOKED, and the crl_check option should govern how
the implementation reacts to this result.
|
|
When establishing a TLS connection with {verify, verify_none}, if the
server has a certificate with a critical extension, for example a
"Netscape Cert Type" extension, certificate verification would fail,
which is surprising given that the name of the option suggests that no
verification would be performed.
With this change, certificate extensions marked as critical are
ignored when using verify_none.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
