SSL: $ssl_sigalg, $ssl_client_sigalg. #932
Conversation
|
|
||
| const char *name; | ||
|
|
||
| if (SSL_get0_signature_name(c->ssl->connection, &name)) { |
There was a problem hiding this comment.
I was afraid that SSL_get0_signature_name returns empty string name, so I use SSL_get_peer_signature_type_nid instead, if it can't get string name, then the variables return digits string as a backup.
There was a problem hiding this comment.
Both functions are accessors to the same SIGALG_LOOKUP structure, ultimately - an entry in lookup table combined from builtin and provider-added sigalgs.
Builtin sigalgs started to always have the name in OpenSSL 3.4 (38a7183102), preceding SSL_get0_signature_name() introduction.
Providers sigalgs have such requirement since its introduction (OSSL_CAPABILITY_TLS_SIGALG_IANA_NAME, ee58915cfd).
IOW, if there SIGALG_LOOKUP is found, it should contain both nid and name.
There was a problem hiding this comment.
@pluknet But what if Nginx is built with openssl before SSL_get0_signature_name was introduced? These two variables just return empty string. It would be better to add a #else case when #ifdef SSL_get0_signature_name failed, and using SSL_get_signature_type_nid to implement the function. As you explained above, SSL_get0_signature_name will always return non-empty sigalg name, but I still prefer to check the return result, if it's empty, then it should try to return nid digits as a backup result, since there are many companies out there fork and maintain their own openssl implementation and it may not 100% fullfilling the requirements, when it happens, these two variables' result are meaningless since their result are empty.
There was a problem hiding this comment.
I don't think it worth the effort.
SSL_get0_signature_name() was implemented in OpenSSL precisely for logging purpose, basically that's why it is used. See my previous explanation in #545 (review) for detailed reasoning.
Note that OpenSSL 3.5 is an LTS branch, it is quite reasonable to base new variables on this version.
The last argument I don't get, sorry.
If companies have resources to maintain OpenSSL forks, they certainly will be able for nginx.
|
Do you plan a This will be helpful during PQC certificate transition. |
@ghen2 @pluknet |
src/stream/ngx_stream_ssl_module.c
Outdated
| (uintptr_t) ngx_ssl_get_client_v_remain, NGX_STREAM_VAR_CHANGEABLE, 0 }, | ||
|
|
||
| { ngx_string("ssl_client_sigalg"), NULL, ngx_stream_ssl_variable, | ||
| (uintptr_t) ngx_ssl_get_sigalg, NGX_STREAM_VAR_CHANGEABLE, 0 }, |
There was a problem hiding this comment.
Fixed, tnx.
I tested only http part, that's how it was missed
|
Regarding the commit log, I'd prefer the text from the docs, YMMV. |
Variables contain the IANA name of the signature scheme[1] used to sign the TLS handshake. Variables are only meaningful when using OpenSSL 3.5 and above, with older versions they are empty. Moreover, since this data isn't stored in a serialized session, variables are only available for new sessions. [1] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml Requested by willmafh.
Applied, thanks. Wording was roughly taken from https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3 |
The variables contain an algorithm used in CertificateVerify signatures in the format of TLS SignatureScheme:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
Requested by willmafh.
Closes #554