-2

Seems like the methods we use to ensure secure information exchange with servers continually fail. Given the ongoing issues with SSL / TLS and the ever changing methods to fix issues such as:

  • HTTP Public Key Pinning - to better delineate the correct public key by its signature.
  • Certificate Transparency - an X509 certificate extension
  • deprecation or elimination of versions of SSL and TLS
  • various other fixes for other system vulnerabilities

It seems safe to say the that the PKI infrastructure is in a bad state of affairs (on the verge of collapse) when it apparent that we can not even tell which Certificate / Public key is valid.

So is there actually a realistic fix for the ongoing SSL / TLS issues?

There is a lot of motion but no indication that the issues are being resolved!

closed as too broad by StackzOfZtuff, forest, Overmind, ThoriumBR, billc.cn Jun 8 '18 at 13:36

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • HPKP seems to loose steam (support removed in latest Chrome browser) and instead HSTS and HSTS preloading have the favors of the world. – Patrick Mevzek May 31 '18 at 21:57
  • You also forgot to mention everything related to the DNS, like DANE and its TLSA records, or CAA (Let's Encrypt just added support for it, to restrict the validation mechanisms possible per domain). And of course, you forgot to mention the upcoming TLS 1.3 that changes many things. SSL is dead and should not be used anywhere anymore, its name should not be used anymore. – Patrick Mevzek May 31 '18 at 21:58
  • @PatrickMevzek Unfortunately, HSTS helps against simple MITM attacks, but not against a single rogue or hacked CA (which HPKP protects from). Even CAA requires the CA be honest, so really only helps with accidental certificate issuance. – forest May 31 '18 at 23:36
  • @forest Then see DANE and its TLSA records: each domain name can exactly specify which certificate (or which authority certificate) it allows to be used to contact it. – Patrick Mevzek Jun 1 '18 at 0:10
  • @PatrickMevzek DANE isn't supported by most clients, is it? – forest Jun 1 '18 at 0:11
12

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.

  • I accept your answer as obviously I approached my question in to broad a fashion. The issue IMHO remains a general SSL / TLS issue as the identification of the correct certificate utilizing the tools and revocation lists or Certificate Transparency or HPKP (public key pinning) or ?? seems to be on the road to nowhere. In short if you can not trust the certificate and key then the entire exercise is of no use. I will focus the question better and resubmit. – Surly Canuck Jun 1 '18 at 3:58

Not the answer you're looking for? Browse other questions tagged or ask your own question.