I'm currently developing an application in C# for Windows Phone against an HTTPS web service. An example of the endpoint that I'm accessing is as follows: https://apitest.letsfreckle.com/api/projects.json?token=lx3gi6pxdjtjn57afp8c2bv1me7g89j
When I inspect the network traffic using Fiddler with the "Decrypt HTTPS traffic" option enabled I get a "NotFound" exception in my code. If I disable the "Decrypt HTTPS traffic" option in Fiddler, then I get the response that I would expect in my code.
In Fiddler, I see the HTTP CONNECT request with a result of 200, but nothing else.
I'm using Fiddler v2.3.7.4 beta on 64-bit Windows 7 with no filters. I have no proxy servers configured and the problem persists if I disable my anti-virus protection (Microsoft Security Essentials). I have tried removing the interception certificates and the root and site-specific certificates are correctly re-created.
I appreciate that this scenario works perfectly well for the many Fiddler users out there, but would be grateful if you could shed any light on why it's not working for me.
UPDATE: I can hit the endpoint and get a response just fine using a browser and when not decrypting HTTPS traffic through Fiddler and when Fiddler is not involved.
You can install the certificate on the emulator, I use an HTTPS endopoint in my app too and I can decrypt the traffic.
You need to visit with IE Mobile this URL: http://yourmachine:8888/ and click on the link "install the root certificate", after you should be able to see the traffic beyond the handshake (CONNECT)
You need to start Fiddler bedore the emulator I think.
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.
Is there a way to configure IIS or mark up my code so that the client (any major modern browser) will always include Kerberos information in the response without having to make any modifications to the client itself?
In this specific server method, I'm using ASP.NET impersonation with delegation enabled in AD and it would seem that from firefox and a few other clients, Kerberos data is not being passed from the client to the server.
My application only has Windows Authentication enabled, but how can I force the requests to pass Kerberos information along?
If it helps, I'm using jquery's ajax to GET or POST my requests to the server.
As long as your server is returning "WWW-Authenticate" headers that indicate it accepts Kerberos authentication ("Negotiate"), the client should automatically supply the necessary credentials. Make sure that Negotiate is listed as a possible provider for Windows Authentication in the Authentication configuration of your application. You'll probably want to disable NTLM in that list.
You can tell if the client is sending Kerberos tickets if you look at the HTTP headers. It should have something like "Authorization: Negotiate YIIN..."; the first few base64 characters of the payload let you distinguish between Kerberos and NTLM.
I am not sure if this is possible, but I am running into an issue where a Web Service call is giving me back a 401 Unauthorized. I have looked at the Fiddler logs and confirmed this, but I am passing in the correct credentials through my app. Is there anyway to get credentials that are being passed to the service by looking at the Fiddler Headers or Auth tabs?
If you click the AUTH tab in Fiddler, it will show you the information about the authentication challenge response.
Note, however, that NTLM and Negotiate don't send the raw password over the network.
Is the target site HTTPS? If so, is Extended Protection enabled?
I have prepared an ASP.NET web application (ASP.NET V2.0) and I configured it in my IIS (V7.5). I used Request.Url.AbsoluteUri in my application and it works fine in my server. I deployed the web application on my client's server machine (2008 R2 Server). But in my client's environment Request.Url.AbsoluteUri always return http url even though they enabled SSL. Whether any IIS settings configured on my client's server machine? Please guide me
I have seen this before. The reason was that the load balancer at the production site terminated the SSL connection. It by itself connected to IIS using HTTP only. This scheme is a way to offload the SSL computations to the load balancer. It means that the IIS application does never see the HTTPS protocol although the browser does see it.
As spender pointed out in the comments, please see the HTTP headers arriving at your application. The load balancer is likely to add information to them that allows you to reconstruct everything.
If you want to check whether request is HTTP or HTTPS. You should check headers. Below link really helped me to solve it.
http://www.bugdebugzone.com/2013/12/identifying-https-or-ssl-connection-in.html
I have to send a request as https post to a third party Apache server.
It seems my code is fine as testing to an aspx page shows parameters without any problem, but when I tried to conect to Apache server answers like I didn't send anything.
As I've been digging a bit more, I found out a reference to "servers handshake". Does this mean IIS has to have SSL enabled to conect to the Apache Server?
I don't think so.
the ability to call https from your code (hosted on iis) doesn't involves iis ssl settings.
you need to make sure you ignore certificate errors (if there are some) and it should work.