Is there any plan to replace this protocol with something more reliable, or is it that most problems are implementation-based and all those best practices/RFCs are there to mitigate possible human error?
There isn't a simple answer here, so I would "yes and no to all of the above". There are lots of factors at play.
Is TLS flawed?
Much like any other protocol (take HTTP or HTML for example) SSL/TLS is an evolving standard. Like any other protocol, it evolves to include:
- new features (ex. DNS CAA or OCSP which give higher security)
- performance enhancements (ex. OCSP stapling, and a lot of the TLS 1.3 stuff to improve speed and bandwidth usage)
- new use-cases that reflect the changing way in which the internet is built (ex. wildcard vs multi-domain vs multiple certs in a load-balanced cloud server context).
Unlike other protocols, TLS also needs to keep up with increases in the CPU power available to hackers, and cryptographic research (both research into new algorithms, and research into breaking existing algorithms). That's why you see new ciphers added, old ones dropped, and key sizes gradually increase.
I wouldn't say that TLS is flawed, but rather that, like any software, TLS is being improved over time to reflect the changing internet.
You are right to point out that most of the egregious vulnerabilities in TLS are not due to a problem with the TLS specification, but due to programmers not following that spec properly. Two examples come to mind:
Mining your Ps and Qs
The issue here is with (mainly) small embedded devices (think home routers or internet-enabled webcams) that need to generate TLS server keys on first boot-up. Turns out these devices all roll out of the factory almost identical, which means the keys they generate on first boot are not very random.
This is certainly a TLS vulnerability, but is not the fault of the TLS spec.
Here, the TLS spec (RFC 5246 section 188.8.131.52) gives very clear instructions for how to avoid Bleichenbacher-style attacks:
As described by Klima [KPR03], these vulnerabilities can be avoided
by treating incorrectly formatted message blocks and/or mismatched
version numbers in a manner indistinguishable from correctly
formatted RSA blocks. In other words:
1. Generate a string R of 46 random bytes
2. Decrypt the message to recover the plaintext M
3. If the PKCS#1 padding is not correct, or the length of message
M is not exactly 48 bytes:
pre_master_secret = ClientHello.client_version || R
else If ClientHello.client_version <= TLS 1.0, and version
number check is explicitly disabled:
pre_master_secret = M
pre_master_secret = ClientHello.client_version || M[2..47]
That's 3 pretty straight-forward steps. Turns out that the software developers behind a large number of the TLS implementations out there did not these steps properly, leading to vulnerabilities.
Again, his is certainly a TLS vulnerability, but is not the fault of the TLS spec.