TL;TR: TLS is not broken beyond hope and there is no "fix to the ongoing security issues with ssl / tls" needed. Regular improvements are needed though but they are also done.
Seems like the methods we use to ensure secure information exchange with servers continually fail.
"continually fail" is in my opinion a very pessimistic and wrong interpretation. Fact is that most use of SSL/TLS is pretty secure, i.e. it is way more success than failure. But it is not perfect, mostly because the world today is different from when SSL/TLS was designed initially. And as the world is changing SSL/TLS needs to adapt to the changes and thus needs continues improvements: years ago state of the art was TLS 1.0, now it is TLS 1.2 and TLS 1.3 is arriving too.
Improvements to the TLS protocol and to the ciphers used are done usually way before potential issues really arise to a problem. While there were lots of issues in the past (CRIME, BREACH, POODLE....) these were merely theoretical attacks at the time, i.e. possible only within a narrow and usually unusual use case and/or they needed considerable resources. I would argue that none of these problems caused any security issue in practice when they were found - but they might have caused such problems later if they wouldn't have been fixed. Attacks get only easier with the time, both because attacks gets improved and because the resources needed (computing power, bandwidth) get easier and cheaper to acquire.
Contrary to this bugs in protocol implementations were much more serious, i.e. things like Heartbleed, goto fail or the schannel vulnerability caused real problems. But these were not bugs in the protocol as designed but bugs in the implementation.
As for the problems with certificate validation: These are actually not problems of SSL/TLS itself since how validation is done is not part of the TLS protocol at all. They are though issues to watch out when practically using SSL/TLS inside HTTPS or similar on the internet.
The problem with certificate validation is actually less a technical one but more a human one - whom to trust and how to scale trust and how much to trust. In the initial days of HTTPS usage there were only a few certificate authorities which had a strict certificate management. Impersonating sites using their certificates was not a real problem at this time since no sites actually required HTTPS, i.e. the attacker could simply use HTTP if needed.
Today the situation is different: most important sites require HTTPS and thus attacking certificate authorities to impersonate sites got more attractive and got actually real in many cases. To deter such attacks improvements like certificate transparency or certificate pinning or Certificate Authority Authorization (CAA) were developed and employed and also several certificate authorities with shoddy security were closed (i.e. no longer trusted by major browsers). Methods like OCSP stapling, OCSP must staple, CRLSets and use of short-lived but automatically updated certificates were propagated to address the growing problems with stolen certificates which need to be revoked. Thus it is the same as with TLS: it is not broken beyond hope but there is room for improvements and improvements get done.
Another issue is that the trust in TLS (HTTPS) got smaller with the years, less because of problems with the certificate authorities but more because of massive use of TLS: today it is easy and cheap/free to get certificates and it is expected in many cases that HTTPS is used. This means that also phishing sites get certificates today and malware gets delivered by HTTPS. While HTTPS was in the past often marketed as a signal that the site itself is secure this is no longer true and actually never was. Users need to understand that HTTPS only means that the content is protected during delivery, but that the protected content can still be malicious. But again, this is a sociological and usability problem and not a protocol problem.