Develop Reference

How Secure is connecting to an SSL encrypted Website?

I am using WebClient to implement a secure account check before a customer can use my application. but what I am worrying about is "does connecting to a website that uses SSL Certificate using HTTPS protocol prevent MATM attack and makes the whole communication encrypted ?".
In another words: will some programs like Wireshark be able to get the requests and responses in plain text as with using normal HTTP requests ? and is there an ability to alter the sent and received packets ? in order to change my application behavior or something.
[NOTE] I am not talking about getting my application pirated as I know that there is no way to get away from that fate.

HTTPS does prevent Man in the middle attack, as long as both sides are implementing the protocol properly and I assume that WebClient is implemented properly.
That means that even wireshark that is installed on your local box won't be able to decrypt the traffic
If someone in the middle would alter packets on their way, the other side won't be able to read them and the communication would break.
Some clarification given our discussion in your comments:
The above holds if your client is not compromised (HTTPS does work), since you are assuming that your clients will compromise themselves and use tools that will cheat your application by adding fake trusted certificates (which requires admin rights), I can suggest you to use two way ssl.
The tools that I know like Fiddler won't be able to decrypt this just by adding their trusted certificates, thus making it more difficult for your clients to attack your application this way, and bring them to use a debugger or patch it, because it is easier than implementing a two way ssl proxy.
You can also do what's described in this post to override the framework's certificate verification with code that expects one specific certificate and ignores the system's trusted certificates, which is compromised by tools like Fiddler (this implements What Mark suggested).

HTTPS encrypts the transmitted data and prevents man in the middle attacks by authenticating the HOST you are connecting to. However, in regards to a desktop application and also a web application, the user can use wireshark or an http proxy to view the contents of the https transmissions on the local host.
A way to mitigate this problem is to hard code the thumb print of your server cert so that you r application can encure that the server it's connecting to is presenting a specific certificate.
An example, would be if you were to install Fiddler on your local box and install the fiddler root certificate. Your application would think it's securely connecting to the server, but fiddler would be in the middle decrypting traffic. If your application code looks for a specific certificate thumbprint, you can throw an exception when a certificate other than the certificate you expect is used to connect, thus preventing the transmission of any data when a local proxy is in use.
Wireshark will always be able to see the packets being transmitted over the network but you won't necessarily be able to see the contents of the transmission unencrypted. However I'm not an expert in using Wireshark, so maybe someone else here can expound on that.
UPDATE
Ok to clarify more.... this question is discussing the encryption of contents being sent from a desktop application to a server.
Let's layout some assumptions:
The user of the desktop application, controls their desktop.
The application installed on the desktop is using a public key to encrypt.
Anyone with the corresponding private key can decrypt.
Since the user controls their desktop they can also run an http proxy on their desktop.
Now the way SSL(HTTPS) works is that your browser starts a secure handshake, at which point the server will return the public certificate, and your browser will attempt to authenticate that certificate with the authority you puchased the certificate from like (godaddy, geotrust, or versign, etc)
Assuming the user installed fiddler and it's root certificate, your desktop application would connect to fiddler, and be served fiddlers public root certificate, which it would validate against the locally certificate store and deem it trusted. Fiddler would then contact the server, which would send it the real public certificate.
Subsequently your http request from the browser is encrypted by the browser using the fiddler root public key, fiddler then decrypts the contents, and then reencrypts it using the public key from your server (mydomain.com) and forwards the request to the server, which then decrypts it and processes it.
Here is more information: http://en.wikipedia.org/wiki/HTTP_Secure
SSL offloading(https://f5.com/glossary/ssl-offloading) is also a feature used in network infrastructure for offloading the SSL load on other devices than web services. This is a form of man in the middle decryption of content. Also, Instrustion Detection systems in enterprise networks can have SSL certificates installed in them allowing these devices to decrypt the contents of requests and inspect them for behaviors indicative of network attacks.

What is Fiddler and how do I turn it off?

Pretty much straight forward question. I've tried to look this up but the results that I've found have been very vague. I'm busy with a Windows Phone app and have been running into some problems. I've read with Fiddler on you might run into some problems, but that's beside the point right now...
What is fiddler and how do I know if it's 'on'? Plus how to I turn it off if it is?
Thanks in advance,

Fiddler is a data monitoring tool that allows you to see incoming and outgoing HTTP(s) traffic from your computer. http://fiddler2.com/
It is a desktop app, so if you haven't got it installed on your PC - then you don't need to turn it off

Fiddler is a tool that helps you monitor your HTTP(S) traffic. It's great for debugging any network issues you're having as it lets you trace where your data is going and coming in from. If you haven't installed it, then you won't have it on your machine by default.

Monitor HTTP/HTTPs traffic from any browser
Fiddler is a free web debugging proxy which logs all HTTP(s) traffic between your computer and the Internet. Use it to debug traffic from virtually any application that supports a proxy like IE, Chrome, Safari, Firefox, Opera, and more.
Inspect and debug traffic from any client
Debug traffic from PC, Mac, or Linux systems and mobile devices. Ensure the proper cookies, headers, and cache directives are transferred between the client and server. Supports any framework, including .NET, Java, Ruby, etc.
Tamper client requests and server responses
Easily manipulate and edit web sessions. All you need to do is set a breakpoint to pause the processing of the session and permit alteration of the request/response. You can also compose your own HTTP requests to run through Fiddler
Test the performance of your web sites and apps
Fiddler lets you see the “total page weight,” HTTP caching, and compression at a glance. Isolate performance bottlenecks with rules like “Flag any uncompressed responses larger than 25kb.”
Decrypt HTTPS web sessions
Use Fiddler for security testing your web applications -- decrypt HTTPS traffic, and display and modify requests using a man-in-the-middle decryption technique. Configure Fiddler to decrypt all traffic, or only specific sessions.
Extend Fiddler as much as you want
Benefit from a rich extensibility model which ranges from simple FiddlerScript to powerful Extensions which can be developed using any .NET language. See full list of ready-made add-ons.

In HTTPS request , Request.IsSecureConnection return false

I have an asp.net application working in https (SSL). This is working well in my local computer and Amazon AWS(production environment).
But when I host this application in office (for testing) some strange things happens.
I can see the https in browser and the lock sign.
Fiddler also showing that the output is encrypted and shows port 443.
But HttpContext.Current.Request.IsSecureConnection returns false
And HttpContext.Current.Request.Url.Scheme returns http.
In the office we are using Juniper SSG firewall and TMG 2010 (Forefront Threat Management Gateway 2010). So server receive request through Juniper and TMG 2010. Thanks in advance.

To reduce costs I suspect that the SSL certificate is installed on the TMG Gateway and that this gateway is simply rewriting the request to standard HTTP when passing it to the actual web server. So by the time the request hits IIS and your web application it is a standard plain HTTP request.

This tripped my up after deploying to Amazon's Elastic Beanstalk environment. I couldn't see any way to get the load-balancer to allow the SSL request straight through to the server. Instead it was always terminating the SSL at the load-balancer and passing plain http back to the server.
I found this documentation: Elastic Load Balancing Concepts - X-Forwarded Headers.
Essentially the load-balancer injects a number of additional HTTP Headers into each request before forwarding it to the back-end server. The most relevant one is X-Forwarded-Proto which tracks the protocol used to connect from the client's browser to the load-balancer. This can be checked like so:
var loadbalancerReceivedSSLRequest = string.Equals(Request.Headers["X-Forwarded-Proto"], "https");
var serverReceivedSSLRequest = Request.IsSecureConnection;
if (loadbalancerReceivedSSLRequest || serverReceivedSSLRequest)
{
// SSL in use.
}
else
{
// SSL not in use.
}

Well another way to check is to check the port
if(context.Request.Url.Port == 443)
Note: check which port is used for secure connections, usually it is 443

How to listen on browser requests (proxy, addon...)?

I wanted to know what is the best way to write an agent on Win platform that will be able to monitor browser's communication.
scenario: monitor the user access to predefined url on Chrome, FireFox and IE. On each hit I send the stats to a server with some data (page title).
The ways I found so far are proxy and browser addons. Each has it's own advantages and disadvantages. The main disadvantage of the proxy way is handling of HTTPS communication. The addon disadvantage is the installation (need to install on every browser) and cross-browser support.
Is there another way? some service I can write with .net that will automatically hook on a browser when it is started?
Thanks you.

You do have only two choices - an http proxy, or to write a plugin for every browser. That plugin could just forward data via network to a central service, leaving you with the challenge of coming up with a common set of data that all browsers can provide, plus learning all the plugin models.
In my opinion, though, the only real option is an HTTP(s) proxy because otherwise you have to keep updating your plugins every time browsers change, or deal with the fact that new browsers can come along and be used.
Certainly you won't find a 'user is browsing a url in some browser' event in the OS - all it knows is that a socket connection has been opened on some local port to a remote server's port 80/443 (or whatever).
So I strongly suggest building on top of the excellent work that's behind Fiddler and use the Fiddler Core.
http://www.telerik.com/fiddler/fiddlercore
For https you have to decrypt and re-encrypt with a different certificate. The information that you need is just not available without actually unpacking the request. Fiddler achieves this by opening it's own SSL tunnel to the target server on the client's behalf, whilst acting as an SSL server to the client under a different certificate. So long as the certificate that it uses is fully trusted by the client, no problems occur.
That said, it means that the user cannot personally verify the identify of the target site - therefore your system would have to assume worst case scenario for any invalid SSL certificates and block the connection.

Why is WCF communication a tcp even if I say http in URI?

I have created a WCF server in a PC named PC1. I access the URI http://PC1:8000/ServiceModelSamples/Service using internet explorer from another PC named PC2.
When I debug the messages in Wireshark, I am confused that why there is no HTTP message, even though I specify "http://" in my URI. It only shows TCP protocol, there is no HTTP message or header.
Please advice

To wireshark, any browser request is just another TCP connection. As far as showing the HTTP protocol details is concerned, it might be guessing that traffic on a specific port (80) would be http. Since you are using a non-standard http port, it might not be able to do so.
To confirm this, try loading some other website/webpage (e.g. www.google.com) and see if it is able to show you http details. If it works, then next thing would be try and find some setting/configuration by which you can tell wireshark that it should treat traffic from another port (8000 in your case) as http traffic.
EDIT:
See this question as a guide to configure wireshark for http ports.

HTTP is an application layer protocol that sits on top of TCP, the transport layer protocol.
See http://en.wikipedia.org/wiki/TCP/IP_model for more information.

When you access the service using a browser, a "friendly" service responds to generate a web form to your browser. If you get a web page back in your browser, it is HTTP. That's not part of the "SOAP" spec, but it is part of the MS WCF stack supporting HTTP.
Then, if you fill it out, you might be POSTing or GETing the form, but POST is the default. That's also HTTP. GET is often disabled in WCF.
Then, you get back XMLish stuff in your browser, that also came by HTTP.
So you might just be missing an HTTP protocol decode in wireshark.
EDIT: I didn't see your URL included :8000. Wireshark won't decode that as HTTP unless you force it to, because it's not on the HTTP port. You can right-click on a port 8000 packet and say "follow conversation", and you'll see all the http goodness. You can also force wireshark to decode that stream as HTTP, which will let you "drill into" the packets past the TCP layer.