Congiuring varnish with multiple domains+ssl Support - ssl

I am currently been involved in implementation of varnish with loadbalancer as back-end which shall forward traffic accordingly to multiple web server.
I am trying to achieve:
Public Traffic -> haproxy/DNS -> [Varnish (x2) / nginx(ssl) ] -> Loadbalancer -> Web server(x4)
I am able to configure Varnish , nginx as ssl/443 terminator for one domain.
(i.e if i point dns to varnish eth and access webserver serves the page)
varnish config
backend loadbalancer { .host = "xxx.xxx.xxx.xxx"; .port = "80" }
backend loadbalancer_ssl { .host = "xxx.xxx.xxx.xxx"; .port = "443"; }
sub vcl_recv {
# Set the director to cycle between web servers.
if (server.port == 443) {
set req.backend = loadbalancer_ssl;
}
else {
set req.backend = loadbalancer;
}
}
# And other vcl rules for security and other.
Nginx Config
location / {
# Pass the request on to Varnish.
proxy_pass http://127.0.0.1;
proxy_http_version 1.1;
#SSL certificate and config
=> How would i achieve configuring varnish as dns entry Point with ssl termination for multiple domains?
=> Is it possible to somehow configure varnish to accept all connections and bypass ssl to web server directly? (so that i don't have to worry about multiple interface for ssl support)
=> Or any standard approach to achieve with 443 terminator?
Note: why i am trying to achieve this: To create multiple layer for security and using existing hardware devices.
Already in place:
All server has (multiple interface for ssl using lightty).
Load balancer -> Hardware -> which will balance load between those web server.
Any experts sharing there view would be great.

I have decided to go with nginx as ssl terminator and achieving my question answers as below. I decided to update this, if anyone finds it useful.
From my above query:
How would i achieve configuring varnish as dns entry Point with ssl termination for multiple domains?
=> How it works is we need to have socket listening for https/ either nginx/pound/or anything else that can read ssl.
(which i was not quite convinced previously is to use this point as ssl terminator however i think i am fine as beyond that level now i have planned to make it internal zone.
=> Is it possible to somehow configure varnish to accept all connections and bypass ssl to webserver directly? (so that i dont have to worry about multiple interface for ssl support)
One can achieve this either with multiple interface (if you have multiple domains).
or, same interface if you are dealing with subdomains.
Or, you can create one secure page for all ssl required pages (depends upon trade-off)
=> Or any standard approach to achieve with 443 terminator?
I decided to go with nginx to use those feature that nginx provides (interms of security layer).

Related

Reverse Proxing with HA Proxy

I'm trying to use HA Proxy as Reverse Proxy for LoadBalancing and Health-Check Purpose mainly.
Therefore, I have to address different domains with several subdomains and/or subpaths.
https://sub1.example1.com
https://subsub.sub1.example1.com
https://sub2.example2.com
https://example3.com/path1
Unfortunately, I'm not finding an opportunity to define a frontend for each Domain to bind the SSL-cert-file to.
Additionally, I'm not pretty sure whether HAProxy provides something like ProxyPass to handle the "path"-Stuff.
Can somebody please give me an example how to solve this with HAProxy?
Thanks
You can have a single frontend that handles all of the subdomains and use ACL's to route to different backends. You define your certificates on the bind line and multiple can be specified. I'm not quite sure what you mean by the "ProxyPass to handle the "path"-Stuff" but if you provide more detail I can help. HAProxy is extremely flexible.
provides something like ProxyPass to handle the "path"-Stuff.
Example of how you might handle the multiple subdomains:
defaults
mode http
frontend fe_main
bind :80
# define all certificates
bind :443 ssl crt /etc/haproxy/ssl/sub1.example.com.pem crt /etc/haproxy/ssl/sub2.example.com.pem crt /etc/haproxy/ssl/example3.com.pem
use_backend be_sub1 if { req.hdr(host) sub1.example.com }
use_backend be_sub2 if { req.hdr(host) sub2.example.com }
default_backend be_catchall
backend be_sub1
server app1 192.168.1.10:80 check
backend be_sub2
server app1 10.2.0.4:443 check ssl verify none
backend be_catchall
server catchall1 10.3.2.5:80 check

HTTPS between frontend and backend

I am developing a website using Vue.js, and I have implemented HTTPS in my webpage.
Right now the website is basically static, no communications between itself and the backend server.
If I wanted to add features for instance, login, via a backend server which is on the same machine as the frontend server.
Do I need to get another SSL certificate to make to communication between frontend and backend through HTTPS?
Is there any way to make the SSL certificate work on the whole domain?
You have a few options here
Proxy API requests to your backend service
This means that your HTTP server (eg NGINX) uses your built Vue app (eg the dist folder contents) as its document root and creates a reverse proxy for requests to your API service. For example, say you have a backend service running on port 3000
location /api {
proxy_pass http://localhost:3000/
}
Then your Vue app can make requests to /api/whatever.
During development, you can mirror this using the devServer.proxy setting in vue.config.js
module.exports = {
devServer: {
proxy: {
"^/api": "http://localhost:3000/"
}
}
}
Use a wildcard certificate and run your backend service at a sub-domain, eg
Frontend - https://example.com
Backend - https://api.example.com
Just get two SSL certificates for your two domains. They're free after all
Keep in mind, options #2 and #3 will need you to enable CORS support whereas that is not required for option #1.

HTTPS proxy with caddy

I am working with a Golang app and Caddy as the HTTP server. The golang app rejects every http connection, it only can be used over HTTPS. This app is a kind of API/service that is consumed by other apps. As, it requires HTTPS I installed Caddy so I can take advantage of the automatic SSL certificate and use proxy to switch between the ports.
The application is running in the port 9000, so, the consumers will only writte mysite.com and caddy should be in charge of redirect that petitions to the port 9000 but maintaining the HTTPS. The configuration in caddy for the site is:
mysite.com {
proxy / :9000 {
max_fails 1
}
log logfile
}
Nevertheless, it seems like when the proxy is made the HTTPS is lost. I checked the logs for the application (no the logs of caddy) and I get this:
http: TLS handshake error from xxx.xxx.xxx.xxx:xxxx: tls: oversized record received with length 21536
So, based in this error, to me looks like the HTTP proxy made by caddy is losing the HTTPS. What can I do?
From the caddy docs
to is the destination endpoint to proxy to. At least one is required,
but multiple may be specified. If a scheme (http/https) is not
specified, http is used. Unix sockets may also be used by prefixing
"unix:".
So maybe it is sending http requests to the proxied https endpoint.
Does
mysite.com {
proxy / https://localhost:9000 {
max_fails 1
}
log logfile
}
fix it?
If that is the case, you may not strictly need your app on :9000 to listen https. It may simplify your deployment or cert management to just have it listen http and have caddy manage all the certs.

Difference HTTP Redirect vs Reverse Proxy in NGINX

I'm having some difficulty in understanding the difference between reverse proxy (i.e. using proxy_pass directive with a given upstream server) and a 301 permanent redirect. How are they similar/different?
Reverse Proxy
upstream backend {
server backend1.example.com weight=5;
server backend2.example.com:8080;
}
server {
location / {
proxy_pass http://backend;
}
}
HHTP Redirect
Apache Example: http://www.inmotionhosting.com/support/website/htaccess/redirect-without-changing-url
NGINX example:
server {
listen 80;
server_name domain1.com;
return 301 $scheme://domain2.com$request_uri;
}
Hence, it seems that both approaches have no difference from an end-user perspective. I want to ensure efficient bandwidth usage, while utilizing SSL. Currently, the app server uses its own self-signed SSL certificate with Nginx. What is the recommended approach for redirecting users from a website hosted by a standard web hosting company (hostgator, godaddy, etc.) to a separate server app server?
With a redirect the server tells the client to look elsewhere for the resource. The client will be aware of this new location. The new location must be reachable from the client.
A reverse proxy instead forwards the request of the client to some other location itself and sends the response from this location back to the client. This means that the client is not aware of the new location and that the new location does not need to be directly reachable by the client.

NGINX - Add http headers and forward messages to Apache server?

I am trying to build a fleet management software at the likes of google maps or bing maps and I need the GPS devices to send messages to the server and have the server store them (mySQL).
I have a Apache server (let's say "myserver.com") which only processes/accepts http requests for security reasons. The problem with this configuration is that it does not processes the gps messages because the device does not include http headers on its messages by default.
So, I was thinking on putting a nginx server in between them and make the gps send its messages to the nginx server, which then adds http headers to the original message and forwards it to the Apache server.
I tried finding any good tutorials online but so far haven't been able to find a good one.
Anyone can help me? Thank you.
I'm a bit confused on what you mean by 'gps messages'. Is it just http traffic without the appropriate header? If so, you want to use the proxy module. You can find current documentation for it at here.
Here is an example:
http {
upstream backend_apache {
server apache_server1_ip:80;
server apache_server2_ip:80;
}
server {
listen 80;
server_name myserver.com;
location / {
proxy_set_header Host $host;
proxy_pass http://backend_apache;
}
}
}