aboutsummaryrefslogtreecommitdiffstats
path: root/lib/ssl/src/ssl_alert.hrl
AgeCommit message (Collapse)Author
2018-06-18Update copyright yearHenrik Nord
2017-08-14dtls: Customize alert handling for DTLS over UDPIngela Anderton Andin
From RFC 6347: 4.1.2.7. Handling Invalid Records Unlike TLS, DTLS is resilient in the face of invalid records (e.g., invalid formatting, length, MAC, etc.). In general, invalid records SHOULD be silently discarded, thus preserving the association; however, an error MAY be logged for diagnostic purposes. Implementations which choose to generate an alert instead, MUST generate fatal level alerts to avoid attacks where the attacker repeatedly probes the implementation to see how it responds to various types of error. Note that if DTLS is run over UDP, then any implementation which does this will be extremely susceptible to denial-of-service (DoS) attacks because UDP forgery is so easy. Thus, this practice is NOT RECOMMENDED for such transports.
2017-07-07ssl: Enhance error loggingIngela Anderton Andin
2016-12-07Update copyright-yearErlang/OTP
2016-05-31Improve SSL diagnosticsAlexey Lebedeff
There are a lot of cases where `ssl` application just returns unhelpful `handshake failure` or `internal error`. This patch tries to provide better diagnostics so operator can debug his SSL misconfiguration without doing hardcore erlang debugging. Here is an example escript that incorrectly uses server certificate as a client one: https://gist.github.com/binarin/35c34c2df7556bf04c8a878682ef3d67 With the patch it is properly reported as an error in "extended key usage".
2015-06-18Change license text to APLv2Bruce Yinhe
2015-03-17ssl: Add TLS-ALPN supportLoïc Hoguin
This commit adds support for RFC7301, application-layer protocol negotiation. ALPN is the standard based approach to the NPN extension, and is required for HTTP/2. ALPN lives side by side with NPN and provides an equivalent feature but in this case it is the server that decides what protocol to use, not the client. When both ALPN and NPN are sent by a client, and the server is configured with both ALPN and NPN options, ALPN will always take precedence. This behavior can also be found in the OpenSSL implementation of ALPN. ALPN and NPN share the ssl:negotiated_protocol/1 function for retrieving the negotiated protocol. The previously existing function ssl:negotiated_next_protocol/1 still exists, but has been deprecated and removed from the documentation. The tests against OpenSSL require OpenSSL version 1.0.2+.
2015-03-02ssl: Implement support for TLS_FALLBACK_SCSVIngela Anderton Andin
2014-04-30ssl: Add checks to avoid processing of illegal alertsIngela Anderton Andin
2014-03-25ssl: Handle SNI alert unrecognized_name and gracefully deal withIngela Anderton Andin
unexpected alerts. Add recognitions of RFC 4366 alerts and handle possible unimplementd alerts in a gracefully way.
2013-03-28SSL: add TLS PSK (RFC 4279 and RFC 5487) cipher suitesAndreas Schultz
2012-08-22ssl: Add missing sslv3 alertIngela Anderton Andin
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP