Attacks in SSL and SSH

Question

Assume that we have two end-host A and B connected by two routers R1 and R2. A wants to send a large file to B.

1. A decides to establish SSH connection with host B using public key authentication. Can router R1 or R2 inject content in TCP flow without losing any original packet sent from A to B?
2. Host A decides to use SSL. Assume A, B R1 and R2 are assigned public/private key with corresponding certificates signed by a certification authority(CA). All nodes know public key of CA. Can router R1 or R2 inject content in TCP flow without losing any original packet sent from A to B?

Answer 1

Because the SSH connection exchanges a key in such a way that only the holders of the two private keys can have access to the shared key, there is no way for the routers to inject meaningful information. They could attempt to inject information, but because the information they inject is not encrypted with the mutually agreed upon shared encryption key, it would only come out as garbage on the other end and if the stream was in a chaining mode, it would also potentially corrupt the entire session.

SSL uses a similar mechanism where the end user will be able to tell which server the information was sent from and only the server which the end user intended to talk to can get access to the encryption key that the client selects.

The one thing that can not necessarily be determined is if the client B is actually the client unless they also have a public/private key pair that is either CA signed or previously known. Both SSL and SSH have mechanisms to support mutual authentication, but frequently only the server is authenticated against a CA.

Regardless, while R1 or R2 (or anyone) could claim to be B, they would not know what B's request was under either system, thus they could not try to convince B that they were in fact A so long as B attempts a handshake with A's public key.

Answer 2

The whole reason SSL and SSH were defined was precisely to prevent passive and active attacks from whatever lies between the two end points. In particular, your routers R1 and R2:

1. cannot learn the data which is transfered from A to B (confidentiality);
2. cannot alter the transfered data (integrity);
3. cannot impersonate either A or B (authenticity).

In the specific case of inserting new data within the tunnel, let's see how it is avoided in the case of SSL (SSH is similar): in SSL/TLS, data is sent as successive records. Each record contains up to 16 kB of data. Once the initial handshake has taken place (this is where the certificates and asymmetric cryptography take place), both end points share a session key K (called "master key" in SSL terminology), from which they compute a few keys which are used to encrypt and authenticate record. In particular, for each record is computed a message authentication code, which can be viewed as a kind of keyed hash; the sender computes the MAC, and the receiver recomputes it. The cryptographic property of the MAC is that, without knowledge of the MAC key, it is not feasible to forge a pair (d,m) such that m is the MAC for data d.

The MAC is computed over the concatenation of the record data and, crucially, a record sequence number. Due to the MAC, attackers cannot insert extra records, replay old records, remove records or alter the order of records, because this would require recomputing the MAC for the new data or sequence number -- and, without the key, that's a no go.

Note that your routers R1 and R2 can still modify the data or block it; alterations are reliably detected by the receiver, but if the attacker wants to simply cut the wires, well, he can. Nothing in SSL (or SSH) tries to recover from alterations.