I am using u web service developed in wcf. And it has made secured using digital certificate.
The data decrypted at client side itself.
I found that it does "man-in-the-middle" approach to do the same.
But I could not get a explanation about how to block HTTPS analyser to decrypt the data.
Can anyone help me with some code or link?
If you want to prevent a man-in-the-middle attack, you need to ensure that the SSL certificate is trustworthy. If the https traffic can be intercepted then either the SSL certificate isn't from a trusted source, or the analyser has access to the private key.
If you want to learn more and see how it works, have a look at this post about Fiddler. Fiddler acts as web proxy and can be configured to decrypt https using man-in-the-middle.
Why make use of HTTPS when Fiddler can decrypt it
Related
i don't want to fiddler capturing my web application activity . i want to make my application more secure like banking site .while using internet banking site the fiddler cannot able to capturing the details. how can i make it by using C#.net in asp.net web application.
Fiddler can also capture HTTPS traffic if the user accepts the root authority certificate it installs when you enable 'Decrypt HTTPS traffic' in Fiddler Options.
Fiddler acts as a standard HTTP proxy. There is no way you can prevent Fiddler from intercepting and decrypting the traffic if the user chooses so, although Certificate Pinning can make things a bit harder on the Fiddler user.
You could of course use some kind of symmetric encryption to encrypt the payload of your requests, but you'd need to store the key somewhere on the client, making it vulnerable to attackers. See here for more info on JavaScript encryption.
Request.Proxy = New WebProxy()
This blocks the fiddler to set itself as a proxy.
I already have an existing LAMP application. I am going to integrate a 3rd part API which uses C#, so I'm planning to create a Web API for them to be connected. No other website will connect to the web API other than the LAMP app. How do I make a secure connection from my LAMP app to the web API? Thanks.
If it is just API calls and nothing dealing with interfaces you can use Encrypted WebSockets or create your Authorization headers... which could be a bit of work and would only work between the those two applications.
The most secure way to lock them up is a combination of a secure HTTP request (HTTPS) coupled with a Client Certificate.
All of these things are quite a tall order; you're best bet is to just get/create a half-way decent SSL certificate and use BASIC authentication. Your authorization headers will be encrypted. Even a self-signed certificate would work; make sure to research on how to make a self-signed certificate the most secure it can be. Also your LAMP server will likely make use of cURL to send the requests to the C# server, you'll want to make use of the curl -k option if you're going to be using a self-signed cert.
I am having a lot of trouble setting up an X509 certificate scheme in C#.NET. SSL is enabled on the server and the connection is being made over SSL. Certificates are being added to the request's store via request.ClientCertificates.Add(). However, no client certificate is being attached to the handshake request (which I am both confirming by both checking the server's code through HttpRequest.ClientCertificate and by analyzing the handshake in Fiddler).
As nearly as I can tell, the problem here is that the server is not requesting a client certificate. The certificates are definitely in the outgoing request, but I see none on the handshake and none on the server side - they simply disappear into the ether. I'm aware of the semantics behind choosing a certificate (thanks to this page), but it hasn't resolved my problem. The CAs should be the same; I am using the same self-signed, private key secured certificate for each end of the test.
Apparantly I can use certutil.exe to check which certificates will be chosen when used with a given server certificate. This would be a huge help if I could figure out how to use it like this. Certutil is a big program that is poorly documented. Any help would be appreciated.
If you're using IIS serverside you MUST provide certificate that is trusted by your server. So you MUST add client cert' CA cert into server computer 'Root certificate authorities' storage. IIS doesnt work with self-signed certificates. It requests client cert providing list of CAs it trusts to.
I am trying to send an X509Certificate from an Http Handler to a web service that will receive and read the certificate to authenticate the user. I know the certificate is sending fine; I have a tester that lets me look at the HttpWebRequest before sending, and the ClientCertificates property shows that it has a certificate attached. (e.g. request.ClientCertificates.Count = 1).
However, on the other side on the web service, HttpRequest.ClientCertificate is consistently showing NULL. I have looked at a number of Microsoft KB examples and all of them are using the same technique for inserting the certificate. Other unrelated articles show that HttpRequest.ClientCertificate is the preferred way of reading it in.
So what am I doing wrong, and how can I determine on the server that a client certificate was sent?
Perhaps configuring your HttpListener with clientcertnegotiation=enable with netsh would help (this makes the server negotiate the client-certificate during the initial handshake, as opposed to using re-negotiation).
It may also depend on whether you've initialised the certificate on the client side with its private key, see Can't connect to HTTPS using X509 client certificate
Here is a scenario:
Desktop application
Installed from the web
Needs to call a WCF webservice
Transferred data needs to be encrypted from Client to Server and Server to Client
Is there a well understood solution for this that is:
Secure
Easy to manage and deploy
I guess what this comes down to firstly is whether https encryption happens in both directions... Does it? Or do you need mutual authentication for that?
Try using HTTP over SSL
HTTPS is what you're after - it does provide end-to-end encryption (client-to-server and server-to-client).
So long as you can generate and install a server certificate, and be sure that your clients 'trust' the issuing authority of your certificate, then you're good to go. Note that this is not mutual authentication - your clients know that they have contacted the correct server, but the server does not know who has contacted it.
It can offer mutual authentication through the use of client-side certificates, but I would argue that does not fall under the 'easy to deploy' requirement.
HTTPS works...
I was confusing Encryption with Authentication and they are two different things. Simple Https which is the most common only authenticates the server to the client which is sufficient in many cases. An additional step (where the client also has a certificate) can be required to authenticate the client to the server but this is not required. In both scenarios, data with Https is encrypted from both the server to the client and client to the server using a session key once the SSL handshake has been completed. This is all described here:
Description of the Secure Sockets Layer (SSL) Handshake