1 / 25

Using SSL/TLS Client Certificates for User Authentication

Using SSL/TLS Client Certificates for User Authentication. 22 nd March 2006 Robert Loomans robertl@apnic.net. Overview. Background Why? What? How? Lessons learned Future Conclusion Q & A. Background.

kasa
Télécharger la présentation

Using SSL/TLS Client Certificates for User Authentication

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Using SSL/TLS Client Certificates for User Authentication 22nd March 2006 Robert Loomans robertl@apnic.net

  2. Overview • Background • Why? • What? • How? • Lessons learned • Future • Conclusion • Q & A

  3. Background • In 2001, APNIC decided to develop a secured web portal (MyAPNIC) to allow its members self manage their account information • username/password is not sufficient to protect the access • Leverage SSL and PKI/X.509 technology to authenticate users • An application framework was developed to handle user authentication and authorisation • This application framework is then used to develop various web applications such as: • MyAPNIC • Meeting/events registration system • Resource management system (internal use)

  4. What we did • OpenCA • Hardware crypto engine • Apache 2.0 including mod_ssl • Use Apache config for authentication • Custom web framework for authorisation • Mapping to APNIC member using cert serial (Don’t do this!) • Email expiry reminders

  5. Why use client certificates? • Something the user has, not knows • Best case: cert installed on a smart card • Strong identification • Well, assuming you want it, and it’s part of your process • Revokable • Limited validity • Data in the cert is signed by the issuer • User only controls the use of the private key • Can support capabilities • Security policy must be explicit • Certificate Policy (CP) and Certification Policy Statement (CPS)

  6. Cons • More effort for operator • Running the PKI • Processes and procedures • User and operator education • Browser problems and differences • More effort for users • More process for requesting and renewing certificates • Reduced portability • Browser problems and differences

  7. What don’t client certificates help with? • Clueless users • Clueless staff • Poor network security • Poor application security • Poor security policy • Rapid turnaround

  8. What are they? • X.509 v3 Certificates • ASN.1 • Extensible • RFC3280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile • RFC4325 - Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension

  9. Example Certificate

  10. Example Certificate (cont.)

  11. Example Certificate (cont.)

  12. What are they? (cont) • Distinguishing Name (DN) • Subject • Issuer • Certificate Revocation List (CRL) • Serial • X509 V3 Extensions vs. Netscape Extensions • Alternative Name vs. Common Name • CRL Distribution Points vs. Revocation URL • Key Usage • CA bit • Validity

  13. What do you need? • SSL enabled web server • User database • PKI • Public interface • Request Authority • Certificate Authority • Repository • Policies • Processes and procedures

  14. PKI • PKIX-WG -http://www.ietf.org/html.charters/pkix-charter.html • OpenCA - http://www.openca.org/ • TinyCA - http://tinyca.sm-zone.net/

  15. Apache configuration • Normal SSL configuration to serve HTTPS • SSLCACertificateFile file-path or SSLCACertificatePath directory-path • SSLCARevocationFile file-path or SSLCARevocationPath directory-path • SSLVerifyClient level • none • optional • require • SSLVerifyDepth number

  16. Apache configuration (cont.) • CRL? • Definitely for static content • Otherwise, maybe • SSLOptions • FakeBasicAuth • StrictRequire • OptRenegotiate • StdEnvVars

  17. Apache configuration (cont.) • SSLRequire

  18. Example Apache config

  19. Example Apache config (cont.)

  20. 6. Process user input 1. Initialise C V .html 5. Parse template & transmit The MainProcessor (.cgi) Header 2. Read ST 4. Load Components M Component A • Session Table • State • Component • User 3. Read PDT Menu Component B Core Objects (.pm) Library Component C • Page Descriptor Table • Template file • Components • Security Attributes The application framework authenticate authorise

  21. Application configuration • Authorisation • Users • Credentials ↔ User • More than one mapping?

  22. Lessons learnt • Use Distinguishing Name, not Serial • Serial is unique, but it changes on renewal • DN can be identical over renewal • Who/what are you certifying and/or identifying? • What guarantees are you making, for what purpose and to whom? • Possibly use FakeBasicAuth

  23. Future • Segment certificates for different types of users • Different issuers • Different names • Looser coupling between user identity and authorisation • Browsers don’t deal nicely with choosing between certificates

  24. Conclusion • Increased security… maybe • Very flexible • Extra effort for operator and users • Processes • Education • Browser support

  25. Questions?

More Related