Haproxy as reverse proxy problem in ssl pathtrough - ssl

I setup haproxy as reverse proxy in our organization . we want when the client request for some web site like lenovo or oracle or etc. …the request must be passed through our reverse proxy server .(because our client set our dns server and i defined reverse proxy’s ip as those such domain in our dns server). i using SSL passthrough .but i have some problem in this case.
1- some time haproxy doesnt work fine and have problem to load right certificate.for example when i want to see www.amazon.com haproxy load wrong certificate(SSL_ERROR_BAD_CERT_DOMAIN) so firefox prevent to load website. in this case i have www.intel.com in haproxy config so haproxy getting confused and load www.amazon.com with intel certificate website.
2-I want all sub domain of website like *.oracle.com or *.lenovo.com passed through our reverse proxy so we don’t need to register sub domains of website one by one in haproxy server .
i try with -reg or matching pattern method but all of them need to final destination.
3- some time redirection cant work properly and we facing http to https redirection error .(some time client enter lenovo.com or intel.com (means http requesting).to over come this problem i defined http frontend and redirect all request to https except one hypothetical request by acl . but my issue some time appear.

This is simple done by req_ssl_sni and writing simple acl to forward request but attention to just write single forntend and backend ,because multi frontend and backend cause a confusing in haproxy.

Related

CloudFlare workers fetch HTTPS works on workers.dev subdomain but not on own subdomain getting 525 error

I have a simple worker that just does a fetch against an HTTPS endpoint somewhere else.
The code is literally just:
return await fetch('https://something.com/someResource')
When I test locally (wrangler dev) and even publish to a workers subdomain this works fine. When I curl https://foo.bar.workers.dev/myEndpoint I get the same response as https://something.com/someResource.
However I want to run this from my own domain (managed through cloudflare) so the worker also has a route of foo.mydomain.com/* and a AAAA record to 100:: for foo as per CloudFlare docs. The DNS works fine the URL is reachable, but when I try to hit https://foo.mydomain.com/myEndpoint CloudFlare's worker logs show that the fetch behind the scenes fails with a 525 error (SSL Handshake fail).
Things I've tried based on some CloudFlare forum posts:
Add a page rule foo.mydomain.com/* -> SSL Mode: full since my overall SSL settings are set to flexible.
Set the host header in the fetch to the origin domain ( fetch(url, {headers: {'Host': 'something.com'}})
FYI, I don't control the origin server as it's an external API I work with.
How come the same request works from local and *.workers.dev but not my own domain?
Your page rule is not taking effect. The page rule is for foo.mydomain.com/*, but it has to match the subrequest URL, which in this case is https://something.com/someResource, which doesn't match. It doesn't matter that the original worker request matched -- what matters, in this case, is whether the subrequest URL matched.
Unfortunately, you cannot create a page rule that matches a domain other than your own.
Instead, what you'll need to do is reverse things. Set your SSL mode to "full" by default, but then use page rules to set it to "flexible" for your own domain.
(Note: The "SSL Handshake fail" error itself is actually a known bug in Workers, that happens when you try to talk to a host outside your zone using HTTPS but you have "flexbile" SSL set. We do not use flexible SSL when talking to domains other than your own, but there's a bug that causes the request to fail instead of just using full SSL as it should.)

GCP load balancing ("internal" traffic over HTTPS)

I have a GCP instance group with 2 instances. Both are up and running. I want to configure a load balancer (HTTPS) to manage the traffic.
I've set up a forwarding rule with the HTTP-protocol and a certificate managed by google. This all works, but only when the traffic between the load balancer and the backend (the instances) is plain HTTP.
Steps I did so far
I create a template and this template is just a normal N1 series machine. I checked the boxes to create firewall rules for allowing http and https traffic.
I create a firewall rule named "allow-ports". This firewall rule targets all instances in the network, has a 0.0.0.0/0 IP-range and allow port tcp = 80, 443. How I see this, this firewall rule should open both the http (80) and https (443) port.
I create an instance group with port mapping. "http-port" = 80, "https-port" = 443. I use the template I just created.
When the instance group is created, I check if this is running. With SSH, I get access to the instances and install apache (sudo apt-get install -y apache2) on the both. When navigating to their external IP's in the browser, I see them both.
I create a HTTP(S) load balancer, with the option "From internet to my VMs". For backend configuration, I add a backend service with my instance group, protocol HTTP, named port "http-port". For frontend configuration, I set up the HTTPS protocol, create an IPv4 IP address, create a google-managed ssl certificate, and I'm done. I also added health checks btw.
Now... these steps work (after a few minutes). With the cloud DNS, I have set up a domain name which points to the IP address of the load balancer. When going to , I see the apache page.
What doesn't work?
When I change the backend configuration to HTTPS (and named port "https-port"), I get a 502 server error. So it seems to me that there is some connection, but there is an error. Could this be an apache error?
I have spent a whole day, creating and recreating instance groups, firewall rules, load balancers, ... but nothing seems to work. I'm surely missing something, probably something dumb, but I have no clue what it could be.
What do I want to achieve?
I do not only want a secure (HTTPS) connection between the client and my load balancer, I also want a secure connection between the load balancer and the backend service (the instance group). Because GCP offers the option to use the HTTPS protocol when creating a backend service, I feel that this could be done.
To be honest: I'm reading some articles about the fact that the internal traffic is secured, so a HTTPS connection is not necessary. But that doesn't matter to me, I really want to know how this works!
EDIT
I'm using the correct VPC (default). I also edited the firewall rule from 0.0.0.0/0 to 130.211.0.0/22 and 35.191.0.0/16 (see: https://cloud.google.com/compute/docs/tutorials/globally-autoscaling-a-web-service-on-compute-engine?hl=nl#configure_the_load_balancer).
In addition to my previous comment. I followed your steps at my test project to find out the cause of your issue. I installed the same configuration and checked it with HTTP at the back-end. As it was expected, I found no errors. After that, I installed SSL certificates to the back-end and to the load balancer. Then I switched my back-end, load balancer and health checks to HTTPS and disabled HTTP at the back-end. At this point, I found no errors also.
So, I decided to get 502 error in my test configuration in some way. I switched my health check at the load balancer to HTTP. A few minutes later I tried to reach my test service again and got 502 error. When I switched back my health check to HTTPS 502 error gone away.
During this test, I didn't change firewall rules, but allowed HTTP and HTTPS traffic in my instance template and I used default network.

Do I need any additional configuration for express to use https?

If I got a signed certificate from letsencrypt.org and baked it into my nginx web server, does that mean I still need to configure express.js to use https?
As in nginx serves me a secure webpage, and I see the https lock on the top left, but do I need to do any extra configuration with express at all??
No node/express does not need to handle ssl - you can have a separate service for node/express and have nginx act as a reverse proxy and do ssl offloading.
Under this configuration, browsers will first hit your nginx web server over HTTPS, nginx will handle the ssl decryption and forward the decrypted HTTP request to your node process.
Your node process doesn't have to know HTTPS is happening at all.
Digital Ocean really has the best docs for setting this up on linux with systemd.
The first link is a clear tutorial on setting up a an nginx reverse proxy to node
The second link shows configuring SSL in nginx w/ a simple reverse proxy (in this specific example - its not a node server on the receiving end but the concepts are the same) to accomplish the SSL termination

Connection Partially Encrypted in Firefox :SSL

I have uploaded my SSL certificates to IAM purchased from Comodo and evrything looks fine in chrome and opera. But mozilla is giving an error: "Connection Partially encrypted". I am not able gauge why this is happening.
Link : https://www.advisorcircuit.com/
Please tell me what is the possible culprit for this?
and also i want to know , how can i redirect my users to HTTPS ebven if they type http as even if i type http the website loads and opens.
I am using AWS t2.medium instance. So is there any configuration i need to do in my console??
Redirection:
You have a few options:
Block HTTP traffic, only allow HTTPS on the Security Group level ( Not the nicest solution.
Use an Elastic Load balancer, Listening only on HTTPS port. ( Same as above)
The webserver ( most of them like Tomcat, IIS, etc) supports a redirection, so it sends back "HTTP/1.1 301 Moved Permanently", then the client browser does the call again on HTTPS.
If you use Elastic Load Balancer with SSL termination ( which is a good practice, less load on your server, easier setup of the SSL Certificate). Then all your traffic inside your VPC goes on port 80. In this case you need to setup your webserver to redirect differently. Instead of the incoming port, the trigger for the redirection should be the based on the "X-Forwarded-Proto" header value, which is the original protocol what the client is using.
For production environment the last setup is an AWS Best practice. ( Of course there are also other solutions)
Your site is running Apache/2.2.29. You can redirect your virtual host traffic from 80->443 in Apache itself. That way if someone goes to http://www.yourdomain.com then get redirected to https://www.yourdomain.com
ServerFault has an post explaining how to use Apache mod_rewrite to accomplish this
https://serverfault.com/a/554183/280448
Also you need to adjust the SSL cipher suites that your site accepts. Your ELB has an option to change cipher suites and you can deselect some there. The two you definitely want deselected are RC4 and SSL3.
Here's the full report if you want to make more changes
https://www.ssllabs.com/ssltest/analyze.html?d=www.advisorcircuit.com&s=52.7.154.196&latest

Remove /web from PLEX URL

How do I remove the need to type /web on the end of my PLEX media server to access from outside my network? I have a no-ip.com account and set up a static domain name to point to a static ip. But that doesn't help much, because I still need to type in the /web to access my media server. I am using windows 7. I have set up a owncloud server before and removed the need to type /owncloud in the httpd.conf file. But I can't find it for the plex server. I read somewhere to set up a page that will redirect to /web, but I don't know how to do that. Thanks for help!
You can remove both the port (in case you are already not forwarding it from port 80 to Plex's port) and the need for the /web at end using redirection rules.
Here is a good example of how to do just that (this solution uses Apache):
http://matt.coneybeare.me/how-to-map-plex-media-server-to-your-home-domain/
EDIT: Small correction, that site I linked is not using redirection rules, it is using a reverse proxy.
With a redirection rule if you type: myPlexServer.com, you'll be redirected to myPlexServer.com:32400/web (as in, the address on your browser will actually be re-written to that, same as clicking on a link that takes you to another page).
With a reverse proxy, you effectively have a man in the middle, the reverse proxy server itself. You send requests to myPlexServer.com (Apache server in this case), it receives those requests and the proxy forwards them to myPlexServer.com:32400/web (PMS Server). The PMS server sends the reply to the Apache server and the Apache server sends the reply back to you. As far as PMS is concerned, the client requesting info is the Apache server, in fact it doesn't even know about you talking to the Apache server.