Skip to main content
Log in

Analyzing proposals for improving authentication on the TLS-/SSL-protected Web

  • Special Issue Paper
  • Published:
International Journal of Information Security Aims and scope Submit manuscript

Abstract

“Secure” Web browsing with HTTPS uses TLS/SSL and X.509 certificates to provide authenticated, confidential communication between Web clients and Web servers. The authentication component of the system has a variety of weaknesses, which have led to a variety of proposals for improving the current environment. In this paper, we survey, analyze, compare and contrast five prominent proposals. To do this, we attempt to systematically capture the properties one might require of such a system: authentication properties, forensics/privacy properties, usability properties and pragmatic properties. Enumerating these properties is an important part of understanding these proposals and the nature of the authentication problem for the secure Web. Finally, we offer a few conclusions and suggestions pertaining to these proposals and possible future directions of research.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Fig. 1

Similar content being viewed by others

Notes

  1. The responsibility for managing trust anchors falls to some combination of browser vendors, OS vendors, users and, perhaps, IT support departments.

  2. This article is only concerned with server authentication, so client-authentication properties are not addressed.

  3. Draft revisions of the RFC address some of the issues raised here. This evaluation notes server privacy as an issue—a legitimate server needs to announce its presence by submitting its certificate to a public logfile server. To address this, draft revision 3 of the RFC includes a mechanism for redacting portions of the domain name in the certificate information submitted to a logfile server. For example, if the domain name in the certificate was super.secret.example.com, the information submitted to the logfile server might be (PRIVATE).example.com. Another mechanism added in the draft that addresses this problem is logging a name-constrained intermediate authority, along with a field that explicitly allows the SCT for the intermediate authority to stand in lieu of an SCT for the end-entity certificate. Thus, the situation above might be handled be having super.secret.example.com send an SCT for an intermediate CA constrained to example.com. Concerns raised here regarding the Minimal Impact and Minimal Server Roadblocks Properties are addressed in draft revision 3 by providing a mechanism for including a server’s SCT in its certificate. This way, the server/server owner does not necessarily need to change or do anything different in order for CT to be used. Instead, CA’s could make sure SCTs are bundled in the certificates they issue, and servers simply send those certificates as they always do. Of course, this creates a chicken-and-egg problem: the CA needs the SCT to create the certificate, but the logfile server needs the certificate to create the SCT. To deal with this, draft revision 3 allows CA’s to submit “pre-certificates” to the logfile server, which contain enough information for the logfile server to create an SCT. The SCT gets sent back to the CA, which then can complete the certificate. Because these mechanisms are only described in draft revisions under very active development, we are not including them in our analysis.

  4. Depending on the TLS cipher-suite, the second use of the key may instead be to verify that an ephemeral key belongs to the server.

  5. Client-directed pinning would ensure that the certificate had not changed since the client’s last connection to the site, and OCSP stapling would ensure that the certificate had not been revoked—at least as of some reasonably recent point in the past. Online Certificate Status Protocol (OCSP) stapling is a piece of the modern certificate infrastructure. It allows a server to send clients a message, signed by the relevant certificate authority, that asserts that as of a certain point in time, the server’s certificate has not been revoked. This is a nice alternative to contacting OCSP servers to check for revocation, or either pushing or pulling blacklists.

References

  1. Dierks, T., Rescorla, E.: The transport layer security (TLS) protocol version 1.1. RFC 5246, RFC Editor (2006)

  2. Housley, R., Santesson, S.: Update to directorystring processing in the internet X.509 public key infrastructure certificate and certificate revocation list (CRL) profile. RFC 5280, RFC Editor (2006)

  3. Herley, C.: So long, and no thanks for the externalities: the rational rejection of security advice by users. In: Proceedings of the 2009 Workshop on New Security Paradigms Workshop, NSPW ’09, New York, NY, USA, pp. 133–144. ACM (2009)

  4. Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., Cranor, L.F.: Crying wolf: an empirical study of ssl warning effectiveness. In: Proceedings of the 18th Conference on USENIX Security Symposium, SSYM’09, Berkeley, CA, USA, pp. 399–416. USENIX Association (2009)

  5. CA/Browser Forum. Guidelines for the issuance and management of extended validation certificates (2014). https://cabforum.org/wp-content/uploads/EV-V1_5_2Libre

  6. Hoffman, P., Schlyter, J.: The DNS-based authentication of named entities (DANE) transport layer security (tls) protocol: TLSA. RFC 6698, RFC Editor (2012)

  7. National Institute of Standards and Technology (NIST) http://www.dnsops.gov/dnssec-perform.html

  8. Laurie, B., Langley, A., Kasper, E.: Certificate transparency. RFC 6962, RFC Editor (2013)

  9. Evans, C., Palmer, C., Sleevi, R.: Public key pinning extension for http. Internet-Draft draft-ietf-websec-key-pinning-21, IETF Secretariat (2014)

  10. Barker, E., Barker, W., Burr, W., Polk, W., Smid, M.: Recommendation for key management—part 1: general (revision 3). Technical Report NIST Special Publication 800–57, National Institute of Standards and Technology (2007)

  11. Marlinspike, M., Perrin, T.: Trust assertions for certificate keys. Internet-Draft draft-perrin-tls-tack-02, IETF Secretariat (2013)

  12. Wendlandt, D., Andersen, D.G., Perrig, A.: Perspectives: improving ssh-style host authentication with multi-path probing. In: USENIX 2008 Annual Technical Conference on Annual Technical Conference, ATC’08, Berkeley, CA, USA, pp. 321–334. USENIX Association (2008)

  13. Kaminski, D.: These are not the certs you’re looking for. Personal blog (2011). http://dankaminsky.com/2011/08/31/notnotar/

  14. The ICSI Certificate Notary. http://notary.icsi.berkeley.edu/

Download references

Acknowledgments

The first author’s research related to this work was carried out at the National Security Agency under the Sabbatical program administered by the Mathematical Sciences Program. The US Government is authorized to reproduce and distribute reprints notwithstanding any copyright notation herein.

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Christopher W. Brown.

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Brown, C.W., Jenkins, M. Analyzing proposals for improving authentication on the TLS-/SSL-protected Web. Int. J. Inf. Secur. 15, 621–635 (2016). https://doi.org/10.1007/s10207-016-0316-2

Download citation

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s10207-016-0316-2

Keywords

Navigation