Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I have a web service and an application that connects to it. I do not expose the web service via any discovery protocol to the outside world. I have two security mechanisms:

  1. My software uses SSL and encrypts all messages using a public/private key mechansim.
  2. I use WCF WIF integration username/password authentication, so my application has a unique user name and password which allows it to access the web service.

Now, if the user installs a sniffer such as Fiddler on his machine and installs the special certificate that allows fiddler to sniff https traffic:

  1. Will it allow it to analyze my web service methods structure?
  2. Will the user be able to reverse engineer the user name and password of my application and access my web service?
  3. Will the user then be able to build his own messages (REST/SOAP) and interact with my web service?
share|improve this question
add comment

migrated from stackoverflow.com Mar 8 '12 at 21:14

This question came from our site for professional and enthusiast programmers.

2 Answers

up vote 3 down vote accepted

Will it allow it to analyze my web service methods structure?

Yes, SSL/TLS only secures the transport of the data between your and the user's machines.

Will the user be able to reverse engineer the user name and password of my application and access my web service?

If your application includes credentials to speak to the server, then most likely yes (this is true in general and has nothing to do with SSL).

Will the user then be able to build his own messages (REST/SOAP) and interact with my web service?

Yes.

share|improve this answer
    
But what about my public key private key encryption ? –  James Roeiter Mar 7 '12 at 1:53
1  
@James: The data is only encrypted during its transportation over the internet. On both ends of the connection, the data exists in unencrypted form. That's the whole point of communication. –  Niklas B. Mar 7 '12 at 1:55
    
Ok , but if I encrypt that strings I pass as method parameters to the web service manually inside the application , no one besides my web service can decrpt them and understand what they mean , so the hacker-user can perhaps call the web service but cannot have any benifit from it . And perhaps (not sure) if I choose to use TCP connections , simply sending encrypted objects to a single method , the hacker can never really understand the protocol ?? Am I wrong ? –  James Roeiter Mar 7 '12 at 2:08
1  
@James: Yes, you're wrong. Obfuscation only delays reverse engineering of your protocol by some time, it does not prevent it. The application itself could be cracked easily, thus revealing the original strings. –  Niklas B. Mar 7 '12 at 2:11
2  
@user1200129: Yes, but that wouldn't solve this particular issue. The same public key could be used to encrypt or replay any other request. –  Niklas B. Mar 8 '12 at 20:30
show 3 more comments

Fiddler's HTTPS decryption is a classic Man-in-the-middle attack. It works because the user can convince the program to use a certificate that you don't want it to use. That's the problem with generic SSL clients - especially if your application is built using Windows networking components. To secure against Fiddler (or any other user-authorized SSL proxy), you need to have full control over the CA certificates that your application will allow as signers for the server's certificate. Most SSL implementations do not give you that level of control, alas.

share|improve this answer
1  
That doesn't really apply if the MitM has control over the client application itself. He could just modify the app to ignore certificate errors and use an intercepting HTTP proxy anyways. –  Niklas B. Mar 8 '12 at 20:32
1  
Once you can modify the app code, all bets are off. So yeah, but it's a game-changing level-up :-) –  Ross Patterson Mar 8 '12 at 20:40
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.