I'm looking for example of implementation of 2-way SSL authentication / mutual authentication example in LoopBack API framework(featured by StrongLoop API Platform)
I need to connect with SOAP API with mutual authentication.
I found these examples
https://github.com/strongloop/loopback-example-ssl and https://github.com/strongloop/loopback-example-connector/tree/soap ,
but I guess it isn't enough.
Node module loopback-ssl which can accelerate enabling SSL with loopback.
- SID
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'm studying for this exam identity & access management. The question is what is the difference between one way authentication and mutual authentication? Our prof says mutual is TLS but if I search on the internet TLS is also one way authentication... So I'm a bit confused
I have implemented both one-way and mutual SSL in Applications hosted on Java and Webmethods technology. In One-way authentication, there is a server certificate that the client receives, trusts it (registers it) and sends back a secret along with the server certificate. Hence, a successful SSL Handshake occurs.
In mutual SSL, in addition to trusting the Server Certificate, the Client also provides it's own certificate to the Server. Hence, a mutual trust is maintained between the Server and the Client after which the secrets are transferred.
TLS is a protocol for guaranteeing security in the exchange of information. It is used in particular on the HTTP protocol. The TLS protocol allows both unilateral authentication and bilateral authentication (or mutual authentication). Recently I published on GitHub a project that implements a system of Mutual Authentication based on Apache 2.4 and the TLS 1.2 protocol. https://github.com/amusarra/docker-apache-ssl-tls-mutual-authentication/
The attached image shows the call to a REST service in mutual authentication
I try to understand why Istio have the mTLS feature? It enables mutual TLS authentication between all the services in a cluster via automatically issued certificates.
Mandatory TLS authentication is a benefit only as long as they are services outside Istio, but when Istio is enabled globally in Kubernetes, this is not the case - then every service gets certificate automatically, so can connect to any other.
Maybe TLS is used as identity provider, required by Istio authorization rules, like asked in yet unanswered Does istio authorization have effect if mtls is not used for istio authentication?? But why Istio does not just use Kubernetes service accounts as identity provider. This is even mentioned in documentation.
Also, even with TLS for identity, why encrypting traffic (TLS can be used without encryption)? I am assuming here that the container is not able to spoof IP address.
I have an application installed in tomcat which currently I am running on http.
Also I have used AWS API gateway to expose my application .
I want to implement mutual auth between aws api gateway and my api which we have created .
Is there any document which I can refer.
Also is it possible to implement mutual authentication with AWS API gateway and my api.
This is definitely possible by installing an SSL certificate in Tomcat and using the Client Certificate feature of API Gateway. See http://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started-client-side-ssl-authentication.html
The API Gateway server must use a certificate the AWS ACM issues.
The Gateway itself uses another AWS-generated certificate to authenticate with your backend.
Is it possible to use mutual authentication (client SSL certificates) with WSO2 ESB? (I'm not talking about WS-Security.)
I see that it is possible to add custom keystores to the ESB but I could not find any information on how to specify what client key to use when connecting to a specific backend.
Yes. You can enable mutual authentication for ESB proxy service. Here you want to do small configuration to enable mutual authentication for all proxy service . You can edit axis2.xml file and change following property to "require"
<parameter name="SSLVerifyClient">require</parameter>
More details you can find here. However, if you are enabling mutual authentication for given set of proxy services, There is some more to do.. More details you can find here. There was an issue with older release in ESB. therefore you need some patches to install. but with 4.7.0 and 4.8.0 (next release). there have been fixed.
It is actually quite simple to set up mutual SSL authentication between the ESB and a back-end server. This requires configuration of the back-end server as well. Because the ESB serves as a 'client' when initiating a connection with the back-end, the back-end server is responsible for requesting the 'mutual' SSL instead of one-way SSL. See this nice mutual SSL article for reference [1].
In order to successfully use mutual SSL with a back-end server,
Load the back-end server's public certificate into the default
truststore, which is located in: repository/resources/security/client-truststore.jks (That's it!
That's the only change necessary on the WSO2 ESB side.)
Load the public certificate from the WSO2 keystore into the back-end server's
keystore.
Configure the back-end server to request mutual SSL.
If you're using a CA certificate instead of the default self-signed certificate, skip step 2.
Cheers,
Colin
[1] http://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication