As i understand it, PKI with an asymetric key approach is much more secure than a symetric key encryption.
This is wrong. If anything, asymmetric cryptography is less secure than symmetric cryptography: it's harder to do implement asymmetric cryptography than symmetric cryptography (I'm not going to compare the internal design of the algorithms), and more attacks threaten asymmetric cryptography (for example, if we figure out how to make quantum computers, that will break all the asymmetric cryptography that's in use today, whereas for symmetric cryptography we'll just need to stop using small keys).
But mostly symmetric cryptography and asymmetric cryptography solve different problems, so you can't compare them that way.
In particular, for TLS, the usual setup is that the client knows what server it wants to connect, but the server doesn't know anything about the client that's connecting to it. And at a minimum, the security goal is that the client knows what server it has actually connected to, to avoid a man-in-the-middle attack. In this scenario, symmetric cryptography is not enough: the client needs to know some cryptographic value that's specific to the server. This can't be a secret key that's already shared between the client and the server because the server doesn't know anything about the client. And it can't be a secret key that's shared with many clients in addition to the server because that would allow the client to impersonate the server when talking to other clients. Therefore the only solution is to use asymmetric cryptography, where the client knows a public key of the server which does not allow it to reconstruct the private key that only the server knows. A public key infrastructure is a way for the client to find out the server's public key from the server's name.
So why do we exchange the pre-master secret?
The client and the server need to decide on a secret key. The client knows the server's public key, and needs to be able to construct the pre-master secret (the shared secret key) from the server's public key plus whatever data the server sends. The server knows its private key and needs to be able to construct the pre-master secret from that plus whatever the client sends. There are several ways to do that.
couldnt we just encrypt the shared secret (key for symetric encryption)? The client could come up with a random key, encrypt it with the public key (found within the public certificate) and the server could decrypt it with the private key.
Yes, that's possible, with an asymmetric cryptography construct that can do asymmetric encryption (encrypt with a public key, decrypt with the corresponding private key). Since only the server has a public key, this means the client generates a random key, encrypts it, and sends it to the server, which decrypts it. An attacker who sees or even changes the messages in transit won't be able to obtain the shared key since it can't decrypt the shared secret chosen by the client. Note that it is still necessary to protect against other attacks, such as repeating a server's messages; I won't go into what this requires in terms of protocol design.
This method exists in TLS: that's how the cipher suites that use RSA but not (EC)DH work. It has several downsides, which led to this method being abandoned in TLS 1.3:
- In terms of security, this approach lacks forward secrecy. This is the property that if an attacker records all communications that a server makes, and later manages to breach the server and obtain its private key, then the attacker can decrypt all past communication. This is fundamentally possible with any approach where the client chooses the shared key on its own, since the only secret data that the server has to calculate the shared key is its private key.
- Similarly, this approach allows a middle-box to decrypt traffic if it knows the server's private key. Whether this is a good thing depends if you're a security administrator who is more concerned with knowing exactly what information is exfiltered from your organization (middle-box good) or anyone else (middle-box bad). Anyone else includes a security administrator who's concerned about the organization being vulnerable to impersonated servers: that's harder to defend against when a middle-box gets involved.
- In addition, asymmetric decryption is intrinsically difficult to implement securely. The decryptor uses its private key on a message which is coming from outside and could be coming from an attacker. Any design flaw in the algorithm or in the implementation can give a way for the attacker to obtain information about the private key. Signature is safer in this respect because the private key is used on a message that is generated internally and so has a known format.
- To make matters worse, TLS standardized a particular method for RSA encryption which is extremely hard to implement securely: PKCS#1 v1.5. This approach is vulnerable to a padding oracle attack, known as Bleichenbacher's attack (one of them, and by far the most far-reaching one). Refinements on this attack have been present in real-world applications for more than 20 years. And even if you manage to implement PKCS#1v1.5 decryption as a secure black box, the way TLS uses it is itself vulnerable to the same attack. In contrast, OAEP (a more modern RSA-based encryption scheme) is vulnerable to a similar attack, but there's a much smaller core that it's sufficient to get right. And standard RSA-based signatures, including PKCS#1v1.5 signature, are not vulnerable to any similar attack, for the reason I explain in the previous bullet point.
- Today, a lot of systems use elliptic-curve cryptography instead of RSA and non-EC Diffie-Hellman. ECC has significantly faster private-key operations, smaller signatures (so less data to exchange), but slower public-key operations. In terms of performance, RSA is only preferable to ECC if signature/decryption speed doesn't matter, encryption/verification speed is critical, and message size isn't a concern. Thus ECC is almost always preferable for performance. And ECC doesn't have a way to directly encrypt a message the way RSA does: the way to encrypt data with ECC, standardized as ECIES, is to do a key agreement and then encrypt the data with the resulting shared secret — which you can bypass if your only goal is to establish a shared secret.
The key exchange ensures the use of PFS which in return means that PFS is used in all TLS connections (which i think is true for TLS 1.3)
That's true for all TLS cipher suites that use ephemeral Diffie-Hellman (whether using elliptic curves or classic finite fields), i.e. all TLS ≤1.2 cipher suites with DHE or ECDHE in their name, and all TLS 1.3 cipher suites.
The PKI thing is only used for verification that the cert comes from where it says it comes from (denying a man in the middle attack)
That's correct. The DH key exchange establishes a shared key, and the client uses its knowledge of the server's public key to check that the shared key was indeed established with the desired server, rather than with a man-in-the-middle attacker.
It would be viewed as a secure way, but the key exchange was implemented to increase the security, should some process fail in the future
Decryption-based TLS is not fundamentally insecure as far as the basic properties of TLS are concerned (resistance against man-in-the-middle attacks), but it's hard to get right and there's a security property (PFS) it cannot achieve at all.
