What am I trying to do: create multiple TLS servers that listen on same port. Each TLS server has different set of certificates and should only allow certain set of clients. For example, first TLS server should allow Client X and not Client Y. Second TLS server should allow Client Y and not Client X.
Issue that I am having is Client Y and X both connect only with first TLS server. TLS certificates used are different for each client are signed by different TLS servers, but they tend to connect only to first TLS server.
Would appreciate any thoughts on this issue.
That setup just isn't going to work. The cluster API lets multiple workers share a port, but there is no intelligence about which worker gets allocated to which requests. If there isn't a lot of load, it's entirely possible that only one worker will receive all the requests.
I'm not sure what you're trying to do, but if you think about it, this kind of setup doesn't make sense. If you have different certificates, then there is just no way for a TLS session to be setup successfully. It would be like trying to bind multiple SSL certificates to the same IP.
The only way I could see this working is if each of those different certificates corresponds with a different hostname. In that case, you could try using SNI as documented at http://nodejs.org/docs/latest/api/tls.html#tls.connect. However, each worker process would still need to access the same pool of certificates.
Related
Is it possible to deploy a node.js app on Cloud Foundry that listens for HTTPS requests on port 443?
Well, the good news is that you don't have to do that. The Cloud Foundry platform takes care of it for you.
All you need to do is push your app and assign a route to the app. Your platform operations team will already have everything set up so that traffic for both HTTP and HTTPS routes through to your application.
The only thing you probably want to do in your application is to look at the x-forwarded-proto (should be http or https) or x-forwarded-port (80 or 443) header. You can use this to determine if the client's connection was over HTTP or HTTPS, and if it's HTTP then issue a redirect to ask the client to connect over HTTPS (this force clients to use HTTPS).
You can read more about this in the docs at the following link:
https://docs.cloudfoundry.org/adminguide/securing-traffic.html
Having said all that, if you really want to control the certs for some reason you can do that. You would need to map a TCP route to your application. This will enable TCP traffic to flow directly to your application. Then you can configure your application as an HTTPS endpoint on the mapped TCP route and port.
Some notes about this:
You will almost certainly end up with some high numbered port, not 443. The platform will have a pool of available ports, which is configured by your operations team, and you are limited to using only those ports.
The platform and buildpacks will not help set up TLS, you will need to handle that all on your own. The good news is that it should work exactly the same as if your app were running on a VM or your local laptop.
You will need to create your own TLS certs and push them with the application. You can probably use Let's Encrypt, but you may need to obtain these through your employer, if you work for a large company.
I have created a NodeJS application using http/2 following this example:
Note: this application uses self-signed certificate until now.
We deployed it on GKE, and it is working until now.
Here is how this simple architecture looks like:
Now, we want to start using real certificate, and don`t know where is the right place to put it.
Should we put it in pod (overriding self-signed certificate)?
Should we add a proxy on the top of this architecture to put the certificate in?
In GKE you can use a ingress object to routing external HTTP(S) traffic to your applications in your cluster. With this you have 3 options:
Google-managed certificates
Self-managed certificates shared with GCP
Self-managed certificates as Secret resources
Check this guide for the ingress load balancing
The Client's SSL session terminates at the LB level, the self-signed certificates being used are just to encrypt communication between the LB and the Pods. So if you want the client to use your new valid certificate it needs to be at the LB level.
On a side note, having your application servers communicate with the LoadBalancer over HTTP will give you a performance boost. Since the LB is acting as a reverse proxy anyway.
You can read this article about LoadBalancing it's written by the author of HAProxy
I want to make a secure hyperledger fabric infrastructure to manage all nodes based on physical devices.
The front-end user application writes to HL. It asks for a random node and if it answers application sends request and payload.
What is the best way to guarantee private communication between off-chain frontend app and hyperledger?
I have already created private domain secured by SSL certificate for every node but this method doesn’t sound scalable - what if we have 10k nodes? Is there a better approach?
If your intent is to communicate directly with the Peer, the endpoint's already able to be secured with TLS.
However, under an ideal situation, your web app, would communicate with your back-end server (lets say NodeJS Express server). Your Express server would be TLS secured and your web app would communicate via https. Your Express server would then use the Fabric Node SDK to communicate with your network, which is also TLS secured communication. You're not configuring anything more extensively than you would have while building a TLS-secured web server in the first place.
To your last point, who owns the 10k nodes? An organization would only be expected to own a few nodes, and your few nodes would be handling your transactions, you wouldn't be submitting to other organizations peers. You owning so many peer's in a network would defeat the purpose of Fabric's consensus, allowing you to compromise the network by always being able to provide policy quorum.
I'm developing a security system. It has a proxy server acting like a ssl termination using Nginx which will forwards all tcp/ip connections from clients to other third-party systems.
The client-proxy connections must be authenticated and securely encrypted by ssl.
And my problems is:
Each client is a computer which installed Windows 7 OS or higher. It has been installed with some third-party applications which cannot be interfered. For the better user experience, all clients' tcp/ip outbound requests from any applications must be transparently "converted" into (or "wrapped" in) ssl requests before coming to proxy server. And my first idea is to develop a network driver to access these requests using windows api, namely WFP(Windows Filtering Platform). I have read its online documentation but it's not easy to understand. Can you have to find some projects like this or tell me which sections in the documentation need to be focused? Thank you in advance!
Your issue is a bit unclear but here are my thoughts:
You want to have full encryption between the End User Client to the App Service.
Current:
Client --(443: TLS)--> NGINX --(Clear; Port 80)--> App Service
(Terminate TLS)
Change:
Client --(443: TLS)--> NGINX --(TLS; Port 443)--> App Proxy -(Plain; 80)-> App Service
(Terminate TLS) (Nginx with self-signed Cert)
The change is to add an additional Nginx server on the app server to provide the last layer of TLS between the load balancer and the App Service.
If your App service has the capability to serve SSL connections directly that's even better as you can just configure that in place of running an additional Nginx server on the app host. (If you wanted you could run apache or any other web server that supports proxy/load balancing capabilities)
If you are worried about the App Service port, it won't make a difference, the idea is that the App Proxy (being Nginx or the likes) will handle the encryption on a different port to then pass via localhost to the App Service (in plain text).
Additional Resources:
Can Nginx do TCP load balance with SSL termination?
https://serverfault.com/questions/978922/nginx-proxy-pass-to-https
https://reinout.vanrees.org/weblog/2017/05/02/https-behind-proxy.html
https://nginx.org/en/docs/http/ngx_http_ssl_module.html
It's my understanding that if I connect to a windows Azure web role with HTTPS that there is an initial handshake to exchange certificates and then another connection is made to get data.
Can someone explain to me is the connection persisted or if the user needs another page a few minutes later would there me another exchange of handshakes? How about if the WebRole was serving data from the Web API, would that be the same?
It depends on a client capabilities but in terms of modern web browsers I wouldn't be so worried about single connection(handshake) per request:
HTTP 1.1 - Persistent connection
Modern browsers use HTTP 1.1 by default which according to RFC 2616 makes connection persistent by default. Another important aspect of HTTP 1.1 is that it forces support of HTTP pipelining which means that multiple requests to the same endpoint will be send in a batch and response will be also received in a batch (on the same connection). Browsers generally have a limit of connections per server (Chrome - 2 connections by default) and reuse connections.
Azure: It looks like Azure will drop connection if idle for 4 minutes
Handshake
Every first connection requires full handshake but subsequent can reuse session ticket (ID), but this depends on a client. Microsoft introduced TLS session resumption some time ago - What's New in TLS/SSL (Schannel SSP) in Windows Server and Windows. As long as you have only one host serving HTTPS connection it should resume sessions, according to this blog post:
There’s also a warning about session resumption. This is due to the
Azure load balancer and non-sticky sessions. If you run a single
instance in your cloud service, session resumption will turn green
since all connections will hit the same instance.
It should not make any difference if it's a WebAPI or Website. You can always test it using SSLyze.