mirror of
https://gitlab.com/openconnect/ocserv.git
synced 2026-02-10 08:46:58 +08:00
40 lines
1.7 KiB
Plaintext
40 lines
1.7 KiB
Plaintext
Short term items:
|
|
|
|
* Think for ways for ocserv to co-exist on the same system with
|
|
an HTTPS server (while sharing the same port).
|
|
|
|
* IPv6 support is probably broken or non-optimal. See how it can be
|
|
improved.
|
|
|
|
* 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.
|
|
|
|
* Change into hashtables the lists that are used during a client
|
|
connection.
|
|
|
|
* Give each worker a limited number of accesses to the security module.
|
|
|
|
* If only a single instance of a client is allowed, then (depending on
|
|
a configurable option) allow dropping previous instances on a reconnect.
|
|
|
|
Long term items:
|
|
|
|
* Think how the DTLS part can use better negotiation of algorithms and DTLS
|
|
versions than the current openssl string approach (using PSK ciphersuites
|
|
seem to be like a solution, but then we could not use the session ID to
|
|
forward the UDP connection to the proper worker).
|
|
|
|
* Certificate authentication to the main process. Possibly that is just
|
|
wishful thinking. To verify the TLS client certificate verify signature
|
|
packet one needs instead of the signature, the contents of all the handshake
|
|
messages, and knowledge of the negotiated TLS version, in addition to 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).
|
|
|