0

When transferring a large file over network, its likely that the file is broken into packets and then transferred. The underlying network protocol, lets consider the case of TLS/SSL, it generates MACs for the individual packets, the receiving party compares the MAC and is guaranteed that the MAC of individual pieces are correct. Does this ensure that the complete file on transfer is not corrupt, assuming no packet/chunk is lost on wire?

3

The MAC in SSL/TLS is computed over the combination of the record payload and a sequence number, thus ensuring that records are all received, with no missing, out-of-order or duplicated record. The connection is also terminated with an explicit close_notify alert, which is itself part of the protected records, thus cannot be faked by attackers.

See the standard, section 6.3.2.1:

   The MAC is generated as:

      MAC(MAC_write_key, seq_num +
                            TLSCompressed.type +
                            TLSCompressed.version +
                            TLSCompressed.length +
                            TLSCompressed.fragment);

   where "+" denotes concatenation.

   seq_num
      The sequence number for this record.
  • right, so, assuming there is no flaw in security does that ensures the integrity of whole file, if individual records of file are verified and assembled correctly by receiver? – prasun Oct 28 '15 at 18:58
  • 1
    The point of the sequence number is indeed to guarantee that the complete stream of bytes is correct, even if each MAC is computed only over a single record. – Thomas Pornin Oct 28 '15 at 19:09
  • got you, that said, individual fragments and even re-assembling sequence numbers are protected, so, that ensures complete integrity! – prasun Oct 28 '15 at 19:14
2

As in the other answers, SSL/TLS protects against corruption or tampering of the file in transit.

However, it's still possible for the file to be corrupted in memory or on disk at either end, so for critical data (firmware comes to mind, where a wrong bit could brick a device), checksumming is still a very good idea - but not a 'security' issue as such.

  • +1 for considering that transmitting data is more than simply following a protocol spec. Remember also that TCP/SSL/ etc are all models. Real code has errors in it, so it never hurts to make double check that the whole equals the sum of the parts. – Steve Sether Feb 29 '16 at 20:59
  • That too. Hadn't considered implementation errors. – SomeoneSomewhereSupportsMonica Feb 29 '16 at 21:04
0

You need to have a way to keep track of order of pieces and also make sure you get all pieces. A sequence number, checked end-to-end can probably solve this. Also, you need to make sure that no piece is replayed, so you also need to verify freshness.

  • lets say TLS/SSL is already ensuring that replays are not happening (I am talking about ideal scenarios, it would be hard to break TLS in normal scenarios as well) and I am already assuming that there is no packet drop (please see my question) – prasun Oct 28 '15 at 18:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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