We are in the process of moving a 2-way SSL enabled web service to Amazon Web Service cloud. Since AWS doesn't support 2-way SSL, I was thinking if it is possible to decouple the 2-way SSL process: Terminate the SSL at the Elastic load balancer but validate the client cert in the CXF application using custom code?
I don't prefer to make our clients to change their implementations from the current 2-way SSL setup.
You could do this using TCP load balancing and terminating the SSL connection at your server instead. Somewhat more info here under "Using Back-End Server Authentication with Elastic Load Balancing":
http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html
Related
I am trying to convert an Istio service mesh running on k8s from http to https but stumbled upon many problems. I don't really understand what are all the steps required to do that.
As I know, there are 2 kinds of traffic that requires TLS in a mesh:
between internal services: scramming through Istio docs let me know that Istio will somehow automatically configure mTLS between services so all of them will communicate securely without any extra configuration. However, I still don't understand deeply how they implement this mTLS. How does it differ from normal TLS and what is mTLS role in the other kind of traffic (client outside to service inside)?
from client outside to a service inside: this is where I don't know what to do. I know that in order for a service to have TLS it needs TLS certificate by a trusted CA. However, as the outer client will not talk directly to the service inside but only through the Istio ingress gateway. Do I need to provide cert for every service or only the ingress gateway? All of my services are now exposing port 80 for HTTP. Do I need to convert all of them to port 443 and HTTPS or just the ingress gateway is enough?
Regarding the certificates, if I just use self-signing certs for now, can I just create cert and key with openssl and create secrets from it (maybe sync between namespaces with kubed), then all services use the same cert and key? Everywhere suggests me to use cert-manager. However, I don't know if it is worth the effort?
I would be really thankful if anyone can explain with some illustrations.
In general, if you need a good explanation of the issues related to Istio (also with pictures), I recommend that you check the documentation. You can find around 540 topics related to TLS in Istio.
Istio is a very well documented service. Here you can find more information about Understanding TLS Configuration. You can also find good article about Mutual TLS Migration.
However I still don't understand deeply how they implement this mTLS, how does it differ from normal TLS and what is mTLS role in the other kind of traffic (client outside to service inside).
Mutual TLS, or mTLS for short, is a method for mutual authentication. mTLS ensures that the parties at each end of a network connection are who they claim to be by verifying that they both have the correct private key. The information within their respective TLS certificates provides additional verification. You can read more about it here. Additionally yo can also see page about HTTP Traffic (mTLS is required for this case).
All of my services are now exposing port 80 for HTTP. Do I need to convert all of them to port 443 and HTTPS or just the ingress gateway is enough?
It is possible to create Ingress Gateway without TLS Termination:
The Securing Gateways with HTTPS task describes how to configure HTTPS ingress access to an HTTP service. This example describes how to configure HTTPS ingress access to an HTTPS service, i.e., configure an ingress gateway to perform SNI passthrough, instead of TLS termination on incoming requests.
EDIT (added more explanation and documentation links):
Service mesh uses a proxy to intercept all your network traffic, allowing a broad set of application-aware features based on configuration you set.
Istio securely provisions strong identities to every workload with X.509 certificates. Istio agents, running alongside each Envoy proxy, work together with istiod to automate key and certificate rotation at scale. The following diagram shows the identity provisioning flow.
Peer authentication: used for service-to-service authentication to verify the client making the connection. Istio offers mutual TLS as a full stack solution for transport authentication, which can be enabled without requiring service code changes.
Peer authentication modes that are supported: Permissive, Strict, and Disable.
In order to answer this question:
All of my services are now exposing port 80 for HTTP. Do I need to convert all of them to port 443 and HTTPS or just the ingress gateway is enough?
fully we could have informed the customer that using Istio Gateway can expose services from Istio service mesh to the outside using plain HTTP, with TLS termination or in PASSTHROUGH TLS mode. Incoming TLS termination could be improved (using TLS certificate approved by a trusted CA or using cert-manger with Istio Gateway). You can read more about this topic here.
I am new to the whole container-orchestration world and was wondering if the microservices I deploy with Kubernetes need a secure connection too or if the Ingress TLS termination is enough.
For example I have an NGINX microservice with currently no SSL/TLS setup whatsoever. When users communicate with this microservice, the connection is encrypted because I set up an Ingress with TLS termination.
Are there any security drawbacks in such a scenario? I find it very hard to find proper literature regarding this topic.
It definitely will work. I mean ingress with TLS termination. It depends on security requirements of your project. If you ok with un-encripted traffic inside your cluster, you can go with it.
Though, if you will be running micro-services in production, the best practice for secure service-to-service communication is Istio mesh with mutual TLS authentication
What it does is injects sidecar proxy (envoy) for each of your services
One of my teammate just enabled SSL on one of the service that we are using and I had to install a Certificate that he gave me to each of the client machines who intend to consume that service. Now, I am not very well-versed when it comes to SSL security and that raised a question in my mind that
WHENEVER we create a SSl enabled service, do we have to hand out certificate to all the clients
Is there any kind of configuration using which we create an SSL enabled service without having to hand out certificate to all the clients?
IF it is possible then how secured that service be than the service which requires each client to install certificate on the machine?
Also, is there any easy to understand article on WCF SSL security?
Que : WHENEVER we create a SSl enabled service, do we have to hand out certificate to all the clients
Ans : No. For SSL enabled service one do not need to handout certificates to clients.
SSL certificate on server (in this case service) side gives confidence to clients that they are talking to legitimate server.
Clients needs certificates only in case of when service needs its clients to prove their identity using client certificate. With client certificate server (service) gets confidence that its sending data to legitimate clients.
Que : Is there any kind of configuration using which we create an SSL enabled service without having to hand out certificate to all the clients?
Ans : Certainly there is way with which you can make service enabled without requiring client certificate. Check SSL Settings option for website where service is hosted.
Que: IF it is possible then how secured that service be than the service which requires each client to install certificate on the machine?
Ans : Obliviously using SSL certificate doesn't stop any clients from consuming it. Any client who knows service endpoint can consume it. Client certificate is one way to authenticate clients. Only those clients who has valid client certificate will be able to consume service.
Que: Also, is there any easy to understand article on WCF SSL security?
Ans : Check out this link : https://msdn.microsoft.com/en-us/library/ff650862.aspx Its WCF regarding security as whole and not just SSL security.
I have client server application which using WCF service with Transport security mode and NetTCP binding. I heard like Transport security is best for local intranet, not for internet. Now my scenario is I need to access WCF service over internet (from another country), but dont want to use Message security (cause it need to purchase and install certificate on server and each client). I want to use Transport security and also encrypt my data, so no one can hack it from internet.
So please someone guide me how can I encrypt my data with Transport security ?
Thanks
Transport is just SSL, so after the initial setup on the host and client sides, there's really nothing special to it. SSL will encrypt all the bytes starting at byte 0 and only the host that distributed the public key portion of the SSL cert will be able to decrypt the transmission since it and only it should have the private key part of the certificate.
SSL does present some potential problems if you have a load balancer or proxy fronting your service - i.e. if the proxy or LB server didn't begin the SSL transmission, it won't know what to do with the inbound message. But SSL encryption can be offloaded to a LB or proxy, so there are ways around that.
Here's a link to a stackoverflow question about SSL over WCF
Enable SSL for my WCF service
I cannot find authoritative information about how WSS interacts with HTTPS proxies and load balancers.
I have a load balancer that handles the SSL (SSL off-loading), and two web servers that contains my web applications and handle the requests in plain HTTP. Therefore, the customers issue HTTPS requests, but my web servers get HTTP requests, since the load balancer takes care of the SSL certificates handling.
I am developing now an application that will expose WebSockets and SSL is required. But I have no clear idea about what will happen when the load balancer gets a secure HTTPS handshake for WSS.
Will it just relay the request as normal handshake to the web server?
WebSockets use a "Upgrade:WebSocket" HTTP header that is only valid for the first hop (as there is also "Connection:Upgrade", will this be a problem?
Cheers.
loadbalancers can normally deal with websockets - also including ssl offloading shouldn't be an issue - BUT you have to configure the LB to take care about HTTP and not only to take care about balancing the traffic based on Layer 3 infos - therefore, you have to ensure that the LB has to take care about the session state.
i don't know what LB you are using - but e.g. with F5 LBs you just have to assign a http profile to loadbalance websocket based apps.
If you want to do ssl offloading additionally - just assign an ssl client profile to your virtual server.
http://support.f5.com/kb/en-us/solutions/public/14000/700/sol14754.html
I would have thought SSL-terminating LBs handle WebSockets as well, but I had to realize I was mistaken, once I tried. So the answer for F5 LBs, as of January 2013, is: It won't work. The gist of the answer I was given over at serverfault:
As of December of 2012, BIG-IP doesn't support SSL offload of WebSocket traffic.