The "all odds in attackers favor" scenario
Attacker is in the same network as the victim, can monitor the network and can not only eavesdrop on the connection, but interfere with it. This is the case when the attacker can execute an ARP Spoofing attack against the victim. In this case, the attack is possible, and trivial against an unencrypted protocol like HTTP. Attacker can read every packet from the victim and the server, and can alter things when he wants to. He can tell H that he is the gateway, and alter packets going to the server. As he has the entire packet in his hands, he knows the TCP Sequence Numbers, all flags, options, and everything else. This is called Man in the Middle Attack. Attacker in another network
It's harder than guessing a 32-bit number. In this case, MH must guess the correct sequence number (a 32-bit number) AND craft the injected packet with the correct flags AND correct options AND have his packet reach the server before the package from H. As H and MH are not in the same network, MH will have to employ IP spoofing, and that is almost impossible to execute. As lots of routers have Egress Filtering, they will discard packets with a spoofed source address. Encrypted protocols
The same constraints as the other scenarios, but with a complication: attacker must forge an encrypted packet, guessing the cypher suite, all the encryption parameters, padding, IV, checksum, and have it merge seamlessly with the next packet coming from the client... No, it's not possible to inject data on an encrypted protocol and expect it to be accepted by the server or client. Server can find out that a packet is malicious because the content is not decrypted to the correct form.
No, the server finds the malicious packet because the TCP sequence number is incorrect, or correct but late (a newer packet already arrived), or much above the expected number plus the transmission window. If all those almost impossible to spoof values are correct, and encryption is employed, the server will discard the packet because it does not even remotely look like a valid one.TCP Injection is a complex protocol, so it's actually hard to bypass. Add an even more complex protocol on top of that (TLS/SSL) and you have an impossible task trying to inject spoofed packets on the communication.
