This the situation: I have one webservice without SSL, which provides two pages for the other web application. When the user submits these pages, an XML file with private information is sent to the webservice.
How can I provide the necessary privacy protection on the XML file? Is the one certificate good enough to give the appropriate security?
I'm not sure about this one, and am in the preparation phase of a project... So need to know the involved work on this part...
As an alternative to SSL you could encrypt the file yourself using any of the algorithms available in using System.Security.Cryptography but then you have to work out a mechanism to exchange your key(s).
However by far the easiest way will be to have both web services using SSL endpoints. That will take care of all your confidentiality, integrity and identity considerations in one fell swoop.
Certificates are tied to the hostname of the server (or, with wildcard certificates, all the hosts in a domain). So if the two services are on the same host, then both can use the same certificate.
If they are not on the same host there will be no transport security on the non-SSL service unless this is added separately. WCF has support for message (or part of message) encryption.
The simplest solution is certainly to use TLS, ex-SSL (widely supported in every programming language).
There is no need to buy a certificate (and it brings no extra security, it is mostly there to make PHBs feel better): either create self-signed certificates or set up your own CA.
Related
We are working on a payment processing application and want to make sure we are doing CRL/OCSP checks when establishing secure connections (we will be initiating a TLS 1.1 session with a server). I would think that .NET would do this for us, but I'm not able to find any information in this regard.
Does .NET do this auto-magically?
Are there any settings to control how it works?
Please provide links to documentation that I cannot seem to find.
If it does not do this for us. Is there a 'best-practice' method for performing the checks, such as the X509Certificate2.Verify Method?
Thank you!
yes, by default WCF client do check server certificate to determine if it is valid for requested usage and is not revoked.
yes, you can control certificate validation behavior. These threads discuss the subject:
One: WCF, REST, SSL, Client, custom certificate validation
Two: Custom WCF client certificate over ssl validation
The best link I know of is this: https://msdn.microsoft.com/en-us/library/aa702579.aspx
According to that link, when using HTTPS, WCF checks the chain trust but does not check for revocation. For Message based security and for TLS over TCP, WCF does both checks according to the the client endpoint configuration.
We are using Web API 2.0 to serve clients in a context where SSL can't be used (no public internet access, clients can't be expected to trust a self-signed certificate). To secure content moving between the client and server, we'd like to be able to encrypt it. We're OK with un-encrypted HTTP headers (only need to encrypt payload). The question is: is there a way to insert a custom handler into both the request and response message pipelines so that we can apply a decryption as a request pre-processing step and an encryption as a response post-processing step?
We are using the built-in features of Web API to serialize/de-serialize between JSON and model classes, and don't want to have to refactor any of that existing code. So an encryption handler would have to be inserted at the very start/end of the request/response pipeline. Is this possible, and if so, what is the technique to insert custom request/response content pre/post processing?
The network is "public" in that users bring their own devices, but the network is isolated from the public internet. Clients will only use a custom application we are developing to consume our Web API service, so we can address implementation issues of a custom encryption scheme on both client and server side.
If you control the client application, you can hard-code the SSL certificate that the server is expected to return, which means that it doesn't have to validate through the normal PKI means (sometimes called certificate pinning). Most other approach will result in you attempting to re-invent SSL, but with some fatal flaw.
To be explicit, I think you are seeing a conflict between "a context where SSL can't be used (no public internet access, clients can't be expected to trust a self-signed certificate)" and "Clients will only use a custom application we are developing" where one doesn't necessarily exist. The user doesn't have to know that the certificate is self-signed, and self-signed does not always imply untrusted.
I'm setting up a WCF service. The service has to use transport security over https and I need to use some kind of authentication to prevent unwanted usage.
Digging in to WCF theory has disapointed me so far.
What I have found out so far is that I can use UserName authentication with transport security. But then I will need a certificate to secure the message.
And this makes it difficult to consume with most .NET languages.
I am surprised that I cannot find any good information on how to authenticate a user with wcf without message security?
What I would like is that the client passes username and password in some way to my service.
And for the record. The service will be using transport security.
To break it down:
How can I implement authentication without limiting interoperability?
Is WCF services so cumbersome that I either have to use a completely open service. And use IP filtering or VPN to restrict access?
UPDATE:
Since I am planing to use https with a SSL sertificate, will security mode "TransportWithMessageCredential" be the solution for me?
The only way to get REAL security IS to use digital certificates.
See my own question on this topic for details.
TransportWithMessageCredential (AKA mixed-mode security) is indeed what you are looking for.
I need to call a .NET SOAP webservice in a secure way. It must be secure in such a way that others can't call the WebService methods, and also it should not be possible for "the middle man" to understand the content of the messages.
The caller will also be a .NET webapplication installed on another IIS.
I can design the webservice methods as I want, so no restrictions there.
I have been researching HTTPS/SSL with certificates, but I don't know if it actually solves my problems in a good way? For example, it would be anoying if the certificates has an expiration date, although it's not a showstopper in any way.
So how would I go about this in a good way..?
Thanks for any help.
As #BrokenGlass said, SSL only encrypts the traffic between points. It doesn't handle securing individual functions from usage without authorization. Here is a good article on just such a topic using SOAP headers:
How to: Perform Custom Authentication Using SOAP Headers
This can be mixed with any form of authentication except Windows Integrated. To use Windows authentication, you'll need to have a separate library which accesses the Active Directory through the DirectoryServices namespace.
Assuming you control the infrastructure then keeping the server that is providing the web services behind a firewall so it's accessible only from the web servers and implementing IPSec should provide the necessary security.
From the software point of view, this article contains all you need to know about protecting the service interactions.
HTTPS/SSL works fine. Just make sure to renew your certificate in time to avoid warnings and messages for your client.
I need to call a .NET SOAP webservice in
a secure way. It must be secure in
such a way that others can't call the
WebService methods, and also it should
not be possible for "the middle man"
to understand the content of the
messages.
HTTPS/SSL only solves the "middle man" part of what you want to achieve. You would still need proper authentication in place on your web service. You could do this i.e by using the built in Forms authentication and providing a Login method that returns your authentication ticket.
I'm looking for a simple way to encrypt my soap communication in my C# Web-Service.
I was looking into WSE 3.0 but it seems Microsoft dropped support for it, and therefore it's not straightforward to use.
It seems WCF could've been an option but I prefer not to upgrade from .NET 2.0 .
Any simple, straightforward encryption method?
I think this can help; last year we used this to compress the webservices and it performed very well, I believe it could be enhanced with encryption classes;
Creating Custom SOAP Extensions - Compression Extension
Anything you do to provide "encryption" that isn't using SSL/TLS is likely to be vulnerable. Now you have to ask yourself, is it worth burning dev hours you could be spending on features on a rubber-chicken security measure? Maybe it is.
.NET APIs like DPAPI and the Win32 crypt32 API make it easy to encrypt blobs of data with static keys. But how will your clients receive the keys? Any installed SOAP client will have to either have the key burned into its configuration, or receive it over the insecure Internet.
This is the problem SSL/TLS solves for you; the dance you do with TLS certificates is what solves the problem of communicating public keys over untrusted channels.
Perhaps I'm being naive, but would
forcing the communication to be via
https be acceptable? I develop web
services that run on 2.0 and have had
success with just getting IIS to
enforce https on the virtual
directory.
That would be the simplest way to go
probably, but unfortunately I don't
have control over the IIS
configuration, and can't guarantee
that it can run https.
In that case, perhaps the best bet is to either case-by-case encrypt portions of the SOAP messages (after all, you may not need the entire message to be encrypted - just certain sensitive fields?), or you could opt to use an HttpModule to intercept all the messages and operate on the contents. In either case you're probably going to have to provide custom proxies.
Perhaps I'm being naive, but would forcing the communication to be via https be acceptable?
I develop web services that run on 2.0 and have had success with just getting IIS to enforce https on the virtual directory.
Alternatively, or in addition, you can check the HttpRequest.IsSecureConnection property.
We actually use WSE 3.0 in our web services, which were originally developed pre-WCF. For security, we use a SAML token based system built on the Cryptography classes in System.Security.
It works very well. However, this method is by no means "simple".
You can use parameters encryption in C# using the System.Security.Cryptography extension.
Encrypting your parameters and decrypting them would be harder but much more secure.
How To: Encrypt and Decrypt Data Using a Symmetric (Rijndael) Key (C#/VB.NET)
I'm using this aproach for an OTP (one time password) web service, and it works fine for me.