Simple Key Exchange, One Server

I am trying to better understand how TLS works. I understand in the normal use case you need various random values generated and used in the key exchange, to prevent some MITM reusing a previous transmission to spoof the server or the client.

However, let us assume some degenerate case where there is a single server whose single public key is already known by its clients as well as various adversaries. In this case, I would think all that is strictly speaking necessary to perform a secure key exchange would be the following:

1. Client uses server's public RSA key to encrypt random symmetric session key
2. Client sends server encrypted session key
3. Server decrypts session key using server's private RSA key
4. Server uses session key to encrypt a "finished" message
5. Server sends client encrypted "finished" message
6. Client uses session key to decrypt "finished" message
7. Client verifies message is "finished", handshake is complete

So in this simplified process, the only value changing each session is the session key itself, so no previous client or server random is used; and there is no pre-master secret, again only the session key.

This feels like a drastic oversimplification of things, but I am having trouble seeing what I am missing. If the main purpose of a key exchange is to make sure the server is the only one getting the session key, this seems to be secure. Proof by contradition, tracking the above process again, but from the perspective of an adversary:

1. Adversary already has the server's public key, could encrypt its own symmetric session key for MITM purposes
2. Adversary can see encrypted session key from client, but cannot decrypt it; can send server its own encrypted MITM session key
3. Server decrypts MITM session key, unaware of its origin
4. Server uses MITM session key to encrypt "finished"
5. Server sends client (in fact adversary) encrypted "finished"
6. Adversary can decrypt "finished", but cannot re-encrypt and send to client with client's session key, which adversary cannot decrypt
7. Client will ultimately never receive correctly encrypted "finished", either from server or adversary

So it seems the only potential weakness here is that the server has no way of knowing whether it is communicating with a legitimate client or an adversary - but as I understand it, authenticating the client was never in view to begin with. Authenticating the server is, but in this case that is not a concern since there is only a single server.

So am I correct in understanding that if one were to employ this scheme, it would be impossible for an adversary to perform a MITM attack? Or how could this be defeated?

One obvious issue with your 'degenerate case TLS' is that, as TLS is deployed, the client cannot be assumed to have apriori knowledge of the server's public key; that needs to be transferred (and authenticated) somehow.

However, your question was:

Or how could this be defeated?

Well, one obvious issue is that it is quite vulnerable to client-side replay attacks. Suppose the valid client performs a negotiation with the valid server, and then proceeds to send some commands. What an adversary could do is record what the client sent, and then later on, send those messages again. The server will perform exactly the same operations, generate the same symmetric keys, and then process the same encrypted commands. How bad it would be would depend on what those commands were - if it were a require to download a web page, not an issue - if it were a command to do a banking transaction, well, it probably would be somewhat of a problem.

The other issue (from the perspective of modern TLS) is that it lacks Perfect Forward Secrecy - if someone manages to steal the server's private key, not only could they masquerade as the server (which is inevitable; if you learn everything the server knows, you can do anything the valid server can), they can go back and decrypt previous sessions. Recent versions of TLS (specifically, TLS 1.3) don't allow an attacker to do that.