0

If someone tampers with data being transmitted over HTTPS using TLS, would that result in a corrupted decrypted message or would it result in the error being detected such as through a cryptographic checksum and retransmitted?

This has security implications as well as accidental corruption implications (https://stackoverflow.com/questions/3830206/can-a-tcp-checksum-fail-to-detect-an-error-if-yes-how-is-this-dealt-with).

3

It depends on where the data was changed and all you mentioned outcomes are possible. TLS messages has some public scructure. For example, TLS record:

enter image description here

and if its structure is broken, then entire message is considered broken. This doesn't necessarily say if encrypted data was additionally tampered.

If only ciphertext was tampered so entire structure remains valid, it may result in decryption failure. If payload is tampered and was successfully decrypted, then signature validation will fail.

If MAC field is tampered, then it will result in signature validation failure. MAC protects only payload and is used only when payload is successfully decrypted.

Either way, tampering will be detected, only detection reason will be different depending on what exactly was tampered. RFC 5246 defines a set of messages:

enum {
   close_notify(0),
   unexpected_message(10),
   bad_record_mac(20),
   decryption_failed_RESERVED(21),
   record_overflow(22),
   decompression_failure(30),
   handshake_failure(40),
   no_certificate_RESERVED(41),
   bad_certificate(42),
   unsupported_certificate(43),
   certificate_revoked(44),
   certificate_expired(45),
   certificate_unknown(46),
   illegal_parameter(47),
   unknown_ca(48),
   access_denied(49),
   decode_error(50),
   decrypt_error(51),
   export_restriction_RESERVED(60),
   protocol_version(70),
   insufficient_security(71),
   internal_error(80),
   user_canceled(90),
   no_renegotiation(100),
   unsupported_extension(110),           /* new */
   (255)
} AlertDescription;
| improve this answer | |
  • Nobody should be using CBC cipher suites, so there is no decryption before the MAC is verified. The MAC is verified first. When a full record (up to 16KB) is received, the MAC is verified and if MAC verification fails then the data from the record is discarded and the connection reset. – Z.T. Mar 29 at 8:51
  • There was no question about what to use and what to not use and no context was provided. – Crypt32 Mar 29 at 8:53
  • My comment was about the line "If payload is tampered and was successfully decrypted, then signature validation will fail.". This is written as if CBC cipher suite is used, MAC-then-Encrypt, Decrypt-then-Verify. But in modern times, CBC cipher suite is not used. With modern AEAD, MAC is checked first. – Z.T. Mar 29 at 8: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.