We are facing 502 error at our IIS web server, which used to work fine up to recently.
We had to change our reverse proxy machine: went from Ubuntu 18.04 to Ubuntu 22.04, and in this proccess the NGINX version changed from 1.21.3 to 1.18.0.
Right now, with NGINX 1.18.0, the 502 occurs. At NGINX log we see:
peer closed connection in SSL handshake (104: Unknown error) while SSL handshaking to upstream
The connection is being served with TLS v1.3, as informed by Mozilla Firefox 101.0.1 (64-bits).
We're working with a Windows Server 2012, which only accepts TLS up to v1.2 (https://learn.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl--schannel-ssp-).
At upstream log there is nothing. If we go back to older NGINX the connection goes without problem (TLS is v1.2). So the problem seems to be at NGINX. We suspect it to be from TLS v1.3 (as per link provided), but couldn't manage to solve this.
We tried updating "nginx.conf" ssl_protocols TLSv1 TLSv1.1; but it didn't work, we still get TLS v1.3. We also tried to update NGINX (apt update and no version change) and some settings (proxy_ssl_name and proxy_ssl_server_name and proxy_pass) with no success either.
Any ideas on how to solve this?
Any ideas on how to solve this?
We're working with a Windows Server 2012, which only accepts TLS up to v1.2
Yup, you identified the problem right there.
Win8 won't support TLS1.3.
Yet you have a business need to communicate over TLS1.3.
Sounds like you want to swap some portion of your deployed software stack.
You could revert to your old Bionic Beaver,
but you're likely better off sticking with Jammy.
Time has moved on.
You want your stack components to keep up with a changing Internet.
We understood that the reason for the 502 error was NGINX didn't accept a private certificate while proxying the connection (our IIS had a private certificate - locally generated).
This case was closed by removing SSL from internal segment (between nginx and IIS), while keeping SSL v1.3 from the user/client to NGINX segment.
Related
I have various nginx server and recently I note that by default response these servers responses using the HTTP/2 version of protocol.
I don't have configured the http2 parameter in nginx.conf.
Is this the right behavior?
No, that is not the default.
If you observe HTTP2 despite not configuring it in NGINX, you likely have a CDN in front of it, e.g. Cloudflare.
We followed gudelines in the below link in order to secure the undertow http server (same steps have been followed for fuse 7.2 and we have the same issue).
https://access.redhat.com/documentation/en-us/red_hat_fuse/7.3/html/apache_karaf_security_guide/webconsole
When we start our server then we see entry "Starting undertow https listener on 0.0.0.0:8943". But when we try to visit link https://localhost:8943/hawtio then we get in chrome below error.
This site can’t provide a secure connection localhost uses an unsupported protocol.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Unsupported protocol
The client and server don't support a common SSL protocol version or cipher suite.
Our certificate has been tested with the the undertow server of the wildfy and it works without any problem, so we believe that we have followed correctly the guidelines.
Also our rest services can exhange https messages without any problem.
In the below links you can find 2 configuration files.
https://quickfileshare.org/Yfx/org.ops4j.pax.web.cfg
https://quickfileshare.org/Yfy/undertow.xml
Have we overlooked any configuration step?
You have:
<w:engine
enabled-cipher-suites="TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
enabled-protocols="TLSv1 TLSv1.1 TLSv1.2 SSLv3.0" />
please verify if Chrome supports the above strong cipher suites.
guys!
I build a chat application based on WebSocket. As backend I use PHP and nginx as a proxy for WebSocket connection.
Searching about PHP libs for WS gave me Ratchet. This tools support WAMP protocol. Something about it: http://wamp-proto.org/why/
Well, I've decided to use this protocol - it seems useful. I tuned nginx for proxy WebSocket connections in standard way. And for common using WebSocket at frontend/backend - all is ok.
But, if I start use WAMP at backend and try to use autobahn.js for WAMP at frontend, I catch 426 No Sec-WebSocket-Protocols requested supported as response every time. At PHP I see that connection from nginx is not receiving. So, as I understood, nginx doesn't process connection with WAMP subprotocol in right way.
So, I don't understand, should I use nginx as a proxy for WAMP? WAMP is just a subprotocol for WebSocket, but doesn't work for me.
Does anybody knows where problem is?
Seems like Nginx isn't forwarding the WebSocket subprotocol announced by the client to the backend WAMP router.
Try adding this to your Nginx conf:
proxy_set_header Sec-WebSocket-Protocol $http_sec_websocket_protocol
See: https://stackoverflow.com/a/36506746/884770
We are using nginx for https traffic offloading, proxying to a locally installed jasperserver (5.2) running on port 8080.
internet ---(https/443)---> nginx ---(http/8080)---> tomcat/jasperserver
When accessing the jasperserver directly on its port everything is fine. When accessing the service through nginx some functionalities are broken (e.g. editing a user in the jasperserver UI) and the jasperserver log has entries like this:
CSRFGuard: potential cross-site request forgery (CSRF) attack thwarted (user:%user%, ip:%remote_ip%, uri:%request_uri%, error:%exception_message%)
After some debugging we found the cause for this:
In its standard configuration nginx is not forwarding request headers that contain underscores in their name. Jasperserver (and the OWASP framework) however default to using underscores for transmitting the csrf token (JASPER_CSRF_TOKEN and OWASP_CSRFTOKEN respectively).
Solution is to either:
nginx: allow underscores in headers
server {
...
underscores_in_headers on;
jasperserver: change token configuration name in jasperserver-pro/WEB-INF/esapi/Owasp.CsrfGuard.properties
Also see here:
header variables go missing in production
http://wiki.nginx.org/HttpCoreModule#underscores_in_headers
Answered it myself - hopefully this is of some use to others,too
I had this issue with Jasperserver 5.5 AWS AMI
More specific:
/var/lib/tomcat7/webapps/jasperserver-pro/WEB-INF/esapi/Owasp.CsrfGuard.properties
Change:
org.owasp.csrfguard.TokenName=JASPER_CSRF_TOKEN
org.owasp.csrfguard.SessionKey=JASPER_CSRF_SESSION_KEY
To:
org.owasp.csrfguard.TokenName=JASPERCSRFTOKEN
org.owasp.csrfguard.SessionKey=JASPERCSRFSESSIONKEY
My version of Jasperserver looked slightly different, the CSRFguard files are located in jasperserver/WEB-INF/csrf
I edited the jrs.csrfguard.properties file.
I'm getting this error from /var/log/messages on my FreeBSD box. I'm using nginx and spawn-fcgi with memcache and apc modules enabled.
upstream prematurely closed connection while reading response header from upstream,
client HTTP/1.1", upstream: "fastcgi://unix:/tmp/fcgi.sock:", host:
I've had a similar error with unicorn + nginx.
The end result was that the unicorn was timing out due to a firewall misconfiguration, dieing off and leaving NGINX clueless as to what to do (nginx would then throw a 503).
Once the port was open my issue was resolved.
I've also seen this happen with an API call that takes a long time (longer than my 30s unicorn timeout). I ended up shipping it off to a background job so the unicorn didn't timeout.
I had a similar issue with Nginx timing out with a RoR app when using an EC2 + Amazon RDS database instance.
The issue was resolved by editing my security group for the RDS instance to allow the EC2's IP over port 5432. Just edit the security group's rules to add a custom rule for the port you are communicating to the RDS instance over, and whitelist the EC2 server's private IP address. Worked instantly after that!
It was related to the version of PHP. I have used latest version of nginx and slightly old version of PHP. The issue has been fixed by updating PHP to latest version.