14

I noticed that, while browsing through many bug bounty and vulnerability disclosure programs, they don't accept issues that are related to TLS/SSL, which includes expired security certificates.

Why are companies so unwilling to accept expired certificates, which can easily be fixed?

Peter Mortensen
  • 885
  • 5
  • 10
user17886134
  • 253
  • 1
  • 5
  • 3
    I've removed the part of your question which asks about the security implications of expired certificates since there are several highly voted question with answers about this already: https://security.stackexchange.com/questions/8394/expired-ssl-certificate-implications, https://security.stackexchange.com/questions/31463/why-do-we-not-trust-an-ssl-certificate-that-expired-recently, https://security.stackexchange.com/questions/117359/is-https-secure-over-public-wi-fi-with-an-expired-certificate – Steffen Ullrich Mar 02 '23 at 17:52
  • 6
    Because it's clearly not a "bug"? – hobbs Mar 03 '23 at 19:26

4 Answers4

41

Why are companies so unwilling to accept expired certificates, which can easily be fixed?

With proper certificate validation a client will not connect to a server which provides an expired certificate. This means that no data will be exchanged over the improperly secured connection. This also means that there is no actual security problem - only an availability problem.

Sure, there are clients which might ignore that the certificate is expired or users which skip browsers warnings. But in this case the real issue as improper certificate validation at the client side, not the expired certificate.

Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • 10
    Isn't availability considered one of the pillars of security? – Nacht Mar 03 '23 at 03:56
  • 12
    @Nacht That really depends on who you ask. All the entities I've seen refer to availability as a "pillar" of security never explain _why_ they consider it to be one. At least from a _security_ standpoint. If secure channels aren't functioning, lack of availability would be more secure, would it not? – Logarr Mar 03 '23 at 04:32
  • 3
    @Logarr I think including availability is to include DoS attacks, which don't really mess with the data itself but still would be considered by most to be a security issue – Radvylf Programs Mar 03 '23 at 04:36
  • 17
    Yes, DoS attacks being the common example... Perhaps the problem is more when an attacker can compromise your availability, whereas in this case, there is no attacker, the lack of availability is fully within your control. – Nacht Mar 03 '23 at 04:50
  • 2
    I like the definition of @Nacht - if an adversary can compromise availability, it is a security issue. It also depends on the use case. In classic IT environments, the triad is usually CIA in this order. Availability flies often under the radar with the exception of DoS. For OT, it is mostly AIC. A breach in confidentiality can be less severe than even a disturbance of availability. Here the availability becomes a major focus of the security folks. – fleitner Mar 03 '23 at 08:01
  • @nacht [mandatory Dilbert strip](https://dilbert.com/strip/2007-11-16) (and let's not talk about the author's recent political issues) – Mindwin Remember Monica Mar 03 '23 at 14:17
  • I never understood why people consider availability a security property. The only two reasons I've heard are a) "it loses the company money", but so does bad PR or being outcompeted in the market and nobody considers those security properties, and b) "the system can't serve its purpose without it", but that applies to everything, not just security systems. – Siguza Mar 04 '23 at 00:28
  • 4
    @Siguza There's a class of availability vulnerabilities that have much in common with other security issues: there's an attacker (as Nacht says) who maliciously provides some kind of input to the system that causes it to break in a harmful way. There are also availability issues that aren't particularly security-related (e.g. "what if the data center catches fire?"), but I can just as easily say there are confidentiality issues that aren't security-related ("what if a court orders us to reveal this?") and integrity issues that aren't security-related ("what if the database corrupts itself?") – Zach Lipton Mar 04 '23 at 02:01
  • 1
    @Siguza: *"I never understood why people consider availability a security property."* information security has a purpose - making sure that business processes work. And that's why information security has to consider the whole CIA triad: confidentially, integrity and availability of data. For example the main problem with traditional ransomware is that it impacts the availability of the data. That does not mean that every availability problem is an information security problem though – Steffen Ullrich Mar 04 '23 at 04:22
18

Other answers here have addressed the security side of expired certificates. I am going to address the bug bounty side of the question.

If the company's main/live domain(s) has an expired certificate; they sure know about it. Their tech support switchboard has just lit up with all these calls about an 'insecure site'.

If there is an expired cert (or even a self-signed cert) on one of their domains it is likely abandoned, or for internal use only.

Publishing a bug bounty scheme implies that the company is going to pay money for bug reports.

By being up front about excluding this sort of thing they stop low-effort scanners going over their domains and submitting bug reports. This has a dual effect of not wasting the company's time and preventing the negative publicity on social media when the person submitting the report doesn't get a payout.

Update:

As bta points out in their excellent comment, it would also be trivial to scan domains, save the current expiry date and revisit them again at that time in the hope of getting a bug report out of this.

I would also think that the restriction is merely a type of gatekeeping. If a seasoned security researcher spotted an actual problem; say a % of a company's application servers used an out of date version of - for example - OpenSSL that allowed downgrade attacks, that researcher would know enough about the situation to submit a report anyway. My guess is that such a report would be paid on, whatever the policy says.

Skrrp
  • 281
  • 1
  • 4
  • 6
    Not to mention, the certificate has an expiration date. Writing a script that waits until a certificate's date passes and then files a bug report on it is hardly the type of investigative work that bug bounties are designed to reward. – bta Mar 04 '23 at 01:34
  • @bta good point, well made. – Skrrp Mar 04 '23 at 01:38
8

SSL certificate expiration is a low-effort "just in case" measure against a possible SSL private key leak which theoretically allows to perform a MiTM attack which is not a small feat at all nowadays considering things like DoT/DoH/DNSSec. Serious hostile actors can hack people while being on the same LAN as them or by hacking any intermediate Internet provider/network which many (if not most) governments can do.

So, unless a SSL private key has been leaked, there's no vulnerability at all. In all honesty if your clients can stomach the "certificate has expired" warning, it's all good and secure.

user71659
  • 289
  • 2
  • 7
Artem S. Tashkinov
  • 2,217
  • 6
  • 17
0

TLDR: bug bountys are to tell me something that I don't know.

Expired SSL certs are an annoyance that can be automatically detected. there is no point to pay a human operator for something that can be monitored and predicted using automated software, or even a calendar.

Revoked certs are another matter these certs may indicate an actual risk, but these are still detectable by automated means.

Nevertheless in both cases if they are not detected by IT staff they will likely be reported by users almost immediately when they cease to work, so bug bounty reports will only be duplicating something that is already known.

Jasen
  • 931
  • 5
  • 9