Quantcast
Channel: Nginx Forum - Other discussion
Viewing all 972 articles
Browse latest View live

Re: issue with Oracle HTTP Server 10.1.3

$
0
0
Could be, the idea was once a cipher is forced it either works or you get some other error pointing to the real problem.

However you need to translate that cipher value into what nginx configuration understands;

See also
https://blog.qualys.com/ssllabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy
http://security.stackexchange.com/questions/87326/what-is-the-impact-of-removing-tls-rsa-with-rc4-128-sha-from-my-servers-cipher

SSL handshake failure

$
0
0
Hello.

I am having a problem with establishing SSL connection between an Apache proxy and Nginx, connection fails during handshake with Alert 21 message.
Other clients have no problem connecting to Nginx, only proxy does.
I have tried to make sense of the tcpdump output but would appreciate your help in finding out why Nginx rejects the connection.

Nginx info:

nginx version: nginx/1.8.1
built with OpenSSL 1.0.1f 6 Jan 2014


Client Hello:

Secure Sockets Layer
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 91
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 87
Version: TLS 1.2 (0x0303)
Random
GMT Unix Time: Jul 28, 1975 11:49:59.000000000 CET
Random Bytes: 5803affbe1677147d908839b735d75f93cd7ba62030d8e8a...
Session ID Length: 0
Cipher Suites Length: 28
Cipher Suites (14 suites)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
Cipher Suite: TLS_FALLBACK_SCSV (0x5600)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Compression Methods Length: 1
Compression Methods (1 method)
Compression Method: null (0)
Extensions Length: 18
Extension: elliptic_curves
Type: elliptic_curves (0x000a)
Length: 8
Elliptic Curves Length: 6
Elliptic curves (3 curves)
Elliptic curve: secp256r1 (0x0017)
Elliptic curve: secp384r1 (0x0018)
Elliptic curve: secp521r1 (0x0019)
Extension: ec_point_formats
Type: ec_point_formats (0x000b)
Length: 2
EC point formats Length: 1
Elliptic curves point formats (1)



Server response:

Secure Sockets Layer
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Length: 2
Alert Message
Level: Fatal (2)
Description: Handshake Failure (40)


I have tested the issue with a default nginx configuration and with a specific set of ciphers but with no success.
Server is on a private network with no access to Internet and I control only the server with nginx.

Any help would be appreciated.

Re: SSL handshake failure

$
0
0
Also, the nginx log excerpt:

2016/04/30 14:36:55 [info] 25632#0: *1 SSL_do_handshake() failed (SSL: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher) while SSL handshaking, client: x.x.x.x, server: y.y.y.y:443

Re: SSL handshake failure

$
0
0
Maybe this http://stackoverflow.com/questions/33806038/nginx-error-no-shared-cipher-but-there-are

Re: SSL handshake failure

$
0
0
Thanks for the suggestion.
Unfortunately, the issue persists.

According to tcpdump output and RFC (if I interpreted it correctly), the issue occurs because the client and the server cannot agree about communication algorithms, conversation does not even reach the certificate exchange stage.

"
https://tools.ietf.org/html/rfc5246#section-7.4.1.2

In the event that a client requests additional functionality using extensions, and this functionality is not supplied by the server, the client MAY abort the handshake. A server MUST accept ClientHello messages both with and without the extensions field, and (as for all other messages) it MUST check that the amount of data in the message precisely matches one of these formats; if not, then it MUST send a fatal "decode_error" alert.
"

"
https://tools.ietf.org/html/rfc5246#section-7.4.1.3

The server will send this message in response to a ClientHello message when it was able to find an acceptable set of algorithms. If it cannot find such a match, it will respond with a handshake failure alert.
"

Excerpt from a successful ServerHello on the same server (localhost request):

TLSv1.2 Record Layer: Handshake Protocol: Server Hello
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 94
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 90
Version: TLS 1.2 (0x0303)
Random
GMT Unix Time: Jan 29, 2038 13:50:53.000000000 CET
Random Bytes: a5c11896aed0b85c783524c7921518e9c6f6cb4f1f5ed28e...
Session ID Length: 32
Session ID: c949118cdcc40d69afd8675a7c6471b61b041a71d4fd3e8f...
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Compression Method: null (0)
Extensions Length: 18
Extension: renegotiation_info
Type: renegotiation_info (0xff01)
Length: 1
Renegotiation Info extension
Extension: ec_point_formats
Type: ec_point_formats (0x000b)
Length: 4
EC point formats Length: 3
Elliptic curves point formats (3)
Extension: Heartbeat
Type: Heartbeat (0x000f)
Length: 1
Mode: Peer allowed to send requests (1)


In regards to requirements sent by the proxy, openssl does not show an issue:

# openssl ciphers | grep -q ECDHE-RSA-AES256-GCM-SHA384; echo $?
0

# openssl ecparam -list_curves | grep -e secp256r1 -e secp384r1 -e secp521r1
secp384r1 : NIST/SECG curve over a 384 bit prime field
secp521r1 : NIST/SECG curve over a 521 bit prime field


Maybe I am overthinking this and there is a simple reason for failure in communication between the two servers but I just do not see it.

reverse proxy

$
0
0
I need to achieve below test case using nginx:

www.example.com/api/ should redirect to ABC.com/api, while www.example.com/api/site/login should redirect to XYZ.com/api/site/login

But in the browser, user should only see www.example.com/api.... (and not the redirected URL).

Please let me know how this can be achieved.

Re: issue with Oracle HTTP Server 10.1.3

$
0
0
NGINX wants to have a cipher, that matches the output of "openssl ciphers", right?

With "openssl ciphers -V" (which outputs the binary value of the Cipher, too), I found that TLS_RSA_WITH_RC4_128_SHA (0x0005) equals

0x00,0x05 - RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1

Put this into nginx.conf on both upstream and downstream, restarted, and retried.

I see that all server hellos confirm the TLS_RSA_WITH_RC4_128_SHA cipher, still the communication will abort shortly after
"Alert Message: Encrypted Alert", again with "SSL_read() failed (SSL: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number) while reading upstream" in the nginx log file.

By now I'm quite pessimistic that I'll ever find a solution for this setup!

Re: issue with Oracle HTTP Server 10.1.3

$
0
0
You can try the mailing list at https://forum.nginx.org/list.php?2
or the openssl forum on google groups, a detailed wireshark capture might be helpful for some to figure out what is going on.

Override HTTP-Method

$
0
0
Hello,

is it possible to override the $request_method?
I have the problem that a well known client tries to place a request with method "0". This has its roots in a bug that would take long time to fix.
Is it possible to do something like

if ($request_method = 0){
set $request_method POST;
}

I did a quick try on this but i qot an error that the variable "$request_method" is duplicate.

Kind Regards,

Benjamin

Re: Override HTTP-Method

$
0
0
Maybe this is helpful http://stackoverflow.com/questions/15362038/nginx-change-request-from-put-to-post

Re: Override HTTP-Method

$
0
0
Thank you for your reply.

I would like to try this but i have no idea how to do this without php.
My setup comes without php. It is a simple reverse proxy.
Is it possible to pass this to the proxy_pass-connection?

Re: Override HTTP-Method

$
0
0
Look at the 'map' example on that site, standard nginx stuff.

Re: Override HTTP-Method

$
0
0
Hello,

i tried the following config:

add_header XX-method: $request_method;
add_header bla-method: $bla_method;

map $request_method $bla_method {
default $request_method;
0 POST;
BLA POST;
}

server {
listen 80 default;
server_name localhost;
location / {
proxy_method $bla_method;
proxy_pass http://<URL>:8080;
}
}

But it does not work. The problem persists.

Kind Regards,

Benjamin

Re: Override HTTP-Method

$
0
0
Try with Curl, check what it reports back including the headers and check the logfiles to see what Curl reports can be found in the logs.

Re: Override HTTP-Method

$
0
0
Thats what I did.

The Error-Log says:
3 client sent invalid method while reading client request line, client: 127.0.0.1, server: localhost, request: "0 /"

And Curl:
HTTP/1.1 400 Bad Request
Server: nginx/1.9.15
Date: Wed, 04 May 2016 09:38:30 GMT
Content-Type: text/html
Content-Length: 173
Connection: close

<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx/1.9.15</center>
</body>
</html>


It is like the mapping is not respected.

Re: Override HTTP-Method

$
0
0
Correct, a 400 is handled internally before any other handler,
see also https://forum.nginx.org/read.php?2,158557,158557#msg-158557

Re: Override HTTP-Method

$
0
0
Is there any possibility to change the method before the 400 happens?

Re: Override HTTP-Method

$
0
0
Maybe with Lua, otherwise you need to hack the code to not handle a 400, a grep for 400 and a grep for some other code which works as desired may give you an idea what to do.

nginx does not waste time with broken clients hence the 400 handling, it may cost you performance when you actually handle it as a lot of basic attacks result in 400's (ea. a DROP).

The 192.168.1.161 page isn’t working

$
0
0
I new to nginx and can't figure out what the problem is. Any help would be appreciated.

The 192.168.1.161 page isn’t working

192.168.1.161 is currently unable to handle this request.
500

My error log is :

2016/05/06 17:06:54 [error] 29248#102195: *1 FastCGI sent in stderr: "PHP message: PHP Warning: require_once(app/libraries/autoload.php): failed to open stream: No such file or directory in /usr/local/www/nZEDb/autoloader.php on line 39
PHP message: PHP Fatal error: require_once(): Failed opening required 'app/libraries/autoload.php' (include_path='.:/usr/local/share/pear') in /usr/local/www/nZEDb/autoloader.php on line 39" while reading response header from upstream, client: 192.168.1.6, server: 192$

Re: '/usr/bin/git: not found'

$
0
0
ln -s /usr/local/bin/git /usr/bin/git
fixes the problem
Viewing all 972 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>