Hi,
I hope this is the right list. If it is the wrong list I'd welcome a
hint to the correct list.
Some suggestions for the ressl API:
* Please consider making ressl_config_set_protocols accepting a string
as option instead.
Using constants for protocols like OpenSSL does make it much harder
for programs using the library to do just the right thing.
Estimating behavior similar to programs using OpenSSL programs will
either not offer to set it at all (which means it is much harder
to disable old protocols especially as long as there is still another
program using the same library and needing a older version),
or hardcode it (meaning even using new protocols needs
using patched/newer versions).
or have their own special way to specify the protocol in configuration
files, often not yet supporting the newest protocols.
(In the case of some language binding translating the constants to
something similar and not strings, one then needs a newer library,
a newer language bindings and a newer/patched program to be able to
use a newer protocol version).
Perhaps it makes sense to even put that in a even more generic thing,
to allow users to specify other protocol variations while only needing
a newer library version. (In case per-server choices similar to the
"no renegotiation"/"only secure renegotiation"/"any renegotiation" will
appear again in the future).
* Some way to override the name to be looked for in the certificate
would be nice.
Both to support speaking with broken/incomplete systems (wrong
certificates, certificates not listing alternate interfaces and missing
SNI, ..) and for monitoring (connecting to a specific host behind a
loadblancer or behind DNS-round-robin and checking the certicate as
it will be checked by real clients) a way to specify a different name
to expect in the certificate would be nice.
(If using ressl directly one could always use ressl_connect_socket,
but I guess most programs using it will only offer calling
ressl_config_insecure_noverifyhost (or even only
ressl_config_insecure_noverifycert)).
* An option to only look at subjectAltName and not CN would be nice.
If only to allow more paranoid monitoring checking if ssl clients
not looking at CN can connect (or not looking at CN if there is
subjectAltName).
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
