Will You Trust This TLS Certificate?

Abstract

Flawed TLS certificates are not uncommon on the Internet. While they signal a potential issue, in most cases they have benign causes (e.g., misconfiguration or even deliberate deployment). This adds fuzziness to the decision on whether to trust a connection or not. Little is known about perceptions of flawed certificates by IT professionals, even though their decisions impact high numbers of end users. Moreover, it is unclear how much the content of error messages and documentation influences these perceptions. To shed light on these issues, we observed 75 attendees of an industrial IT conference investigating different certificate validation errors. We also analyzed the influence of reworded error messages and redesigned documentation. We find that people working in IT have very nuanced opinions, with trust decisions being far from binary. The self-signed and the name-constrained certificates seem to be over-trusted (the latter also being poorly understood). We show that even small changes in existing error messages can positively influence resource use, comprehension, and trust assessment. At the end of the article, we summarize lessons learned from conducting usable security studies with IT professionals.

Assessing Real-World Applicability of Redesigned Developer Documentation for Certificate Validation Errors

“…However, the current documentation of certificate validation errors is too short. The survey of OpenSSL, GnuTLS, Botan, mbedTLS and Microsoft CryptoAPI by Ukrop et al [30] shows neither of these libraries has a median length of the certificate validation error message over eight words. The corresponding section in the documentation (if it exists) is only a tad longer, with the median of eight (mbedTLS), nine (OpenSSL, GnuTLS) or sixteen (MS Cryp-toAPI) words.…”

“…Apart from the error message in the log, they usually consult the official documentation or browse the Internet. On the one hand, as of 2021, the documentation of the certificate validation errors was extremely poor -the median length of an error message in commonly used libraries was just six words, with the official documentation having on average only thirteen words [30]. On the other hand, using informal online resources instead of the documentation was shown to lead to less secure code [2].…”