| Age | Commit message (Collapse) | Author |
|---|
|
|
|
We want to be able to save a specific session to reuse, and make sure
it is reusable immediatly when the connection has been established.
Add client option {reuse_session, SessionID::binary()}
We also do not want clients to save sessions that it did not verify.
Additionaly change behaviour of the client and server to not save sessions
if reuse_session is set to false.
|
|
|
|
If upper limit is reached invalidate the current cache entries, e.i the session
lifetime is the max time a session will be keept, but it may be invalidated
earlier if the max limit for the table is reached. This will keep the ssl
manager process well behaved, not exhusting memeory. Invalidating the entries
will incrementally empty the cache to make room for fresh sessions entries.
|
|
|
|
The previous commit - 7b93f5d8a224a0a076a420294c95a666a763ee60 fixed the macro
only in one place.
|
|
ssl_session_cache:select_session/2 returned [sesionid(), #session{}]
instead of #session{} as the API demands.
This was wrongly compensated for in the code in one place making it
look like everything was good. But the client check for unique session
would always fail, potentially making the client session table grow
a lot and causing long setup times.
|
|
|
|
If an ssl server is restarted with new options and a client
tries to reuse a session the server must make sure that it complies
to the new options before agreeing to reuse it.
|
|
Only use ssl_manager for selecting new ids to guarantee uniqueness,
but reuse check does not need to be performed by the manager.
|
|
|
|
Added session status "new" to mark sessions that are
in the session database to reserve the session id
but not resumable yet and that we want to separate from
sessions that has been invalidated for further reuse.
|
|
|
|
|
|
We want the certificate table to be handled the same way as the
session table and not have a global name, so that we may easier
create a separate ssl-manager to handle erlang distribution over ssl.
|
|
|
|
Changed the behavior of the verify_fun option so that
the application can be responsible for handling path validation
errors even on the server side. Also replaced the not yet
documented validate_extensions_fun to be handled by the
verify_fun instead.
If the verify callback fun returns {fail, Reason}, the verification process is
immediately stopped and an alert is sent to the peer and the TLS/SSL
handshake is terminated. If the verify callback fun returns {valid,
UserState}, the verification process is continued. If the verify callback
fun always returns {valid, UserState}, the TLS/SSL handshake will not be
terminated with respect to verification failures and the connection
will be established. The verify callback fun will also be
able to verify application specific extensions.
|
|
Cleaned up and documented the public_key API to
make it useful for general use.
|
|
Started to improve code documentation by using -spec directive, and
some small refactorings to avoid ugly code.
|
|
|
