|
I have learned that SSL is a protocol to implement machine-to-machine encryption and that there are protocols, like PGP, which implement user-to-user encryption (end-to-end encryption). There are mobile internet messenger applications which transmit the messages over a SSL connection. Would it make sense to use user-to-user encryption in addition to the SSL connection? Would this yield any benefits? |
|||||
|
|
By encrypting machine-to-machine, you (sort of) protect the data in transit, but user-to-user encryption protects the data in transit, from parts of the machine (further up the stack), as well as protecting it in storage. An additional benefit to user-level encryption is better control over the encryption process, in case you do not have control over the SSL process at any point. The question becomes, "who are you protecting the data from?" The Pidgin chat client, for instance, can be configured to use user-level encryption, and gains the benefits I outlined. |
|||
|
|
|
SSL establishes a protected data tunnel over an unprotected data tunnel. You can do SSL between two machines (even if the machines are smartphones) but the practical setup can be difficult: smartphone-to-smartphone direct connections are rare, because in a normal connection, one machine has the role of client and the other is a server (the "client" is the one which talks first, the "server" is the one which waits to the client to talk). Initiating such a connection requires the client to somehow "know" the IP address of the server. Network providers for smartphones do not make that easy (and, come to that, neither do ISP for home users). Common usages of SSL from smartphones are between the phone and a server. If two phones connect to the same server, then that server could act as a relay for data packets sent from one phone to the other, allowing for any communication protocol, even SSL. User-to-user encryption, or at least phone-to-phone encryption, makes a lot of sense if you do not trust the relay server. This is exactly the security model for "secure emailing" as is embodied by PGP. |
|||
|
|
|
Schroeder put it quite properly, and this single sentence really can (nearly on its own) answer your question.
I'd like to expand upon that just a bit, though. If your only concern is to protect the data from casual eavesdroppers (e.g.: that creepy guy next to you in the coffee shop), then machine-to-machine connection security technologies like SSL are typically sufficient. Presuming the protection mechanism itself isn't weak in some way, you have generally little to fear from people snooping on your traffic. However, if you are concerned with protecting your data from government agencies, malicious insiders at your ISP, malicious insiders at the app host, your employer's monitoring systems, or other advanced attackers with man-in-the-middle positioning, then end-to-end solutions like PGP are the way to go. SSL will generally protect the connection between you and the app host. However, if the SSL connection is compromised (i.e.: your company uses an SSL proxy to monitor all traffic on their network as if it was cleartext) then your data is vulnerable. Also, SSL does not protect data at rest in the app host's servers where malicious insiders may be able to exploit it. PGP protects the data along the entire path, from its origin to its final destination, and protects the data at rest. The only way to compromise the data then is to compromise one of the endpoint machines, obtain a copy of an authorized private key, or find a weakness in the encryption algorithms used. Generally, this will protect you from malicious insiders and man-in-the-middle attacks. However, you must still be vigilant against malware and malicious actors with physical access to either endpoint. On that last point, it's good to remember a few of the Ten Immutable Laws Of Security:
However, if you're really afraid of those government agencies or other such "big bad guys", you should probably keep this in mind. |
||||
|
|
|
Short answer, yes, there can be a few select cases that it will help when talking directly between two clients if the applications are extremely hardened. There are also many when the data needs to travel in the open over an untrusted middle man (ie, mail server, chat server, etc). Long answer. There are a couple of things worth mentioning here. First, SSL generally only provides authentication of one machine, therefore it does nothing to ensure that the client connecting to a server is a particular client (other than to attest that they are the same client that initiated the SSL session). Only the server generally has a trusted certificate. There is support for client side certificates in SSL, which would verify a particular client, but it is fairly rarely used. Next, user to user encryption as you've described it here goes slightly further but not significantly. In a system like PGP, you do have mutual authentication as both parties have certificates that should be validated through some type of public key infrastructure (PKI), but that could be done with SSL alone. Moving the encryption to the application layer (instead of the transport) may be meaningful in some rare cases, but for someone to compromise SSL data, they would have to have compromised one of the end points (most likely the network stack). If one of the end points is compromised, the software client can't necessarily be really be trusted either since at attacker would need kernel level access to one of the endpoints to hijack the network stack and they could then hijack I/O to/from the application. It would mitigate a select few threats if the application is designed to be highly secure against any kind of access from another program, but that would require a much more in-depth approach to security than simply encrypting the data to the application level. What is more important is to make sure that SSL is well used by an application. Login's need to occur to attest the client and SSL sessions need to be properly closed if an endpoint leaves the session. (ie, so I can't sit down at your computer and use it as you.) Note that this last point also matters even if it is application to application. As for going through an untrusted middle man, the problem with SSL is that it is not one continuously protected connection if you are going through a middle point or more than one type of transport. Encryption provided by the final client will protect the data regardless of transport and also protect it through any handling. Many systems use "envelopes" where information is encrypted ahead of time for multiple steps of the journey. Each system can open the outermost envelope, determine what it needs to do with the information and can then pass it on to the next system. Eventually, the user on the other end can open the final envelope and get the original message, but nobody in between can get access to it. |
||||
|
|
