How to establish secure connection between NGINX <-> https upstream API
Using below config, According to this,
https://docs.nginx.com/nginx/admin-guide/security-controls/securing-http-traffic-upstream/#
server {
listen 80;
server_name nginx_server_name;
#...
upstream dev {
zone dev 64k;
server backend.example.com:443;
}
location /upstream {
proxy_pass https://$upstream$request_uri;
proxy_ssl_certificate /etc/nginx/client.pem;
proxy_ssl_certificate_key /etc/nginx/client.key;
proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
proxy_ssl_ciphers HIGH:!aNULL:!MD5;
proxy_ssl_trusted_certificate /etc/nginx/trusted_ca_cert.crt;
proxy_ssl_verifyon;
proxy_ssl_verify_depth 2;
proxy_ssl_session_reuse on;
}
}
What is below client.pem & client.key?
is this the nginx client files which needs to be created and signed with CA?
or is that a backend.example.com ssl certs?
What is trusted_ca_cert.crt;?
Is this related to backend.example.com? how can i obtain this?
Steps i did:
Created csr & key using openssl with CN as nginx_server_name
signed & Got the cert (client.crt) -> client.pem configured both client.pem
& .key in config
But getting below exception when i hit the API.
upstream SSL certificate verify error: (19:self signed certificate in
certificate chain) while SSL handshaking to upstream, client: ,
server: , request: "POST /getsomething HTTP/1.1", upstream:
"https://backend.example.com:443/getsomething;, host: "nginx_server_ip"
--
Sent from: http://nginx.2469901.n2.nabble.com/
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Re: Prevent direct access to files but allow download from site
* MAXMAXarena: > The user MUST BE ABLE to download the file from the article pages when > LOGGED. If the user is NOT LOGGED, he cannot download the file, > therefore even recovering the url, he must receive an error or any > other type of block. You describe restricted access, not public access. That differs from your OP where you wanted to have it both ways. See NGINX docs, section "Restricting Access with HTTP Basic Authentication". The latter can be replaced with LDAP or whatever auth mechanism you prefer should basic authentication not be to your taste. -Ralph ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
RE: Prevent direct access to files but allow download from site
> The user MUST BE ABLE to download the file from the article pages when > LOGGED. > If the user is NOT LOGGED, he cannot download the file, therefore even > recovering the url, he must receive an error or any other type of block. It's rather difficult to achieve that only with a webserver (as typically a webserver itself has no idea about users being logged in or out and just to rely on a cookie is possible but rather weak check). While you can use the secure link module (https://nginx.org/en/docs/http/ngx_http_secure_link_module.html ) with expiration a more common way would be to implement the download check in the application itself and use the nginx X-Accel-Redirect feature - https://www.nginx.com/resources/wiki/start/topics/examples/xsendfile/ Without knowing what kind of app (php/python/js/perl etc) are you running it's hard to give an exact example but the gist of the idea is to: - place the files outside webroot - configure the path as an internal nginx location - the application then checks if the user has an active session, then sends the X-Accel-Redirect header with the particular file to nginx which sends the file to user. There should be plenty of samples on internet. rr ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Elasticsearch Native Binary Protocol through NGiNX Stream
I assume Liferay is throwing exceptions. Are these timeouts or indications of broken connections? A typical problem with the Elasticsearch Native Protocol is that it does not like third-party tear-downs of connections it uses (e.g., by NGINX or some load balancer). Posted at Nginx Forum: https://forum.nginx.org/read.php?2,287254,287325#msg-287325 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Prevent direct access to files but allow download from site
The key requirement you mentioned now: the user needs to be logged in.
So, the next question is: how do we know the user is logged in. It can't be
just a simple cookie because that could be faked (I could add "LOGGED_IN=1"
without the site authorizing this), and therefore there is no security at
all. Maybe added obscurity :-)
What you need to do is issue a cookie that can only have been created by
NGINX, e.g., something like a string "{user}/{checksum}", where {user} is
the id of the logged-in user, and {checksum} is an HMAC of a secret only
known to NGINX and that user id. In consequence, without knowing the secret,
nobody can fake this cookie. If NGINX gets the cookie, it can determine the
HMAC of the user id and compare against the checksum provided, in order to
check the validity of the request.
The HMAC computation and validation can quickly be done with a few lines of
Javascript, and would even allow for some sort of single sign-on across all
services capable of using these functions (also in other NGINX instances
knowing this secret). Maybe you want to add some form of expiration to such
cookies.
The classical way, however, is to use https and something like a basic
authentication (auth_basic directive), and require valid authentication for
those URIs referring to protected files. If your authentication scheme is a
bit more complex, you may want to use auth_request or some form of initial
login plus a secured session cookie as described above. Essentially, this
principle (with JWT) is also used by more novel schemes such as OpenID
Connect.
Let's see if this helps you further.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,287297,287324#msg-287324
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Re: HTTP/1.1 400 Bad Request при рестриме аудио потока
On Thu, Mar 12, 2020 at 12:54:31PM -0400, grey wrote:
> Dmytro Lavryk Wrote:
> ---
> > Вы ошибку не описали... Но, подозреваю, делаете HEAD запрос. Проверил
> > у себя на аналогичном - HEAD дает 400, а вот GET отрабатывает
> > нормально со всеми нужными заголовками.
>
> Да, действительно, дело в типе запроса, но понять не могу почему так
> происходит. Напишу тут код на php, я думаю программистам других языков он
> будет понятен:
>
> $fp = fsockopen("test.ru", 443, $errno, $errstr, 30);
> $out = "GET /radio-stream HTTP/1.1\r\n";
> $out .= "Host: test.ru\r\n";
> $out .= "Connection: Close\r\n\r\n";
> fwrite($fp, $out);
> while (!feof($fp)) echo fgets($fp, 128);
> fclose($fp);
>
> В нем я явно указываю тип запроса GET, а nginx почему говорит что к нему
> пришел HEAD
Откуда вывод, что nginx якобы видит HEAD?
> и возвращает ответ "400 Bad Request".
> Проверил на разных версиях
> php - результат везде одинаковый, т.к. вроде как дело не в нем.
И что, вот так просто шлём plain http на 443-й порт, а nginx недоволен?
--
Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
[nginx-announce] unit-1.16.0
Hi,
I'm glad to announce a new release of NGINX Unit.
---
To all Unit package maintainers: please don't miss the new '--tmp'
configure option. It specifies the directory where the Unit daemon
stores temporary files (i.e. large request bodies) at runtime.
---
In this release, we continue improving the functionality related to
proxying and static media asset handling.
Now, the new 'upstreams' object enables creating server groups
for weighted round-robin load balancing:
{
"listeners": {
"*:80": {
"pass": "upstreams/rr-lb"
}
},
"upstreams": {
"rr-lb": {
"servers": {
"192.168.0.100:8080": { },
"192.168.0.101:8080": {
"weight": 2
}
}
}
}
}
See the docs for details:
- https://unit.nginx.org/configuration/#configuration-upstreams
So far, it's rather basic, but many more proxying and load-balancing
features are planned for future releases.
By its design, the new 'fallback' option is somewhat similar to the
'try_files' directive in nginx. It allows proceeding to another
action if a file isn't available:
{
"share": "/data/www/",
"fallback": {
"pass": "applications/php"
}
}
In the example above, an attempt is made first to serve a request
with a file from the "/data/www/" directory. If there's no such
file, the request is passed to the "php" application.
Also, you can chain such fallback actions:
{
"share": "/data/www/",
"fallback": {
"share": "/data/cache/",
"fallback": {
"proxy": "http://127.0.0.1:9000;
}
}
}
More info:
- https://unit.nginx.org/configuration/#configuration-fallback
Finally, configurations you upload can use line (//) and block (/* */)
comments. Now, Unit doesn't complain; instead, it strips them from the
JSON payload. This comes in handy if you store your configuration in a
file and edit it manually.
Changes with Unit 1.16.0 12 Mar 2020
*) Feature: basic load-balancing support with round-robin.
*) Feature: a "fallback" option that performs an alternative action if a
request can't be served from the "share" directory.
*) Feature: reduced memory consumption by dumping large request bodies
to disk.
*) Feature: stripping UTF-8 BOM and JavaScript-style comments from
uploaded JSON.
*) Bugfix: negative address matching in router might work improperly in
combination with non-negative patterns.
*) Bugfix: Java Spring applications failed to run; the bug had appeared
in 1.10.0.
*) Bugfix: PHP 7.4 was broken if it was built with thread safety
enabled.
*) Bugfix: compatibility issues with some Python applications.
To keep the finger on the pulse, see our further plans in the roadmap here:
- https://github.com/orgs/nginx/projects/1
Also, good news for macOS users! Now, there's a Homebrew tap for Unit:
- https://unit.nginx.org/installation/#homebrew
Stay healthy!
wbr, Valentin V. Bartenev
___
nginx-announce mailing list
nginx-announce@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-announce
Unit 1.16.0 release
Hi,
I'm glad to announce a new release of NGINX Unit.
---
To all Unit package maintainers: please don't miss the new '--tmp'
configure option. It specifies the directory where the Unit daemon
stores temporary files (i.e. large request bodies) at runtime.
---
In this release, we continue improving the functionality related to
proxying and static media asset handling.
Now, the new 'upstreams' object enables creating server groups
for weighted round-robin load balancing:
{
"listeners": {
"*:80": {
"pass": "upstreams/rr-lb"
}
},
"upstreams": {
"rr-lb": {
"servers": {
"192.168.0.100:8080": { },
"192.168.0.101:8080": {
"weight": 2
}
}
}
}
}
See the docs for details:
- https://unit.nginx.org/configuration/#configuration-upstreams
So far, it's rather basic, but many more proxying and load-balancing
features are planned for future releases.
By its design, the new 'fallback' option is somewhat similar to the
'try_files' directive in nginx. It allows proceeding to another
action if a file isn't available:
{
"share": "/data/www/",
"fallback": {
"pass": "applications/php"
}
}
In the example above, an attempt is made first to serve a request
with a file from the "/data/www/" directory. If there's no such
file, the request is passed to the "php" application.
Also, you can chain such fallback actions:
{
"share": "/data/www/",
"fallback": {
"share": "/data/cache/",
"fallback": {
"proxy": "http://127.0.0.1:9000;
}
}
}
More info:
- https://unit.nginx.org/configuration/#configuration-fallback
Finally, configurations you upload can use line (//) and block (/* */)
comments. Now, Unit doesn't complain; instead, it strips them from the
JSON payload. This comes in handy if you store your configuration in a
file and edit it manually.
Changes with Unit 1.16.0 12 Mar 2020
*) Feature: basic load-balancing support with round-robin.
*) Feature: a "fallback" option that performs an alternative action if a
request can't be served from the "share" directory.
*) Feature: reduced memory consumption by dumping large request bodies
to disk.
*) Feature: stripping UTF-8 BOM and JavaScript-style comments from
uploaded JSON.
*) Bugfix: negative address matching in router might work improperly in
combination with non-negative patterns.
*) Bugfix: Java Spring applications failed to run; the bug had appeared
in 1.10.0.
*) Bugfix: PHP 7.4 was broken if it was built with thread safety
enabled.
*) Bugfix: compatibility issues with some Python applications.
To keep the finger on the pulse, see our further plans in the roadmap here:
- https://github.com/orgs/nginx/projects/1
Also, good news for macOS users! Now, there's a Homebrew tap for Unit:
- https://unit.nginx.org/installation/#homebrew
Stay healthy!
wbr, Valentin V. Bartenev
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Re: Prevent direct access to files but allow download from site
Hi, thanks again for the reply. HOW I want to block I don't know, I am on this forum for this reason. I thought I was clear, I don't know how to explain it in different words. I want to prevent the user from downloading the file without being logged on my site. The user MUST BE ABLE to download the file from the article pages when LOGGED. If the user is NOT LOGGED, he cannot download the file, therefore even recovering the url, he must receive an error or any other type of block. I have already tried using the parameter valid_referes, it seems that I have to specify the domain and also the address of the article pages, but they are dynamic, the article is not always the same. Maybe I'm doing something wrong. If I enter my domain as valid_referer, the user can still download the file by retrieving the link of the site, from the download history (if he has previously downloaded the file) Example of an article address domain.com/my-first-article On this page there is a link to download a file located in this path: domain.com/assets/file/test.pdf The user does not need to be able to copy and paste this link into the brower to access the file directly. I'm continuing to try, but maybe I'm missing some operating logic. Posted at Nginx Forum: https://forum.nginx.org/read.php?2,287297,287319#msg-287319 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: HTTP/1.1 400 Bad Request при рестриме аудио потока
Dmytro Lavryk Wrote:
---
> Вы ошибку не описали... Но, подозреваю, делаете HEAD запрос. Проверил
> у себя на аналогичном - HEAD дает 400, а вот GET отрабатывает
> нормально со всеми нужными заголовками.
Да, действительно, дело в типе запроса, но понять не могу почему так
происходит. Напишу тут код на php, я думаю программистам других языков он
будет понятен:
$fp = fsockopen("test.ru", 443, $errno, $errstr, 30);
$out = "GET /radio-stream HTTP/1.1\r\n";
$out .= "Host: test.ru\r\n";
$out .= "Connection: Close\r\n\r\n";
fwrite($fp, $out);
while (!feof($fp)) echo fgets($fp, 128);
fclose($fp);
В нем я явно указываю тип запроса GET, а nginx почему говорит что к нему
пришел HEAD и возвращает ответ "400 Bad Request". Проверил на разных версиях
php - результат везде одинаковый, т.к. вроде как дело не в нем.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,287264,287318#msg-287318
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Prevent direct access to files but allow download from site
Without you being more specific on HOW you want to block direct
downloads and how extreme you want to prevent it, then it's all just a
wild guess what kind of solution you want.
>From the example link you gave for stackoverflow, it sounds like you
just want to prevent hotlinking (i.e. downloading without the client
sending a proper referral URL)...
The nginx equivalent of the apache blocking via referral can be found:
http://nginx.org/en/docs/http/ngx_http_referer_module.html
You just set the 'valid_referers' you want, then create a simple 'if'
statement in a location to return a '403 forbidden'...
if ($invalid_referer) { return 403; }
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Re: UDP Connection refused
Hello!
On Thu, Mar 12, 2020 at 02:32:23AM -0400, inkognito0609 wrote:
> При отправке логов через syslog (udp) проскакивают ошибки 111 Connection
> refused, что непонятно при отправке логов по udp, так как этот протокол не
> подразумевает установки соединения в принципе.
>
> strace дает следующее:
> 30752 sendto(64, "<190>Mar 12 09:45:59 balancer nginx: { \"timestamp\":
> \"2020-03-12T09:45:59+05:00\", \"remote_addr\": \"91.144.134.5\",
> \"body_bytes_sent\": 18686, \"request_time\": 0.000, \"response_status\":
> 200, \"request\": \"GET /themes/default/images/flags.png HTTP/1.0\",
> \"request_method\": \"GET\", \"host\":
> \"chel.wifi.example.ru\",\"upstream_cache_status\":
> \"HIT\",\"upstream_addr\": \"\",\"http_x_forwarded_for\":
> \"10.12.199.134\",\"http_referrer\":
> \"https://chel.wifi.domru.ru/index.php?request_uri=http://captive.apple.com/hotspot-detect.html\;,
> \"upstream_response_time\": \"\",\"upstream_header_time\":
> \"\",\"upstream_connect_time\": \"\",\"http_user_agent\": \"Mozilla/5.0
> (Macintosh; Intel Mac OS X 10_14) AppleWebKit/605.1.15 (KHTML, like
> Gecko)\",\"x-project\": \"\",\"cluster\": \"1\",\"container_id\":
> \"\",\"citydomain\": \"\" }", 765, 0, NULL, 0) = -1 ECONNREFUSED (Connection
> refused)
Да, так бывает.
Цитируя "Programming UNIX Sockets in C - Frequently Asked
Questions", AKA Socket FAQ
(http://web.deu.edu.tr/doc/soket/#faq57):
: If the target machine discards the message because there is no
: process reading on the requested port number, it sends an ICMP
: message to your machine which will cause the next system call on
: the socket to return ECONNREFUSED. Since delivery of ICMP messages
: is not guarenteed you may not recieve this notification on the
: first transaction.
То есть ошибка ожидаема, и она означает, что на предыдущее
сообщение в syslog прилетело ICMP-сообщение в ответ.
Если вы не в курсе, что у вас часть UDP-сообщений где-то
реджектится - это повод разобраться, где и почему. Если в курсе -
это лишнее напоминание, что оно так.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Prevent direct access to files but allow download from site
j94305 Wrote:
---
> 2. You use a session context: whenever a page validly serving a link
> to a certain content is delivered, you set a cookie. Retrievals to
> files require the cookie to be present. No cookie, no access.
>
> Cheers,
> --j.
Hi, the second option seem interesting and relatively "simple" solutions,
but I am having some problems.
I put a pdf file in the domain.com/assets/file/test.pdf directory
I created a cookie when a user logs in.
document.cookie = "user_logged = 1";
On Nginx I created this rule:
location ~ ^/assets/file/ {
if ($http_cookie ~* "user_logged") {
allow all;
}
root /path/to/root;
}
I also tried this:
location ~ ^/assets/file/ {
if ($cookie_user_logged = "1") {
allow all;
}
root /path/to/root;
}
But it seems not to work correctly, the user either manages to download from
the direct link https://domain.com/assets/file/test.pdf from the browser,
and from the a href tag of the site, or fails from either side.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,287297,287315#msg-287315
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Re: UDP Connection refused
On Thu, Mar 12, 2020 at 02:32:23AM -0400, inkognito0609 wrote: > При отправке логов через syslog (udp) проскакивают ошибки 111 Connection > refused, что непонятно при отправке логов по udp, так как этот протокол не > подразумевает установки соединения в принципе. Читайте man 7 udp. ECONNREFUSED может быть вызвана отображением на уровень сокетов ответов icmp[port-unreach], icmp[admin-prohib] на предыдущие пакеты от этого сокета, а также блокировкой исходящих udp локальным пакетным фильтром. Конкретика зависит от реализации (может отличаться для разных ОС). К nginx это отношения не имеет. -- Eugene Berdnikov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Prevent direct access to files but allow download from site
Thanks for all this information, I try to study and apply what you told me. Posted at Nginx Forum: https://forum.nginx.org/read.php?2,287297,287313#msg-287313 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Prevent direct access to files but allow download from site
Hi, thank you for your help, but as I said, being an expert, I have difficulty understanding certain things. If you know how to solve my problem, a small example would help me. Posted at Nginx Forum: https://forum.nginx.org/read.php?2,287297,287312#msg-287312 ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: HTTP/1.1 400 Bad Request при рестриме аудио потока
попробуйте дебажную сборку nginx и error.log в режиме debug чт, 12 мар. 2020 г. в 14:33, grey : > Ошибки как таковой нету, есть не верный код возврата заголовка. > > Делаю именно GET, получаю ответ: > > HTTP/1.1 400 Bad Request > Server: nginx > Date: Thu, 12 Mar 2020 09:31:23 GMT > Content-Type: text/html > Content-Length: 248 > Connection: close > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,287264,287310#msg-287310 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: HTTP/1.1 400 Bad Request при рестриме аудио потока
Ошибки как таковой нету, есть не верный код возврата заголовка. Делаю именно GET, получаю ответ: HTTP/1.1 400 Bad Request Server: nginx Date: Thu, 12 Mar 2020 09:31:23 GMT Content-Type: text/html Content-Length: 248 Connection: close Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287264,287310#msg-287310 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Блокирование доступа с custom error page
то что нужно, работает великолепно! Очень признателен за помощь! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287292,287309#msg-287309 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
UDP Connection refused
При отправке логов через syslog (udp) проскакивают ошибки 111 Connection
refused, что непонятно при отправке логов по udp, так как этот протокол не
подразумевает установки соединения в принципе.
strace дает следующее:
30752 sendto(64, "<190>Mar 12 09:45:59 balancer nginx: { \"timestamp\":
\"2020-03-12T09:45:59+05:00\", \"remote_addr\": \"91.144.134.5\",
\"body_bytes_sent\": 18686, \"request_time\": 0.000, \"response_status\":
200, \"request\": \"GET /themes/default/images/flags.png HTTP/1.0\",
\"request_method\": \"GET\", \"host\":
\"chel.wifi.example.ru\",\"upstream_cache_status\":
\"HIT\",\"upstream_addr\": \"\",\"http_x_forwarded_for\":
\"10.12.199.134\",\"http_referrer\":
\"https://chel.wifi.domru.ru/index.php?request_uri=http://captive.apple.com/hotspot-detect.html\;,
\"upstream_response_time\": \"\",\"upstream_header_time\":
\"\",\"upstream_connect_time\": \"\",\"http_user_agent\": \"Mozilla/5.0
(Macintosh; Intel Mac OS X 10_14) AppleWebKit/605.1.15 (KHTML, like
Gecko)\",\"x-project\": \"\",\"cluster\": \"1\",\"container_id\":
\"\",\"citydomain\": \"\" }", 765, 0, NULL, 0) = -1 ECONNREFUSED (Connection
refused)
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,287308,287308#msg-287308
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
