mirror of
https://gitlab.com/openconnect/ocserv.git
synced 2026-02-10 16:57:00 +08:00
2a0cc77c2e
When a worker process terminates in authenticated state, then export statistics from the tun device (currently bytes_in and bytes_out). These statistics are sent to main process using an informational message just prior to process exit. The statistics are also exported to the disconnect script using the STATS_BYTES_IN and STATS_BYTES_OUT environment variables.
45 lines
2.0 KiB
Plaintext
45 lines
2.0 KiB
Plaintext
Short term items:
|
|
|
|
* Move PAM (and other authentication methods) to sec-mod, to prevent
|
|
any leakage to the worker process. Alternatively that could be
|
|
prevented in a fork-then-exec mode switch, but on fortunately that
|
|
requires the reload of all certificates/parameters on the worker
|
|
process, and imposes a quite high penalty (see the 'exec' branch).
|
|
|
|
* Think for ways for ocserv to co-exist on the same system with
|
|
an HTTPS server (while sharing the same port).
|
|
|
|
* More elaborate checks on "make check". Currently we test whether a
|
|
cookie can be obtained, but not whether a TUN devices is created or
|
|
data can be transfered. Need more ideas on how that can be done.
|
|
|
|
* When a user (IP) gets into the BAN list multiple times, disable it for
|
|
longer time (or should we drop this functionality altogether and rely
|
|
on PAM handling that?)
|
|
|
|
* Change into hashtables the lists that are used during a client
|
|
connection.
|
|
|
|
* Give each worker a limited number of accesses to the security module.
|
|
|
|
* Use talloc in main process to simplify the release of resources.
|
|
|
|
Long term items:
|
|
|
|
* Think how the DTLS part can use better negotiation of algorithms and DTLS
|
|
is negotiated properly. Using PSK ciphersuites seem to be like a solution,
|
|
but that would require a new protocol to be implemented in openconnect
|
|
client and ocserv.
|
|
|
|
* Certificate authentication to the main process. Possibly that is just
|
|
wishful thinking. To verify the TLS client certificate verify signature
|
|
one needs in addition to the signature, the contents of all the handshake
|
|
messages, and knowledge of the negotiated TLS version, as well as being
|
|
able to select the server hello random. That could be done sanely only if
|
|
gnutls provided facilities to set the server hello random, and override the
|
|
client signature verification at an early stage before data are hashed
|
|
(to verify that the set random value was present in the handshake).
|
|
However, the complexity required to implement that may in fact reduce
|
|
security rather than increase it.
|
|
|