IPSec VPN is security provided at Network layer with following facilities:
Authentication
Data Integrity
Confidentiality
Anti-Replay
But making this set up is more costlier than using SSL at Application layer.
For example: http uses SSL to talk to Web server
So, Why people use VPN?
You pretty much gave the answer yourself: encryption on the network layer provides security for all traffic that goes through it, instead of each application having to implement its own security model.
VPNs are also used in completely different scenarios than your typical HTTP request. You most typically use VPNs to join into an intranet from outside and use all the network internal services. Doing this via a VPN means you just need to expose one network entry point to the outside world. Otherwise you'd have to expose every single service to the outside world, and implement individual security models for each.
Related
I have been reading the Openshift documentation for secured (SSL) routes.
Since I use a free plan, I can only have an "Edge Termination" route, meaning the SSL is ended when external requests reach the router, with contents being transmitted from the router to the internal service via HTTP.
Is this secure ? I mean, part of the information transmission is done via HTTP in the end.
The connection between where the secure connection is terminated and your application which accepts the proxied plain HTTP request is all internal to the OpenShift cluster. It doesn't travel through any public network in the clear. Further, the way the software defined networking in OpenShift works, it is not possible for any other normal user to see that traffic, nor can applications running in other projects see the traffic.
The only people who might be able to see the traffic are administrators of the OpenShift cluster, but the same people could access your application container also. Any administrators of the system could access your application container even if using a pass through secure connection terminated with your application. So is the same situation as most managed hosting, where you rely on the administrators of the service to do the right thing.
I have several WebApp clients that will be used to serve authenticated users via TLS. On the backend these WebApps communicate to a CloudService via NetTCP using WCF on cloudapp.net endpoints. Both sets of resources are on the same Azure subscription, resource group and geographic location.
My question is in regards to both performance as well as security:
1. Will traffic between the WebApp and CloudService resources stay within the Azure infrastructure to maintain the best performance? If not is there a way to ensure the fastest possible communication between the WebApps and CloudServices?
2. If the traffic does remain internal then are there any concerns about securing the traffic when these calls are made or can I safely keep the calls as http:// requests since they will not be made on any public channels?
3. Are there any other security or performance concerns regarding this scenario?
Not, unless you implement VNet integration and integrate your WebApp into the CloudService VNet.
Well, it depends on how paranoid you are, if you absolutely trust Azure, you can use HTTP, without S. I'm not sure how secure that is, but I can imagine no one would say: "Use HTTP, Azure (or whatever) is secure enough".
If everything is in one region, it should be fine, theoretically.
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.
I have read in Training Kit of MS -WCF that all the bindings by default provide network security that is developer has to do nothing for implementing security.
I have one query over this :- I have used netTcpBinding and i send various objects from client to server. When sending objects we send a special guid in one of the properties of object which we again verify at Server before processing the request.
I will like to know what all vulnerabilities are involved, if do not do anything explicitly for Security, that is no transport level security is applied.
One more point we are using NetTcpBinding at Internet.
netTcpBinding is normally used for Intranet where you are likely to have point to point comms so transport security is probably adequate.
If you are operating over the web then you will want to enable Message level security to secure the end to end traffic (transport security will only secure the content for 1 hop). The default security for netTcpBinding is transport security so you need to change this.
In both cases message privacy (encryption), integrity(against tampering) and partial authentication is achieved.
NetTcpBinding I believe defaults to Windows authentication - so you will need an account in a domain or actually on the Service machine (if operating in a Workgroup) matching the Windows credentials of the client.
Note that you can programmatically change request the credentials from the client and set them programmatically before opening the client proxy if need be.
Also enable reliable messaging.
We are currently using Apache to handle incoming SSL requests. These are two-way SSL connections. Apache accepts the https connection and pass the request on as http connection to the application server. This works well for us.
We would like to use the same kind of centralized mechanism for outgoing two-way SSL connections. Is there a way do this with Apache or another product? To complicate things the client certificate needed to identify out client can vary depending on the destination.
In short:
- Internal clients connect through http to Apache or another product.
- Apache or another product knows based on a rule (?) that a two-way ssl connection is required and sets this up with the destination.
- Depending on the destination the correct certificate is sent to identify our client.
Regards,
Nidkil
What you're talking about is, or course, an HTTP proxy server. In the first scenario you are using it as a transparent proxy to provide SSL support for connections to a set of web pages. In the second scenario you want to use it to provide connections to secure-only pages on behalf of clients speaking HTTP.
You can do this with the Squid proxy, which is free and open-source, provided that your machine sits between the clients and the Internet. Look for "SSLBump". You do need a certificate which the clients would consider valid for all web pages to be accessed (otherwise they will notice what you are doing, which is basically a man-in-the-middle attack).
However, I would strongly recommend against this - if a site requires SSL, it is likely to do so for a reason. It is almost certainly not OK to have internal clients connecting to an online banking site and have you bumping down their encryption so that you can monitor their traffic or whatever...