Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?
share|improve this question
    
At state of knowledge now, No and No. But things may change... –  F. Hauri Jan 2 '13 at 17:42
    
You are asking for the possibility of a man-in-the-middle attack. The answer is no and no: SSH and SSL provide authentication and end-to-end security. –  Martin Schröder Jan 3 '13 at 9:27

2 Answers 2

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.

share|improve this answer
    
Thanks a lot. I guess in case of SSL, we wanted R1 or R2 pretend to be A, not B(if our goal is to change data sent from A to B). Beside that a should be authenticated or B. I guess as A posses file, B should authorize itself to A. –  sanazz Jan 2 '13 at 21:46
    
In case of SSH, if A and B are not using CA and the way their sharing their public keys are not safe, R1 can pretend to be B when communication with A and pretend to be A when communication with B, so B has two shared keys and can convert whatever is received from A and send them to B while changing the messages. Is it true? –  sanazz Jan 2 '13 at 21:46
    
@sanazz - With SSL, R1 or R2 could not pretend to be A because they don't have A's private key as signed by the trusted third party (ie, the CA). If they could get a trusted third party to give them a certificate that said they were A, then B would fall for it though. –  AJ Henderson Jan 2 '13 at 21:58
    
@Sanazz - Yes, if there is no third party validation of the SSH public key and A and B have not talked in the past, then B has no way to verify that someone saying they are A is in fact A since they have no reason to trust the public key of A. With SSH, generally the client and server will keep a copy of the certificates that are used when talking to a host to verify the host is the same in the future, but if that first conversation can be compromised and no validation of the exchange takes place, then a MITM is possible. –  AJ Henderson Jan 2 '13 at 22:01

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.

share|improve this answer
    
Thanks a lot. Is sequence number both encrypted an MACed? –  sanazz Jan 2 '13 at 21:47
    
The sequence number is not encoded in the record itself; it is implicit. First record sent after activating the encryption+MAC has sequence number 0, second record has sequence number 1, and so on. Since sender and receiver agree "naturally" on the record order, there is no ambiguity (the inclusion of the sequence number in the MAC computation detects anything phony in that respect). See RFC 5246, end of section 6.1, and section 6.2.3.1. –  Thomas Pornin Jan 2 '13 at 21:57

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.