StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>SSL/TLS suffers from the same problem that any Diffie-Hellman-based implementation you come up with would have, in that it can still be broken by a man-in-the-middle attack.</p> <p>The reason TLS is secure and trusted is because the client, when receiving the server's certificate, authenticates it by checking that it is signed with another certificate from a known trusted identity - say, VeriSign. Thus far, this makes it impossible to enact a man-in-the-middle attack without having VeriSign's <em>private</em> key - when the interloper sends a fake certificate proclaiming to be the server, the client would easily detect that this certificate is not signed using the trusted identity's certificate, and bails out of the connection, displaying a warning to the user.</p> <p>For your purposes, it's likely easiest to use TLS. To make it secure, you would generate a certificate for your server, and then embed in your client the <em>public</em> key for that certificate. The client can then verify that it is talking to your server, without having to expose the private key, which you <em>don't</em> have to distribute.</p> <p><strong>EDIT:</strong> In response to your comment on Jerry's answer, if your hosting provider doesn't allow SSL/TLS connections at all, preventing a man-in-the-middle attack will be tricky. If this is your only reason for avoiding TLS, I would suggest getting your provider to turn it on, or finding a provider that allows for it.</p> <p><strong>EDIT:</strong> In response to your edited question: even if you're now using RSA in your Silverlight client to send data to your web service, you cannot guarantee that the client <em>itself</em> has not been modified. It's quite possible for an attacker to dig into your client, determine the algorithm you're using to perform the encryption/handshake, and then write code to impersonate your client (or indeed, modify the client to include their code). Once they've done that, they can start analyzing your API and use it to make calls to your web service.</p> <p>It's the same with SSL/TLS - the client can validate the identity of the host using the host's certificate, and as long as the host's server is secured, the client can trust the output from the host; however, there is no mechanism in which the host can 100% validate that the client is who they say they are, as the client will be run on a machine which does not have a controlled execution environment.</p> <p>However - despite the above being true, and that it's <em>possible</em> that an attacker can compromise your system in this way, it's likely not <em>probable</em> -- unless you're working on a public-facing system that attracts a lot of attention/use, or a system that deals directly with money in some form, the attacker needs to make some effort before being able to send their own input to your web service.</p> <p>Your best bet is to validate the input received by your web service thoroughly, and don't leave dangling APIs accessible that your regular client would never use.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload