[PATCH 0 of 1] allow to use engine keyform for server private key
Me and my company will be happy to see any method to load private key from engine with any parameter names. What shall I do? Change parameters to format= and engine=? Try to use STORE_get_certificate(), STORE_get_private_key() before using ENGINE_load_private_key()? Do you have any instruction which can help me to check the patch? To do not break compilation with mail module again etc. Tatiana Kondakova mailto: kondak...@cryptopro.ru ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: [PATCH] Added so_freebind and so_transparent to the listen directive
- Opprinnelig melding -
On Mar 27, 2014, at 22:14 , Trygve Vea wrote:
- Opprinnelig melding -
Hello!
Hello!
On Thu, Mar 27, 2014 at 04:34:37PM +0100, Trygve Vea wrote:
# HG changeset patch
# User Trygve Vea trygve@redpill-linpro.com
# Date 1395933815 -3600
# Thu Mar 27 16:23:35 2014 +0100
# Node ID 13e6a37c2f57443b0d5dd0abce8d9d4ab00e31e3
# Parent 2411d4b5be2ca690a5a00a1d8ad96ff69a00317f
Added so_freebind and so_transparent to the listen directive
This solves a Linux/IPv6-specific problem.
To be able to listen to an IPv6 address that is not yet available on the
host,
one need to use the IP_FREEBIND and IP_TRANSPARENT socket options.
The use case in question is for a failover setup with several service-
addresses in a IPv6-only environment.
IPv4 has a sysctl available (ip_nonlocal_bind), which is not available
for
IPv6 - thus making these patches necessary.
Isn't bind on INADDR_ANY/IN6ADDR_ANY works for you?
It is expected to work fine and allows to accept connections on
all addresses currently available on a host without any
non-portable tricks.
- Opprinnelig melding -
IPv4 has a sysctl available (ip_nonlocal_bind), which is not available
for
IPv6 - thus making these patches necessary.
Isn't bind on INADDR_ANY/IN6ADDR_ANY works for you?
It is expected to work fine and allows to accept connections on
all addresses currently available on a host without any
non-portable tricks.
That would be sufficient for HTTP - and my preferred option, since we can
handle routing after the end-user have provided us with the Host-header,
and thus know where to send the user.
However, with SSL enabled - while we have end users that still do not
support SNI
(http://en.wikipedia.org/wiki/Server_Name_Indication#Client_side), and
using multiple SSL-certificates, for multiple applications - we will need
to bind each certificate to its own dedicated service address. From here,
we can do routing / forward the connections further down the stack.
This can be handled with following configuration:
server {
listen *:443 ssl;
listen any.non.existent.ip1:443 ssl;
ssl_certificate ...
...
}
server {
listen any.non.existent.ip2:443 ssl;
ssl_certificate ...
...
}
nginx will bind only to *:443 and then will call getsockname() to get real
local address.
Hm, are you sure?
I haven't been able to succeed - as this was what I was initially attempting to
do.
server {
listen *:443 ssl;
listen [2a02:c0:209::F1]:443 ssl;
nginx: [emerg] bind() to [2a02:c0:209::f1]:443 failed (99: Cannot assign
requested address)
Are there any additional requirements to make this work?
--
Trygve Vea
Redpill Linpro AS
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: [PATCH] Added so_freebind and so_transparent to the listen directive
- Opprinnelig melding -
On Mar 28, 2014, at 14:45 , Trygve Vea wrote:
- Opprinnelig melding -
On Mar 27, 2014, at 22:14 , Trygve Vea wrote:
- Opprinnelig melding -
Hello!
Hello!
On Thu, Mar 27, 2014 at 04:34:37PM +0100, Trygve Vea wrote:
# HG changeset patch
# User Trygve Vea trygve@redpill-linpro.com
# Date 1395933815 -3600
# Thu Mar 27 16:23:35 2014 +0100
# Node ID 13e6a37c2f57443b0d5dd0abce8d9d4ab00e31e3
# Parent 2411d4b5be2ca690a5a00a1d8ad96ff69a00317f
Added so_freebind and so_transparent to the listen directive
This solves a Linux/IPv6-specific problem.
To be able to listen to an IPv6 address that is not yet available on
the
host,
one need to use the IP_FREEBIND and IP_TRANSPARENT socket options.
The use case in question is for a failover setup with several service-
addresses in a IPv6-only environment.
IPv4 has a sysctl available (ip_nonlocal_bind), which is not available
for
IPv6 - thus making these patches necessary.
Isn't bind on INADDR_ANY/IN6ADDR_ANY works for you?
It is expected to work fine and allows to accept connections on
all addresses currently available on a host without any
non-portable tricks.
- Opprinnelig melding -
IPv4 has a sysctl available (ip_nonlocal_bind), which is not available
for
IPv6 - thus making these patches necessary.
Isn't bind on INADDR_ANY/IN6ADDR_ANY works for you?
It is expected to work fine and allows to accept connections on
all addresses currently available on a host without any
non-portable tricks.
That would be sufficient for HTTP - and my preferred option, since we can
handle routing after the end-user have provided us with the Host-header,
and thus know where to send the user.
However, with SSL enabled - while we have end users that still do not
support SNI
(http://en.wikipedia.org/wiki/Server_Name_Indication#Client_side), and
using multiple SSL-certificates, for multiple applications - we will need
to bind each certificate to its own dedicated service address. From
here,
we can do routing / forward the connections further down the stack.
This can be handled with following configuration:
server {
listen *:443 ssl;
listen any.non.existent.ip1:443 ssl;
ssl_certificate ...
...
}
server {
listen any.non.existent.ip2:443 ssl;
ssl_certificate ...
...
}
nginx will bind only to *:443 and then will call getsockname() to get real
local address.
Hm, are you sure?
I haven't been able to succeed - as this was what I was initially
attempting to do.
server {
listen *:443 ssl;
listen [2a02:c0:209::F1]:443 ssl;
nginx: [emerg] bind() to [2a02:c0:209::f1]:443 failed (99: Cannot assign
requested address)
Are there any additional requirements to make this work?
You need to add also:
listen [::]:443 ssl;
Ah, thank you.
This seems to do the trick.
I spoke with a colleague about this, and he pointed out that this does not
cover the use case where you do NOT want to listen on *:443 (which the patch
does cover). However, that is not something I need.
Feel free to both ignore and merge the patch; if you would like to merge it
with some modifications, feel free to tell me what to change - and I'd be happy
to make them.
Regards
--
Trygve Vea
Redpill Linpro AS
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: [PATCH] Added nonlocal to the listen directive
Hello! On Fri, Mar 28, 2014 at 10:45:53AM +0100, Trygve Vea wrote: # HG changeset patch # User Trygve Vea t...@redpill-linpro.com # Date 139540 -3600 # Fri Mar 28 10:45:40 2014 +0100 # Node ID 16eacd8609c8362e9dd729c743ed7a869c2993fe # Parent 2411d4b5be2ca690a5a00a1d8ad96ff69a00317f Added nonlocal to the listen directive The nonlocal option is used to set the needed socket options to be able to bind to an address not necessarily owned by the host. This patch currently implements this for Linux = 2.4 IPv4/IPv6. The problem we solve by doing this, is in an environment where the following conditions are met: * HTTPS with multiple certificates, and a client base that are unable to use SNI - thus having the need to tie specific certificates to specific ip/ports. * Setting the ip_nonlocal_bind-sysctl is not an option (for example for Linux IPv6) * Used in a failover-setup, where the service IP-addresses are moved around by a daemon like linux-ha or keepalived. As already explained, the patch is not needed for the use case claimed. Just a bind on INADDR_ANY/IN6ADDR_ANY will do the trick. -- Maxim Dounin http://nginx.org/ ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
[nginx] SPDY: detect premature closing of stream.
details: http://hg.nginx.org/nginx/rev/a24f88eff684
branches:
changeset: 5628:a24f88eff684
user: Valentin Bartenev vb...@nginx.com
date: Fri Mar 28 20:22:57 2014 +0400
description:
SPDY: detect premature closing of stream.
The SPDY/3.1 specification requires that the server must respond with
a 400 Bad request error if the sum of the data frame payload lengths
does not equal the size of the Content-Length header.
This also fixes zero size buf in output alert, that might be triggered
if client sends a greater than zero Content-Length header and closes
stream using the FIN flag with an empty request body.
diffstat:
src/http/ngx_http_spdy.c | 17 +
1 files changed, 13 insertions(+), 4 deletions(-)
diffs (34 lines):
diff -r d74889fbf06d -r a24f88eff684 src/http/ngx_http_spdy.c
--- a/src/http/ngx_http_spdy.c Fri Mar 28 20:05:07 2014 +0400
+++ b/src/http/ngx_http_spdy.c Fri Mar 28 20:22:57 2014 +0400
@@ -1609,6 +1609,19 @@ ngx_http_spdy_state_read_data(ngx_http_s
stream-in_closed = 1;
+if (r-headers_in.content_length_n 0) {
+r-headers_in.content_length_n = rb-rest;
+
+} else if (r-headers_in.content_length_n != rb-rest) {
+ngx_log_error(NGX_LOG_INFO, r-connection-log, 0,
+ client prematurely closed stream:
+ %O of %O bytes of request body received,
+ rb-rest, r-headers_in.content_length_n);
+
+stream-skip_data = NGX_SPDY_DATA_ERROR;
+goto error;
+}
+
if (tf) {
ngx_memzero(buf, sizeof(ngx_buf_t));
@@ -1619,10 +1632,6 @@ ngx_http_spdy_state_read_data(ngx_http_s
rb-buf = NULL;
}
-if (r-headers_in.content_length_n 0) {
-r-headers_in.content_length_n = rb-rest;
-}
-
if (rb-post_handler) {
r-read_event_handler = ngx_http_block_reading;
rb-post_handler(r);
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: proxy_pass behavior
On Fri, Mar 28, 2014 at 8:20 AM, Maxim Dounin mdou...@mdounin.ru wrote: Hello! On Thu, Mar 27, 2014 at 08:18:48PM -0400, Jim Popovitch wrote: On Thu, Mar 27, 2014 at 1:50 PM, Jim Popovitch jim...@gmail.com wrote: On Thu, Mar 27, 2014 at 1:27 PM, Maxim Dounin mdou...@mdounin.ru wrote: Hello! On Thu, Mar 27, 2014 at 01:12:18PM -0400, Jim Popovitch wrote: On Thu, Mar 27, 2014 at 12:59 PM, Maxim Dounin mdou...@mdounin.ru wrote: Hello! On Thu, Mar 27, 2014 at 12:29:03PM -0400, Jim Popovitch wrote: Should proxy_pass retry ipv4 if ipv6 fails? Currently (1.5.12), it does not, and there is no way to force proxy_pass to always use ipv4. In no particular order: - The proxy_next_upstream is expected to retry by default. Yes, that works if the host name has 2 or more A OR 2 or more records. proxy_next_upstream does not appear to transition to the next protocol (i.e. from ipv4 to ipv6) It doesn't care about address family. As long as connect() to one address fails, it will try next one. I will have to do some more tests, but so far 1.5.12 (debian wheezy) does not appear to try the next one if the next one is a different protocol family. So here is what happens: Nginx 1.5.12 on Debian Wheezy 7.4 ~$ host www.acadiau.ca www.acadiau.ca has address 131.162.201.18 www.acadiau.ca has IPv6 address 2620:21:c000:c8:0:aca:d1a:18 ~$ grep proxy_pass /etc/nginx/sites-available/proxy proxy_pass https://www.acadiau.ca; When an IPv6 client connects to the proxy, proxy_pass logs the error as 2014/03/27 21:28:28 [alert] 24862#0: *158336 connect() failed (13: Permission denied) while connecting to upstream, client: 2604:180::82c6:fe9, server: proxy-service.tld, request: GET / HTTP/1.1, upstream: https://[2620:21:c000:c8:0:aca:d1a:18]:443/;, host: proxy-service.tld It will next try the ipv4 addr and succeed, however the reason for the So the original claim that it does not appear to try the next one is withdrawn, right? 99% of it is, I did see it fail once. Permission denied error appears to be the format of the URL (raw ipv6 addr, not hostname). Why is it using the ipv6 addr instead of the hostname? No, it's an error from connect() syscall, returned by your OS for some reason (likely because there is no route available, or due to a firewall rule). The address is one of the upstream server nginx uses at the moment - it's is vital for logging if there are more than one address. I agree it's vital for logging so that you can see which address failed. It's just not clear that the destination server was presented with the hostname (SNI) because the Permission denied message seems to idicate connect() was successful but the resource was denied (due to permissions). But I can live with bad OS level error messages as long as the behavior is accurate. Thank you Maxim, -Jim P. ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: proxy_pass behavior
Hello! On Fri, Mar 28, 2014 at 01:56:59PM -0400, Jim Popovitch wrote: On Fri, Mar 28, 2014 at 8:20 AM, Maxim Dounin mdou...@mdounin.ru wrote: Hello! On Thu, Mar 27, 2014 at 08:18:48PM -0400, Jim Popovitch wrote: On Thu, Mar 27, 2014 at 1:50 PM, Jim Popovitch jim...@gmail.com wrote: On Thu, Mar 27, 2014 at 1:27 PM, Maxim Dounin mdou...@mdounin.ru wrote: Hello! On Thu, Mar 27, 2014 at 01:12:18PM -0400, Jim Popovitch wrote: On Thu, Mar 27, 2014 at 12:59 PM, Maxim Dounin mdou...@mdounin.ru wrote: Hello! On Thu, Mar 27, 2014 at 12:29:03PM -0400, Jim Popovitch wrote: Should proxy_pass retry ipv4 if ipv6 fails? Currently (1.5.12), it does not, and there is no way to force proxy_pass to always use ipv4. In no particular order: - The proxy_next_upstream is expected to retry by default. Yes, that works if the host name has 2 or more A OR 2 or more records. proxy_next_upstream does not appear to transition to the next protocol (i.e. from ipv4 to ipv6) It doesn't care about address family. As long as connect() to one address fails, it will try next one. I will have to do some more tests, but so far 1.5.12 (debian wheezy) does not appear to try the next one if the next one is a different protocol family. So here is what happens: Nginx 1.5.12 on Debian Wheezy 7.4 ~$ host www.acadiau.ca www.acadiau.ca has address 131.162.201.18 www.acadiau.ca has IPv6 address 2620:21:c000:c8:0:aca:d1a:18 ~$ grep proxy_pass /etc/nginx/sites-available/proxy proxy_pass https://www.acadiau.ca; When an IPv6 client connects to the proxy, proxy_pass logs the error as 2014/03/27 21:28:28 [alert] 24862#0: *158336 connect() failed (13: Permission denied) while connecting to upstream, client: 2604:180::82c6:fe9, server: proxy-service.tld, request: GET / HTTP/1.1, upstream: https://[2620:21:c000:c8:0:aca:d1a:18]:443/;, host: proxy-service.tld It will next try the ipv4 addr and succeed, however the reason for the So the original claim that it does not appear to try the next one is withdrawn, right? 99% of it is, I did see it fail once. Permission denied error appears to be the format of the URL (raw ipv6 addr, not hostname). Why is it using the ipv6 addr instead of the hostname? No, it's an error from connect() syscall, returned by your OS for some reason (likely because there is no route available, or due to a firewall rule). The address is one of the upstream server nginx uses at the moment - it's is vital for logging if there are more than one address. I agree it's vital for logging so that you can see which address failed. It's just not clear that the destination server was presented with the hostname (SNI) because the Permission denied message seems to idicate connect() was successful but the resource was denied (due to permissions). But I can live with bad OS level error messages as long as the behavior is accurate. The message in question indicates that connect() syscall failed (note connect() failed), and errno was set to EPERM (note 13: Permission denied in brackets). As previosly said, EPERM was seen to be returend from connect() due to either firewall rules in place that deny the connection, or due to lack of route to the destination address. -- Maxim Dounin http://nginx.org/ ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
