2

I've read that SSL is a good solution for "point to point" security, and not "end to end" security. For example, in this article at JavaWorld, it says:

SSL/TLS is simply not designed for such a scenario; SSL/TLS only handles point-to-point security... SSL/TLS may secure the path between any two [intermediaries], but not from one end to the other.

I am building a web service to provide data to separate clients, as described in this Programmers.SE question. My understanding of implementing SSL in that context is that I could add some kind of API key to all my web service calls and force HTTPS-only on the service, and I'm as secure as I need to be (I'm not passing anything user-specific, other than an email address under certain circumstances which are made clear to and initiated by the user). But this statement and this article seems to be disputing that. Is it suggesting that a man-in-the-middle attack is still possible on an SSL connection? The OAuth guide states here (second paragraph under "Beyond basic") that:

HTTPS is the recommended solution to prevent a man-in-the-middle attack (MITM), eavesdropping, and other security risks.

How is this reconciled?

Improve this question

2 Answers 2

Reset to default
5

Go read the article again.

What it is talking about is relaying of data - in this scenario, the client talks to your server (over SSL), Your server talks another service over SSL. While the information sent from the client is intended for the other service, this model requires that your server has visibility of it - you are the man in the middle by design in this architecture. The client does not see the credentials of the other server. Both connections are secure.

This article is about tunneling data to a remote site while maintaining a trust relationship between the client and the 'other server' - but ultimately if the other server sends that data on elsewhere then the integrity of the system fails - just as it fails if you don't use SSL on either of the two connections in the three node model.

Improve this answer
2

You can't totally protect against all scenarios, and SSL can be compromised by a man-in-the-middle attack. Sometimes MITM is performed on purpose, let's say you're using a websense content gateway or a Palo Alto firewall that offers on the fly SSL decryption. In this scenario the client trusts a CA or intermediate CA that is issuing certificates on the fly in order to decrypt and re-encrypt the data transparently.

SSL, like many other technologies is more about confidentiality and it does a fairly good job. Now, MITM can be used to manipulate the content as well which would be more of a dent in the integrity of the data.

I guess what I'm saying is that SSL is pretty tried and true. Get a certificate from a well known CA and you'll be fine, but you can't control whether the client has been compromised.

Improve this answer
3
  • What I'm worried about is unauthorized clients being able to access and use my service, so I need SSL to protect the API key I use. Is it a good measure for that purpose? If/when I start sending more user-specific data, I'll probably implement OAuth. Commented Jun 6, 2011 at 23:04
  • 1
    Also, I like your avatar. Commented Jun 6, 2011 at 23:05
  • I would think just based on the nature of the connection that the client themselves would be able to see that key unless it is also encrypted. SSL would protect against someone sniffing the session from being able to read it plainly in my understanding. Commented Jun 7, 2011 at 3:13

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.