Age | Commit message (Collapse) | Author |
|
Also fix DTLS call to supply its corresponding TLS version
|
|
Negotiated version is now always passed to ssl_handshake:select_hashsign
because ssl_handshake:select_cert_hashsign has different rsa defaults on
tlsv1.2 and older versions.
|
|
|
|
When selecting the available cipher suites for the server all cipher suites
for the highest supported SSL/TLS-version would be selected, and not
all supported for the negotiated SSL/TLS-version. This could lead
to that faulty clients could negotiate cipher suites that they
can not support. This change will enable the faulty client to negotiate
another cipher suite that it can support.
|
|
Conflicts:
lib/ssl/src/dtls_record.erl
|
|
crashing.
When TLS client sends Supported Elliptic Curves Client Hello Extension
the server shall select a curve supported by both sides or refuse to
negotiate the use of an ECC cipher suite.
|
|
|
|
public_key:private_key/0 was referenced but undefined, and lib/ssl had a
local definition of private_key/0.
To fix that, make the following changes:
* add public_key:private_key/0 type
* document public_key/0 and private_key/0
* fix incorrect definitions and references
|
|
* ia/Vagabond/adt-honor-cipher-order/OTP-11621:
Implement 'honor_cipher_order' SSL server-side option
|
|
did not support secure renegotiation
|
|
HonorCipherOrder as implemented in Apache, nginx, lighttpd, etc. This
instructs the server to prefer its own cipher ordering rather than the
client's and can help protect against things like BEAST while
maintaining compatability with clients which only support older ciphers.
This code is mostly written by Andrew Thompson, only the test case was
added by Andreas Schultz.
|
|
The server code erroneously took the list of curves supported by the
client from it's own hello extension, effectively breaking curve
selection all together.
Also the default fallback secp256k1 curve is not supported by
all clients. secp256r1 is recommended as part of the NIST Suite B
cryptographic suites. The chances are much better that all clients
support it, so use that as fallback.
|
|
New design : ssl - Main
tls - Reflect tls specific semantics
dtls - Reflect dtls specific semantics
|
|
|
|
|
|
|
|
- Set to disable to explicitly disable SNI support.
- Set to a hostname when upgrading from TCP to TLS.
|
|
See RFC 6066 section 3
|
|
Also the server should only send ECC point formats extension not ECC curve
extension.
|
|
|
|
|
|
|
|
Also refactor so that TLS and DTLS can have common functions when possible.
|
|
Common functions will be located in ssl_handshake.erl while
specific functions will be located in tls_handshake.erl and dtls_handshake.erl
|
|
Also phase in tls module as main API instead of ssl. To
make API clearer. As TLS is the new protocol name.
Maybe keep some API functions in ssl
|
|
Conflicts:
lib/ssl/src/ssl.app.src
lib/ssl/src/ssl_manager.erl
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Avoid unneccessary conversion as the input format is an oid (according
to ASN1 spec) we do not need to handle it as an atom in ssl.
|
|
|
|
|
|
Use the functions in crypto that we want to keep in the API.
|
|
|
|
|
|
|
|
|
|
server key encoding depends to the negotiated key exchange. Before
the encoding was limited to diffie-hellman keys. This changes allows
to select the key structure to decode and verify. It also consolidates
the transport encoding of the parameters into one place.
|
|
ssl_handshake and ssl_connection where doing essentially the same when
checking a public key signature. This unify both into a single function
|
|
SHA-224 is still better than SHA-1, so let the world know we support it
|
|
Types in a record where wrongly type specified, did not include
undefined. Make them comments for now, maybe we will specify internal
records with dialyzer types later, but as the other record fields are
not specified at the moment, with dialyzer types, make the code
consistent.
|
|
more "sense" (be true to the specification).
|
|
* http://technotes.googlecode.com/git/nextprotoneg.html
|
|
utf8 and close down gracefully if other ASN-1 errors occur.
The reason certificate_unknown that is used as ALERT for ASN-1 encoding failure is described as:
Some other (unspecified) issue arose in processing the
certificate, rendering it unacceptable.
|
|
|
|
|
|
with TLS 1.2 the hash and signature on a certify message can
differ from the defaults. So we have to make sure to always
use the hash and signature algorithm indicated in the
handshake message
|