| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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
|
|
|
|
* ingela/ssl/crl-validity:
ssl: Make crls valid for a week instead of 24 hours
|
|
|
|
* egil/percept/remove-application/OTP-14163:
ssl: Remove percept from benchmark
otp: Don't mention percept in documentation
runtime_tools: Remove percept
percept: Remove application
|
|
|
|
Changes made to ssl_certificate:validate appear to be preventing CRL
validation from happening when an id-ce-extKeyUsage extension is
present in the cert before the DistributionPoint extension.
https://github.com/erlang/otp/blob/448e8aca77dd29ed5b37d56f0700d24ac26a7243/lib/ssl/src/ssl_certificate.erl#L131
See also ERL-338 and PR-1302
|
|
|
|
The PEM cache handling has proven to be too disruptive of the manager process.
|
|
If a handshake message is really big it could happen that the ssl
process would hang due to failing of requesting more data from the
socket. This has been fixed.
Also added option to limit max handshake size. It has a default
value that should be big enough to handle normal usage and small
enough to mitigate DoS attacks.
|
|
With the 24 option we might be unlucky and get failing tests just because
cert expired before the test is run.
|
|
When the terminate function is called explicitly, to make guarantees
that for instance the reuseaddr option works as expected, we must
make sure that the clean up code is not run again when gen_statem
calls terminate. This check was broken in the rewrite from gen_fsm to
gen_statem.
Caused PEM cache errors, that in some cases would
cause unexpected connection failures.
|
|
|
|
|
|
* ingela/ssl/next-version:
ssl: Prepare for release
|
|
* ingela/dtls/statem/OTP-12982:
ssl: Implement DTLS state machine
|
|
* ingela/ECC-tests:
ssl: Make sure common-test priv_dir is used for test case generated files
|
|
|
|
Beta DTLS, not production ready. Only very basically tested, and
not everything in the SPEC is implemented and some things
are hard coded that should not be, so this implementation can not be consider
secure.
Refactor "TLS connection state" and socket handling, to facilitate
DTLS implementation.
Create dtls "listner" (multiplexor) process that spawns
DTLS connection process handlers.
Handle DTLS fragmentation.
Framework for handling retransmissions.
Replay Detection is not implemented yet.
Alerts currently always handled as in TLS.
|
|
ECC certs should preferably use SHA2, this is what we want to be
testing. Also assembling of all available test suites must consider TLS version.
|
|
* ingela/ssl/tune-timeouts-packet_SUITE:
ssl: Change to more modest timeouts
|
|
We where never really satisfied with this workaround it was
a bit far fetched, so we are pleased to be able to remove it.
|
|
|
|
* ferd/ssl-allow-ecc-config/PR-1210/OTP-13959:
Add ECC curve selection order config in TLS server
|
|
As per RFC 4492 Sec 5.1, the preferred order of selection of named
curves is based on client preferences.
Currently, the SSL application only picks entries according to the
absolute order of entries as tracked in a hardcoded list in code.
This patch changes things so that the client-specified order is
preferred. It also allows a mode where the server can be configured to
override the client's preferred order with its own, although the chosen
ECC must still be within both lists.
The configuration is done through the following options:
- `eccs`, shared by clients and servers alike, allows the specification
of the supported named curves, in their preferred order, and may
eventually support more values for explicit primes and so on.
- `honor_ecc_order`, a server-only option, is similar to
`honor_cipher_order` and will, by default let the server pick the
client-preferred ECC, and otherwise pick the server-preferred one.
The default value for `eccs` is the same as before, although the
server-chosen ECC now defaults to the client rather than previous
choice.
A function `ssl:eccs()` has been added that returns the highest
supported ECCs for the library.
|
|
Correct "...an exra distribution..." to "...an extra distribution...".
|
|
This should be fine as timeout problem was due to test case
bug that treated a stream as if it was packet oriented.
|
|
|
|
* ingela/ssl/algo-check/OTP-13959:
Properly filter ssl cipher suites reported as supported
|
|
* ingela/ssl/crl_SUITE:
ssl: Make sure test has correct input
|
|
Adapted from commit 675ee6860d2c273bcc6c6a0536634a107e2a3d9f.
Conflicts:
lib/ssl/src/ssl_cipher.erl
|
|
* ingela/ssl/cipher-type-spec:
ssl: Adjust cipher type to conform to implementation
|
|
|
|
* RoadRunnr/crypto/no-rc4/PR-1169/OTP-13896:
disable RC4 in SSL when crypto doesn't support it
Fix compilation when OpenSSL doesn't support RC4
Conflicts:
lib/crypto/c_src/crypto.c
|
|
Data collection function active_once_raw/4 did not handle streamed
data correctly (it assumed the stream was "packet oriented"),
which could result in that the test case perceived that
it did not receive all data even though it did.
|
|
Test suite did not take TLS-version in to account. Also
some anonymous suites where included incorrectly in some TLS versions.
|
|
|
|
* ingela/ssl/prepare-patch:
ssl: Prepare for release
|
|
* ingela/ssl/ECC-selection-fix/OTP-13918:
ssl: Correct ECC curve selection, the error could cause default to always be selected.
|
|
selected.
|
|
|
|
Several handshake events may be received in the same TLS packet. Then there
will be several events pushed to the gen_statems internal queue.
New events already in the socket-buffer should not be processed
if there are more unprocessed handshake events in next_event queue.
We need to handle this in the next_record/1 function.
|
|
|
|
|
