If you are a programmer, you may be tempted to simply rely on SSL for all your security needs since all it really requires is the addition of an HTTPS string in a URL and the subsequently compatible server. Now while SSL is indeed very hardened security, its standardised nature makes it easy to predict, manipulate and emulate. The last is particularly important, as it leaves the SSL chain open to what is known as a man in the middle attack. To understand this, think of your connection to the server, you can only tell its the server because it tells you it is, now what if there was a proxy server in the middle of your connection, telling the server it was you (the client) and telling you it was the server, in a sense you would have no idea that such a server is operating, however it would be able to make simultaneous connections with both you and thus peer on your traffic. This can be done since SSL is standardised and there are no subsequent surprises in the protocol.
Now SSL has indeed considered this attack, and they have something to remedy it. The notion of certificates was used to help distinguish a servers identity by a trusted third party. This doesn’t invalidate the SSL connection, however it will flag it as being potentially insecure (you can often see this warning in web browsers). However a man in the middle attack can often make itself a trusted CA (certificate authority) and issue its own certificates for the proxy servers connection, I often use Charles proxy to accomplish this.
Now it’s important to note that this has been done in the real world before, in fact TOR exit nodes used to be poisoned with man in the middle proxy attacks, showing that you shouldn’t rely totally on SSL to be safe. However this is not to say SSL is worthless, in fact quite the opposite, I would definitely advocate SSL as a first step in securing communications, just not as the only step. I was once told by someone that everything gets hacked, its just a matter of slowing the hackers down as much as possible, and SSL will indeed slow most of them down (and in fact, exclude the vast majority of reverse engineers).
So what can be done if SSL is not enough? I am chiefly concerned with reverse engineering of my protocols, since I don’t want some other developer to see how my calls work and then make similar types of calls to my web service to extract data off it. So for this, I often wrap all my packets in what is known as a dynamic simple cipher (transposition or substitution are my favourite) which negotiates the kind of cipher to use based on a Diffie Hellman Key Exchange. After that I would often employ AES encryption also by using a Diffie Hellman Key Exchange. By rolling your own security, you can make it difficult and time consuming for hackers to emulate your security measures and thus make calls to your web services. It’s certainly not bullet proof, but will definitely make your program more annoying to crack.