Re: Adding OpenSSL ciphersuites at compile time

[Thomas Ward via nginx-devel]

If I remember correctly, the available cipher suites to NGINX are based
on what's compiled into the underlying SSL libraries that NGINX builds
against.  So if the underlying OpenSSL has access to ChaCha ciphers in
its ciphers that're compiled into it, then NGINX can utilize those
ChaCha ciphers.

I don't believe there's explicit NGINX compile-time configuration
options to enable ciphers at runtime, as this is dependent on the
OpenSSL libraries statically built into your binaries, and therefore
whatever OpenSSL cipher suites are enabled in it.  You can then
enable/disable the individual ciphers to be 'offered' by NGINX the
`ssl_ciphers` configuration parameter [1] to use ciphers that might not
be in the default cipherstring (which is "HIGH:!aNULL:!MD5" for
reference), though, which is the 'standard' way to define what cipher
suites should/shouldn't be used for SSL in the nginx instance when it's
running and serving SSL connections. 

Consider, though, that any ciphers you put in the cipherstring will only
be usable if the underlying SSL libraries (statically compiled in or
not) support those ciphers that are defined in the cipher string.


Thomas


[1]: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ciphers


On 04/05/2018 11:35 AM, Neil Craig wrote:
> Hi
>
> I build a customised nginx binary for my project, this is statically
> compiled against openssl (via —with-openssl). Does anyone know if it’s
> possible to add a configure option to enable specific ciphersuites?
> The OpenSSL docs are here:
>
> https://wiki.openssl.org/index.php/Compilation_and_Installation
>
> And these say that you can set a configure option of
> “enable-” if compiling OpenSSL directly. Is there some
> way I can tell the nginx build to do that?
>
> Cheers
> Neil
>
>  
>
> 
>
> http://www.bbc.co.uk 
> This e-mail (and any attachments) is confidential and may contain
> personal views which are not the views of the BBC unless specifically
> stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
> -
>
>
>
> ___
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel

___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: nginx 1.20.0 coverity errors

[Thomas Ward via nginx-devel]

You should probably be sending development related questions like this 
one to nginx-devel@nginx.org.


Additionally, what I've learned as a developer and a Security person is 
that **coverity static testing issues** are not always actual *issues* 
that need addressed.  Without details specifically on what tests're run, 
and in what circumstances, etc. static code analysis is never an 
all-holy solution that absolutely needs everything *fixed*.


It's been stated in the past on the nginx-devel list (CC'd) that these 
Coverity reports, etc. are usually false-positives or non-issues and 
therefore don't need to be constantly sent to NGINX for their 
awareness.  And additionally, one should not blindly trust Coverity 
testing/output to be 100% accurate/correct with their analyses.




Thomas


On 12/6/23 20:34, BILL wrote (to ng...@nginx.org):

Hi,

We have a coverity testing on nginx 1.20.0 and we got some errors.
Have any plan to resolve these errors?


Checker Number
ARRAY_VS_SINGLETON  3
BAD_FREE3
BUFFER_SIZE 1
CHECKED_RETURN  10
COPY_PASTE_ERROR1
DC.WEAK_CRYPTO  18
DEADCODE8
FORWARD_NULL49
MISSING_RESTORE 1
NO_EFFECT   8
NULL_RETURNS8
OVERRUN 12
PW.INCLUDE_RECURSION8
RESOURCE_LEAK   5
REVERSE_INULL   5
SIGN_EXTENSION  1
SIZEOF_MISMATCH 8
STACK_USE   1
STRING_NULL 1
TAINTED_SCALAR  1
TOCTOU  12
UNINIT  10
UNREACHABLE 63
UNUSED_VALUE4
USE_AFTER_FREE  1
Total   242


___
nginx mailing list
ng...@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx___
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel

Inquiry: Are nginx.org repos migrating from mercurial to git?

[Thomas Ward via nginx-devel]

Seeing a lot of messages related to moving from mercurial to git here in the 
mailing list. Are the nginx.org code repos shifting to Git instead of Mercurial?



Sent from my Galaxy

___
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel

Proposal: Change `ssl_client_certificate` to `ssl_client_ca_certificate`

[Thomas Ward via nginx-devel]

In line with a recent nginx mailing list thread I had with a user about 
how to properly secure a site with SSL/TLS Client Certificates, the user 
indicated that "ssl_client_certificate" is a confusing misnomer.  It 
implies that the certificate(s) provided are a bundle of certs that are 
*individual client certificates* not the Certification Authority (CA) 
certificate and chain that issued the certificiates.


It's always annoyed me slightly that it has been 
"ssl_client_certificate" and has no mention of it being a CA cert. I'm 
guessing that's because you could theoretically use a self-signed 
certificate and verify it against itself, thus not needing a CA 
certificate, however that's not the primary use case nor is that how 
it's really explained in the NGINX documentation of the command.


Has there been any discussion or consideration of renaming 
ssl_client_certificate to something that is less confusing to people new 
to the process, to show that this is supposed to be the CA certificate 
of the authority that is issuing the client certificates?



Thomas
___
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel