Let's pretend we were using TLS, but with AES-CTR (with no MAC) instead of AES-GCM. AES-CTR is essentially a stream cipher, such that there's a keystream, generated by encrypting an incrementing counter with AES, and a plaintext, which are XORed together to get the ciphertext.
In this design, as with most stream ciphers, the attacker can modify the plaintext in as many bits as they like by simply flipping the bits in the ciphertext. That means that if we know the user is sending a GET
request, we can change that to a PUT
request simply by XORing the ciphertext with the result of GET
XOR PUT
. In addition, if we know the amount of data being sent (or whether this is the first request being made), we may be able to guess which page the client was on, in which case we might be able to change the contents of the page to load malicious JavaScript instead of the intended JavaScript.
In addition, in some cases, one of the machines acts as an oracle for us. For example, if I connect to machine A to make a request and it makes a request to machine B, sometimes if I tamper with the data, I can get machine A to return an error message which might contain secret information (say, the invalid session ID that I tampered with). In such a case, I could determine a valid session ID by determining which bytes I tampered with and then make requests to machine B without actually being authorized to do so.
All of these attacks can be applied to almost all other non-AEAD stream ciphers, such as ChaCha20 and the obsolete RC4, as well. They are all practical attacks in many cases, and they are all defeated using an AEAD or a MAC. As mentioned by DannyNiu in the comments, there are also interesting attacks on AES-CBC, such as the BEAST attack.