| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
|
|
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".
|
|
|
|
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+.
|
|
|
|
|
|
unexpected alerts.
Add recognitions of RFC 4366 alerts and handle possible
unimplementd alerts in a gracefully way.
|
|
|
|
|
|
|
