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
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.
There is a server with WCF client, which periodically initiates communications over internet with many WCF services installed on our clients computers. WCF services and WCF clients are hosted in Windows Service, current binding is basicHttpBinding.
Communication has to be over https with mutual authentication. Company ordered SSL certificate but it is not clear if this certificate can be installed on clients computers (because WCF service is there) without exposing a private key. Binding can be basicHttpBinding or wcHttpBinding with transport or message security but using certificates.
Is it possible to install service-side certificate on client computers and client-side certificate on our server? Should this architecture be re-worked so WCF service is on our server or it is possible to secure somehow this current solution?
Each computer involved requires it's own certificate. A certificate value for authentication relies on the uniqueness of the private key. The private key never leaves the host machine, and the certificate can be used to authenticate said machine (because is the only one in the world that posses that private key). As soon as you start distributing copies of a private key, security is pretty much compromised.
Normally such deployment rely on PKI infrastructure which can create certificates on-demand and sign them with a trusted key.
What product/protocol the certificates are used for is irrelevant. What kind of WCF HTTP binding you use it maters not.
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.
What is the difference between Client Cert and Service Cert props in the security tab of WCF-BasicHttp, WCF-WebHttp adatpers based recv and send ports and how they are used by BizTalk for SSL authentication?
The documentations are not that specific.
How to Configure a WCF-WSHttp Send Port
Seems reasonably clear in that article to me
The Client Certificate is the one you hold the private key for and is used for signing your messages so the recipient can verify who you are.
certificate for authenticating this send port to services
The Service Certificate is the public key of the service you are connecting too. This way it can verify that you are connecting to who you think you are connecting too.
certificate for authenticating the service to which this send port sends messages
This is not required "The default is an empty string." however it is a security feature that prevents someone successfully being able to spoof the web service and intercepting your payload if they manage to poison the DNS entry.
I'm trying to understand more why I shouldn't use WCF transport security over the internet. From the answer here I'm told the chain of hops may not be secure. But isn't transport security just like https (which is widely used on the internet)? Or maybe I should ask, what is the difference between wcf transport and https?
If I need to explain myself clearer, please comment.
Thanks
Transport security is indeed very similar to HTTPS (and identical in many cases). What it provides you is an encrypted tunnel between your client and the server. Providing there's a direct connection from your client to your server, it's perfectly fine (providing that your client verifies that it got the right server certificate). If your client is talking to another intermediate server, on which you rely to pass the message to your server - then that intermediate server would get unencrypted data.
An example :
You have a company that processes payments. Because of some regulations, you need servers in each country, and those in turn pass the requests to your main server in the US.
You want to make sure that even if the local hosting company tries to find out what details are being passed, they can't.
That is what Message Security provides you - you trust only the client and your main servers, so you want only them to be able to encrypt and decrypt.
With Transport Security, there would be two transitions - the client will encrypt, and the intermediate server will decrypt. Then it will encrypt again, and your main servers will decrypt. As you can see, there is an intermediate phase where the data is plain in RAM in the intermediate server.
This MSDN article describes it very well, and where to use each :
MSDN
Look at another answer on the link you gave. It explains that the case where transport security not sufficient is when the client doesn't check server certificate. I quoted the answer below:
Yes it is 100% secure when the clients (which most clients do) validate the server certificate.
The multiple hop scenario mentioned here is complete bogus. This is only true when the same message travels through various applications. Like for example several application brokers. If these brokers do not communicate securely then the message can be read by intermediate network sniffers.
In other words, client/server communication over the internet is 100% secure even when there are a million routers in between but it is only secure when the client validates the server certificate as the client could connect to a man-in-the-middle host that could impersonate the server with a false certificate. If the client does not validate the certificate the message could be compromised.
I'm trying to understand more why I shouldn't use WCF transport security over the internet
You should not because (Quoting from here).
Transport Security
Transport security is used to provide point-to-point security between the two endpoints (service and client). If there are intermediary systems between client and the service, each intermediate point must forward the message over a new SSL connection.
Message Security
When using message security, the user credentials and claims are encapsulated in every message using the WS-Security specification to secure messages. This option gives the most flexibility from an authentication perspective. You can use any type of security credentials you want, largely independent of transport, as long as both the client and service agree.