4

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.

Toby Allen
  • 10,997
  • 11
  • 73
  • 124
Erric J Manderin
  • 1,096
  • 3
  • 10
  • 23
  • Further reading: http://security.stackexchange.com/questions/tagged/ssl – Tim M. Mar 02 '14 at 19:33
  • what is your goal: are you trying to make it more difficult for your clients to intercept the traffic, or are you worried about possible attacks against you clients? – argaz Mar 02 '14 at 19:48
  • I want to make it more difficult for my clients to intercept the traffic so someone couldn't or at least make hard for him to alter the response and gain unauthorized access to my app – Erric J Manderin Mar 02 '14 at 19:53
  • Because my application will verify the given username and password from my website and depending on the answer received it will give access to the user – Erric J Manderin Mar 02 '14 at 19:53
  • @argaz so what ? > > > > – Erric J Manderin Mar 02 '14 at 19:59
  • well like you said it yourself: you can't protect your client application, especially if it's .net, I don't think it makes a lot of difference if your client changes the traffic or changes things with a debugger. – argaz Mar 02 '14 at 20:10
  • @argaz: please can all people stop giving literatures about that fact ?. What I have described and want to solve here is very clear so please help me solving this problem and don't worry about other things I haven't complaint about. – Erric J Manderin Mar 02 '14 at 20:13
  • You can go for two way ssl to make it more difficult for him to change traffic with the known tools: http://stackoverflow.com/questions/2066489/how-can-you-add-a-certificate-to-webclient-c – argaz Mar 02 '14 at 20:15
  • @argaz: this doesn't answer my specific questions too: I want to make sure that 1- It will be very hard to alter the sent and received packets. 2- Will be hard to see the requests in plain text. – Erric J Manderin Mar 02 '14 at 20:20
  • I added some clarification to my answer, let's move the discussion over there, Points 1 and 2 are the same in this case. – argaz Mar 02 '14 at 20:36
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/48821/discussion-between-argaz-and-erric-j-manderin) – argaz Mar 02 '14 at 21:58

2 Answers2

1

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).

Community
  • 1
  • 1
argaz
  • 1,458
  • 10
  • 15
  • sorry a little bit of information to go :D, in your link of two way ssl I don't find such thing, also what you mean is that with implementing the two way SSL can I use the Cert that I will buy from a trusted vendor or I have to create a self signed one ?. also will that stop what Mark says about using fiddler ? – Erric J Manderin Mar 02 '14 at 20:49
  • Sorry for my very naïve questions. Just I know 0 about that field. – Erric J Manderin Mar 02 '14 at 20:50
  • Two way ssl means both client and server exchange certificates, You can go for a paid certificate for the server and a self signed for the client (because all your clients have it, it's not protected so it's wrong to use a paid one). Important question: Will your server certificate be used for anything else but your client application? If not, I would go for a self-signed certificate and use the method from the last paragraph to save money. Yes two way ssl will prevent what Fiddler is doing because it has to cheat both the server and the client, and only the client is under his control. – argaz Mar 02 '14 at 21:40
  • but as far as I know if I used self signed certificate I will have to make the users install in to their machines and it is a thing that is not very acceptiable – Erric J Manderin Mar 02 '14 at 21:47
  • as there is no way to silently install a certificate – Erric J Manderin Mar 02 '14 at 21:48
  • No, read the post I linked in the last paragraph. You can programmatically make your application trust it. – argaz Mar 02 '14 at 21:48
  • so to make everything clear you are indicating that in order to secure my connection between my app and my website I will have to use self signed certificates that may be viewed in the browser as insecure certificate ? – Erric J Manderin Mar 02 '14 at 21:51
  • or there is a way to only make paid certificate protect the site and the self signed on protect only the communication to a specific page @ the website ? which will the client connect to ? – Erric J Manderin Mar 02 '14 at 21:52
  • I know that this is going very stupid and long from me and I am sorry for that... – Erric J Manderin Mar 02 '14 at 21:54
  • You won't be able to create a self signed certificate and use it as a client for a certificate you purchased from a CA. – Mark At Ramp51 Mar 03 '14 at 00:50
  • You don't need two way SSL, you just need to ensure you only send data when you are connected to a server that presents a specific certificate. – Mark At Ramp51 Mar 03 '14 at 00:51
  • The reason fiddler won't decrypt two-way ssl is specifically due to the same reason you won't be able to use a self signed certificate with a certificate on your server that was purchased from a public CA. – Mark At Ramp51 Mar 03 '14 at 00:54
1

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.

Mark At Ramp51
  • 5,343
  • 1
  • 25
  • 30
  • Well what if a bought a certificate from a trusted vendor ? not self signed ones ? – Erric J Manderin Mar 02 '14 at 19:34
  • My answer assumes you do that. However it doesn't prevent running a local proxy. Install http://www.telerik.com/fiddler set it up to decrypt SSL traffic and when it asks you to install the fiddler root certificate, install it. You'll see that websites will act as if they are on the proper ssl with no man in the middle. – Mark At Ramp51 Mar 02 '14 at 19:38
  • but if that is possible this breaks all the means of SSL ! – Erric J Manderin Mar 02 '14 at 19:39
  • Sorry I am pretty confused as I have not knowledge about that field can you explain a little bit further as how to prevent this because if someone did that he will be able to alter the received packet by my application and gain unauthorized access to it or similar... – Erric J Manderin Mar 02 '14 at 19:40
  • This answer is confusing, you can't decrypt https by sniffing it, that's why wireshark can't do it, if it could than it would have been possible. The first and last paragraphs are confusing because they imply that it could be possible. – argaz Mar 02 '14 at 20:20
  • @MarkAtRamp51, if it possible to decrypt SSL communication what is the use of it then ? specially that it is possible with that naïve very easy way ? – Erric J Manderin Mar 02 '14 at 20:21
  • @argaz You are just plain wrong. You can decrypt https traffic by sniffing it, it all depends on how you do it. Wireshark is a different type of tool than an http proxy like fiddler. So when you access a website with fiddler in the middle, fiddler swaps in it's own public key certificate, which validates because you've installed the fiddler certificate authority on your local system. So your web browser communicates with fiddler and then fiddler communicates with the server. – Mark At Ramp51 Mar 03 '14 at 00:33
  • @ErricJManderin The use of SSL is to make the transmission confidential, and encrypt the contents. You only encrypt things that you have the intent to decrypt. So if it wasn't possible to decrypt than SSL would clearly wouldn't be what it's used for today. Anytime you have the private key used in an assymetric encryption process you can decrypt the ciphertext. There is nothing simple or naive about it. If you control the localhost and the private keys you can decrypt and reencrypt the transmission contents as many times and in as many different ways as you like. – Mark At Ramp51 Mar 03 '14 at 00:36
  • @MarkAtRamp51 I'll write the definition of sniffing: it means reading the packets being trasnmitted, without modifying them, what fiddler does is modifying packets and impersonating the server. we already discussed what you said in the second comment, his goal is to make it harder for the user to modify traffic, we know that you can't prevent it completely. – argaz Mar 03 '14 at 04:39
  • Even when you're modifying packets (MITM) it requires the consent of the user to work, so you can't even really say that ssl can be decrypted this way (by an attacker). – argaz Mar 03 '14 at 04:49
  • @argaz this is exhausting. If his code looks for a specific cert he's connecting to and refuses to send data otherwise, it can. – Mark At Ramp51 Mar 03 '14 at 05:19
  • @argaz you don't have to define sniffing for me. I know what it traditionally means. You introduced the term in the context of this thread, not me. – Mark At Ramp51 Mar 03 '14 at 05:23
  • @argaz in the scenario being discussed... the user is the attacker. – Mark At Ramp51 Mar 03 '14 at 05:27
  • Yes we are actually agreeing just arguing about terms, just thoguht your initial response was a bit confusing and you've already edited it. He eventually went for the "specific cert" solution. – argaz Mar 03 '14 at 18:24