DOCSLIB.ORG

Digicert® SSL/TLS Best Practice Workshop Student Guide 2021-02 V1

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Digicert® SSL/TLS Best Practice Workshop Student Guide 2021-02 V1 DigiCert® SSL/TLS Best Practice Workshop Student Guide 2021-02 v1 © 2021 DigiCert, Inc. All rights reserved. DigiCert is a registered trademark of DigiCert, Inc. in the USA and elsewhere. All other trademarks and registered trademarks are the property of their respective owners. DIGICERT® BEST PRACTICE WORKSHOP 1 Table of Contents Acronyms ................................................................................................................................................ 5 Introduction ............................................................................................................................................ 6 SSL Overview ........................................................................................................................................... 8 SSL & TLS ............................................................................................................................................. 8 Domain Name System (DNS) ............................................................................................................ 14 SSL Certificates .................................................................................................................................. 15 Subject........................................................................................................................................... 16 Certificate Extensions ................................................................................................................... 16 Certificate Formats ........................................................................................................................... 17 Certificate Signing Request (CSR) .................................................................................................. 18 SAN & Wildcard ............................................................................................................................. 19 Public SSL Certificates ....................................................................................................................... 20 DV Certificates............................................................................................................................... 21 OV Certificates .............................................................................................................................. 21 EV Certificates ............................................................................................................................... 22 Domain Validation ........................................................................................................................ 23 Organisation Validation ................................................................................................................ 26 Extended Validation ...................................................................................................................... 27 How SSL Works ................................................................................................................................. 28 SSL Handshake .............................................................................................................................. 32 Authority Information Access (AIA) .............................................................................................. 34 Certificate Revocation List (CRL) ................................................................................................... 38 Online Certificate Status Protocol (OCSP) ..................................................................................... 39 SSL Protocols & Algorithms ............................................................................................................... 42 RSA ................................................................................................................................................ 42 Diffie-Hellman ............................................................................................................................... 44 Elliptic Curve Cryptography ........................................................................................................... 45 SSL Handshake Details ...................................................................................................................... 45 Session Resumption ...................................................................................................................... 49 Forward Secrecy ................................................................................................................................ 50 Cipher Suites ..................................................................................................................................... 54 SSL Risks & Vulnerabilities .................................................................................................................... 56 Expired/misconfigured Certificates .................................................................................................. 56 Self-signed & Vendor Certificates ..................................................................................................... 59 DIGICERT® BEST PRACTICE WORKSHOP 2 Attacks on SSL ................................................................................................................................... 61 Phishing ............................................................................................................................................. 64 Attacks on Certificate Authorities ..................................................................................................... 67 Case Studies ...................................................................................................................................... 68 Industry Trends ..................................................................................................................................... 70 CA/Browser Forum Requirements .................................................................................................... 70 Certificate Transparency (CT)............................................................................................................ 72 Certificate Authority Authorization (CAA) ........................................................................................ 78 Examples ....................................................................................................................................... 79 Certificate Pinning ............................................................................................................................. 80 What can go wrong with Certificate Pinning? .............................................................................. 81 Enforcing HTTPS ................................................................................................................................ 82 “Always-on” SSL ................................................................................................................................ 86 HTTP/2 .............................................................................................................................................. 87 Encrypting DNS: DoH & DoT ............................................................................................................. 88 Signed HTTP Exchanges (SXG) ........................................................................................................... 89 Implementing SXG......................................................................................................................... 90 Delegated Credentials ....................................................................................................................... 91 Automatic Certificate Management Environment (ACME) .............................................................. 92 SSL/TLS Best Practice ............................................................................................................................ 93 Security ............................................................................................................................................. 93 Identify .......................................................................................................................................... 94 Remediate ..................................................................................................................................... 95 Protect ........................................................................................................................................... 97 Monitor ......................................................................................................................................... 99 Performance ................................................................................................................................... 100 Optimize cryptography ............................................................................................................... 100 Use session resumption .............................................................................................................. 101 Use HTTP/2 ................................................................................................................................. 101 Use a CDN...................................................................................................................................
Load more

Recommended publications
  • SSL/TLS Implementation CIO-IT Security-14-69
    DocuSign Envelope ID: BE043513-5C38-4412-A2D5-93679CF7A69A IT Security Procedural Guide: SSL/TLS Implementation CIO-IT Security-14-69 Revision 6 April 6, 2021 Office of the Chief Information Security Officer DocuSign Envelope ID: BE043513-5C38-4412-A2D5-93679CF7A69A CIO-IT Security-14-69, Revision 6 SSL/TLS Implementation VERSION HISTORY/CHANGE RECORD Person Page Change Posting Change Reason for Change Number of Number Change Change Initial Version – December 24, 2014 N/A ISE New guide created Revision 1 – March 15, 2016 1 Salamon Administrative updates to Clarify relationship between this 2-4 align/reference to the current guide and CIO-IT Security-09-43 version of the GSA IT Security Policy and to CIO-IT Security-09-43, IT Security Procedural Guide: Key Management 2 Berlas / Updated recommendation for Clarification of requirements 7 Salamon obtaining and using certificates 3 Salamon Integrated with OMB M-15-13 and New OMB Policy 9 related TLS implementation guidance 4 Berlas / Updates to clarify TLS protocol Clarification of guidance 11-12 Salamon recommendations 5 Berlas / Updated based on stakeholder Stakeholder review / input Throughout Salamon review / input 6 Klemens/ Formatting, editing, review revisions Update to current format and Throughout Cozart- style Ramos Revision 2 – October 11, 2016 1 Berlas / Allow use of TLS 1.0 for certain Clarification of guidance Throughout Salamon server through June 2018 Revision 3 – April 30, 2018 1 Berlas / Remove RSA ciphers from approved ROBOT vulnerability affected 4-6 Salamon cipher stack
    [Show full text]
  • Using Frankencerts for Automated Adversarial Testing of Certificate
    Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations Chad Brubaker ∗ y Suman Janay Baishakhi Rayz Sarfraz Khurshidy Vitaly Shmatikovy ∗Google yThe University of Texas at Austin zUniversity of California, Davis Abstract—Modern network security rests on the Secure Sock- many open-source implementations of SSL/TLS are available ets Layer (SSL) and Transport Layer Security (TLS) protocols. for developers who need to incorporate SSL/TLS into their Distributed systems, mobile and desktop applications, embedded software: OpenSSL, NSS, GnuTLS, CyaSSL, PolarSSL, Ma- devices, and all of secure Web rely on SSL/TLS for protection trixSSL, cryptlib, and several others. Several Web browsers against network attacks. This protection critically depends on include their own, proprietary implementations. whether SSL/TLS clients correctly validate X.509 certificates presented by servers during the SSL/TLS handshake protocol. In this paper, we focus on server authentication, which We design, implement, and apply the first methodology for is the only protection against man-in-the-middle and other large-scale testing of certificate validation logic in SSL/TLS server impersonation attacks, and thus essential for HTTPS implementations. Our first ingredient is “frankencerts,” synthetic and virtually any other application of SSL/TLS. Server authen- certificates that are randomly mutated from parts of real cer- tication in SSL/TLS depends entirely on a single step in the tificates and thus include unusual combinations of extensions handshake protocol. As part of its “Server Hello” message, and constraints. Our second ingredient is differential testing: if the server presents an X.509 certificate with its public key.
    [Show full text]
  • Adopting Encrypted DNS in Enterprise Environments
    National Security Agency | Cybersecurity Information Adopting Encrypted DNS in Enterprise Environments Executive summary Use of the Internet relies on translating domain names (like “nsa.gov”) to Internet Protocol addresses. This is the job of the Domain Name System (DNS). In the past, DNS lookups were generally unencrypted, since they have to be handled by the network to direct traffic to the right locations. DNS over Hypertext Transfer Protocol over Transport Layer Security (HTTPS), often referred to as DNS over HTTPS (DoH), encrypts DNS requests by using HTTPS to provide privacy, integrity, and “last mile” source authentication with a client’s DNS resolver. It is useful to prevent eavesdropping and manipulation of DNS traffic. While DoH can help protect the privacy of DNS requests and the integrity of responses, enterprises that use DoH will lose some of the control needed to govern DNS usage within their networks unless they allow only their chosen DoH resolver to be used. Enterprise DNS controls can prevent numerous threat techniques used by cyber threat actors for initial access, command and control, and exfiltration. Using DoH with external resolvers can be good for home or mobile users and networks that do not use DNS security controls. For enterprise networks, however, NSA recommends using only designated enterprise DNS resolvers in order to properly leverage essential enterprise cybersecurity defenses, facilitate access to local network resources, and protect internal network information. The enterprise DNS resolver may be either an enterprise-operated DNS server or an externally hosted service. Either way, the enterprise resolver should support encrypted DNS requests, such as DoH, for local privacy and integrity protections, but all other encrypted DNS resolvers should be disabled and blocked.
    [Show full text]
  • Installing Fake Root Keys in a PC
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Royal Holloway - Pure Installing Fake Root Keys in a PC Adil Alsaid and Chris J. Mitchell Information Security Group Royal Holloway, University of London Egham, Surrey TW20 0EX fA.Alsaid, [email protected] Abstract. If a malicious party can insert a self-issued CA public key into the list of root public keys stored in a PC, then this party could potentially do considerable harm to that PC. In this paper, we present a way to achieve such an attack for the Internet Explorer web browser root key store, which avoids attracting the user's attention. A realisation of this attack is also described. Finally, countermeasures that can be deployed to prevent such an attack are outlined. 1 Introduction As is widely known [10], most web browsers (e.g. Microsoft Internet Explorer or Netscape) have a repository of root public keys designed for use in verify- ing digitally signed public key certi¯cates. These public keys are bundled with distributions of the web browser, and are used to verify certi¯cates for applet providers [13]. Speci¯cally, web-sites may download applets to a user PC without the PC user knowing it. Depending on the security settings selected by the PC user, these applets may be executed with or without further checks. Typically, the browser will only execute the applet if the following conditions are satis¯ed. 1. The applet must be digitally signed, and the signature must verify correctly. 2.
    [Show full text]
  • Measuring the Rapid Growth of HSTS and HPKP Deployments
    Measuring the Rapid Growth of HSTS and HPKP Deployments Ivan Petrov∗ Denis Peskov∗ Gregory Coard∗ Taejoong Chungy David Choffnesy Dave Levin∗ Bruce M. Maggsz Alan Mislovey Christo Wilsony ∗ University of Maryland yNortheastern University zDuke University & Akamai Technologies ABSTRACT version of the website, thereby exposing future commu- A basic man-in-the-middle attack to bypass HTTPS strips nication to the MiTM attacker, as well. Second, if an the “s” off of an “https://” URL, thereby forcing the client attacker is able to have a certificate created in someone to effectively downgrade to an insecure connection. To ad- else's name, the attacker can impersonate that victim dress such crude attacks, the HSTS (HTTP Strict Transport domain. Security) protocol was recently introduced, which instructs Both of these attacks completely sidestep the protec- clients to preemptively (or at time of first acquire) load a tions that TLS seeks to provide to its users. To address list of domains to whom to connect strictly via HTTPS. In a these concerns, two recent additions to HTTPS have similar vein, the HPKP (HTTP Public Key Pinning) protocol been introduced. We describe them in detail in Sec- has clients obtain a set of public keys; if in future visits to tion 2, but at a high level: the website the certificate chain does not include any of those • HTTP Strict Transport Security public keys, the client is supposed to reject the connection. (HSTS) [10] addresses SSL stripping attacks by Both HSTS and HPKP are relatively new additions to the informing clients which domains it should connect web’s PKI that have seen a sudden surge in deployment in to strictly over HTTPS (i.e., if presented with an the last couple of years (we observe an order of magnitude http URL to one of these domains, they should greater deployment than a 2015 study of HSTS/HPKP).
    [Show full text]
  • Quantitative Verification of Gossip Protocols for Certificate Transparency
    QUANTITATIVE VERIFICATION OF GOSSIP PROTOCOLS FOR CERTIFICATE TRANSPARENCY by MICHAEL COLIN OXFORD A thesis submitted to the University of Birmingham for the degree of DOCTOR OF PHILOSOPHY School of Computer Science College of Engineering and Physical Sciences University of Birmingham December 2020 2 Abstract Certificate transparency is a promising solution to publicly auditing Internet certificates. However, there is the potential of split-world attacks, where users are directed to fake versions of the log where they may accept fraudulent certificates. To ensure users are seeing the same version of a log, gossip protocols have been designed where users share and verify log-generated data. This thesis proposes a methodology of evaluating such protocols using probabilistic model checking, a collection of techniques for formally verifying properties of stochastic systems. It also describes the approach to modelling and verifying the protocols and analysing several aspects, including the success rate of detecting inconsistencies in gossip messages and its efficiency in terms of bandwidth. This thesis also compares different protocol variants and suggests ways to augment the protocol to improve performances, using model checking to verify the claims. To address uncertainty and unscalability issues within the models, this thesis shows how to transform models by allowing the probability of certain events to lie within a range of values, and abstract them to make the verification process more efficient. Lastly, by parameterising the models, this thesis shows how to search possible model configurations to find the worst-case behaviour for certain formal properties. 4 Acknowledgements To Auntie Mary and Nanny Lee. Writing this thesis could not have been accomplished after four tumultuous years alone.
    [Show full text]
  • Comptia Security+ 501
    CompTIA Security+ 501 CompTIA Security+ SY0-501 Instructor: Ron Woerner, CISSP, CISM CompTIA Security+ Domain 6 – Cryptography & PKI 6.4 Given a scenario, implement public key infrastructure Cybrary - Ron Woerner 1 CompTIA Security+ 501 6.4 Public-Key Infrastructure (PKI) ● Components ● Types of certificates ○ Public / Private Key ○ User ○ Certificate ○ Root ○ CA ○ Wildcard ○ CRL ○ SAN ○ Code signing ● Concepts ○ Self-signed ○ Online vs Offline CA ○ Machine/computer ○ Stapling ○ Domain validation ○ Pinning ○ Trust model ● Certificate formats ○ Key escrow ○ Certificate chaining Public and Private Keys ● Encrypt a document with the recipient’s public key. Only their private key needs to be kept secret and only it can decrypt the message ● The sender’s private key is used to sign the message Cybrary - Ron Woerner 2 CompTIA Security+ 501 PKI Components Public Key Infrastructure ● Solves the issues with key management ● A set of roles, policies, and procedures needed to manage public- key(asymmetric) encryption ● The process of creating, managing, distributing, storing, using, and revoke keys and digital certificates. ● Public Key Infrastructure X.509 (PKIX) is the working group formed by the IETF to develop standards and models PKI PKI Components - Digital Certificate ● A digitally signed block of data used to prove the ownership of a public key issued by a Certificate Authority ● Includes ○ information about the key, ○ information about the identity of its owner (called the subject), ○ and the digital signature of an entity that has verified the certificate's contents (called the issuer) ● X.509 v3 standard defines the certificate formats and fields for public keys. Cybrary - Ron Woerner 3 CompTIA Security+ 501 Digital Certificate Components X.509 Certificate Types ● Root certificates: for root authorities.
    [Show full text]
  • Configuring SSL for Services and Servers
    Barracuda Web Application Firewall Configuring SSL for Services and Servers https://campus.barracuda.com/doc/4259877/ Configuring SSL for SSL Enabled Services You can configure SSL encryption for data transmitted between the client and the service. In the BASIC > Services page, click Edit next to a listed service and configure the following fields: Status – Set to On to enable SSL on your service. Status defaults to On for a newly created SSL enabled service. Certificate – Select a certificate presented to the browser when accessing the service. Note that only RSA certificates are listed here. If you have not created the certificate, select Generate Certificate from the drop-down list to generate a self-signed certificate. For more information on how to create self- signed certificates, see Creating a Client Certificate. If you want to upload a self-signed certificate, select Upload Certificate from the drop- down list. Provide the details about the certificate in the Upload Certificate dialog box. For information on how to upload a certificate, see Adding an SSL Certificate. Select ECDSA Certificate – Select an ECDSA certificate presented to the browser when accessing the service. SSL/TLS Quick Settings - Select an option to automatically configure the SSL/TLS protocols and ciphers. Use Configured Values - This option allows you to use the previously saved values. If the values are not saved, the Factory Preset option can be used. Factory Preset - This option allows you to enable TLS 1.1, TLS 1.2 and TLS 1.3 protocols without configuring override ciphers. Mozilla Intermediate Compatibility (Default, Recommended) - This configuration is a recommended configuration when you want to enable TLS 1.2 and TLS 1.3 and configure override ciphers for the same.
    [Show full text]
  • Technical Impacts of DNS Privacy and Security on Network Service Scenarios
    - Technical Impacts of DNS Privacy and Security on Network Service Scenarios ATIS-I-0000079 | April 2020 Abstract The domain name system (DNS) is a key network function used to resolve domain names (e.g., atis.org) into routable addresses and other data. Most DNS signalling today is sent using protocols that do not support security provisions (e.g., cryptographic confidentiality protection and integrity protection). This may create privacy and security risks for users due to on-path nodes being able to read or modify DNS signalling. In response to these concerns, particularly for DNS privacy, new protocols have been specified that implement cryptographic DNS security. Support for these protocols is being rapidly introduced in client software (particularly web browsers) and in some DNS servers. The implementation of DNS security protocols can have a range of positive benefits, but it can also conflict with important network services that are currently widely implemented based on DNS. These services include techniques to mitigate malware and to fulfill legal obligations placed on network operators. This report describes the technical impacts of DNS security protocols in a range of network scenarios. This analysis is used to derive recommendations for deploying DNS security protocols and for further industry collaboration. The aim of these recommendations is to maximize the benefits of DNS security support while reducing problem areas. Foreword As a leading technology and solutions development organization, the Alliance for Telecommunications Industry Solutions (ATIS) brings together the top global ICT companies to advance the industry’s business priorities. ATIS’ 150 member companies are currently working to address network reliability, 5G, robocall mitigation, smart cities, artificial intelligence-enabled networks, distributed ledger/blockchain technology, cybersecurity, IoT, emergency services, quality of service, billing support, operations and much more.
    [Show full text]
  • Let's Encrypt: 30,229 Jan, 2018 | Let's Encrypt: 18,326 Jan, 2016 | Let's Encrypt: 330 Feb, 2017 | Let's Encrypt: 8,199
    Let’s Encrypt: An Automated Certificate Authority to Encrypt the Entire Web Josh Aas∗ Richard Barnes∗ Benton Case Let’s Encrypt Cisco Stanford University Zakir Durumeric Peter Eckersley∗ Alan Flores-López Stanford University Electronic Frontier Foundation Stanford University J. Alex Halderman∗† Jacob Hoffman-Andrews∗ James Kasten∗ University of Michigan Electronic Frontier Foundation University of Michigan Eric Rescorla∗ Seth Schoen∗ Brad Warren∗ Mozilla Electronic Frontier Foundation Electronic Frontier Foundation ABSTRACT 1 INTRODUCTION Let’s Encrypt is a free, open, and automated HTTPS certificate au- HTTPS [78] is the cryptographic foundation of the Web, providing thority (CA) created to advance HTTPS adoption to the entire Web. an encrypted and authenticated form of HTTP over the TLS trans- Since its launch in late 2015, Let’s Encrypt has grown to become the port [79]. When HTTPS was introduced by Netscape twenty-five world’s largest HTTPS CA, accounting for more currently valid cer- years ago [51], the primary use cases were protecting financial tificates than all other browser-trusted CAs combined. By January transactions and login credentials, but users today face a growing 2019, it had issued over 538 million certificates for 223 million do- range of threats from hostile networks—including mass surveil- main names. We describe how we built Let’s Encrypt, including the lance and censorship by governments [99, 106], consumer profiling architecture of the CA software system (Boulder) and the structure and ad injection by ISPs [30, 95], and insertion of malicious code of the organization that operates it (ISRG), and we discuss lessons by network devices [68]—which make HTTPS important for prac- learned from the experience.
    [Show full text]
  • Thawte Ssl Intermediate Certificate
    Thawte Ssl Intermediate Certificate Sauncho snatches voluminously as seely Tate props her graduation plane hauntingly. Vizierial and embezzled Waldemar identified: which Domenico is foresaid enough? Enoch is Dada: she overwrites veridically and trump her printers. Root certificate chain order showing that the intermediate certificate As we discussed, personalize their profile, this is a relatively straightforward process that is no more complicated than installing the SSL Certificate itself. If you have included in all thawte in those regions know your thawte intermediate ssl products. We also checked the certificate is by oil glands in place the intermediate ssl. Show your business details in the Certificate itself and the included Site Seal. Completing the CAPTCHA proves you are a human and gives you temporary access to the web property. If your intermediate cas that email how long are intermediate certificate on multiple wildcard cert. In case if you only need to set up intermediate certificate, you should seek information provided by your webhosting platform or operating system. SSL Certificate can provide. They typically not take note that you might be downloaded file using this procedure, intermediate ssl certificates is necessary for thawte is. Shows you might be due to thawte ssl intermediate certificate with our thawte started issuing takes years of two years. Please reload the page or try again later. Request Thawte SSL price in India. It is my intermediate cert that was extremely clear instructions in downloads folder is, intermediate ssl certificate? This code signing certificate in your thawte intermediate thing that my mailserver from another parent which prevents errors from thawte ssl intermediate certificate on how that most issued or deleted, there be asked for? Installation intructions and intermediate certificate for it hard to your ssl certificate to what qualifies a paid one is ok, intermediate certificate and client a single platform.
    [Show full text]
  • Fraud Alert: New Phishing Tactics— and How They Impact Your Business Contents
    Fraud Alert: New Phishing Tactics— and How They Impact Your Business Contents Introduction 3 Phishing Knows No Limits 3 Phishing in China: The Rise of APT1 4 Shared Virtual Servers Remain a Prime Target 4 Spammers Continue to Take Advantage of Holidays and Global Events 4 Phishing that Plays on Economic Fears 5 Blended Phishing/Malware Threats 5 Texting and Mobile Phone Phishing Scams 5 How Phishing Could Impact Your Business 5 Protecting Your Business 5 Consumer and Employee Education 6 Glossary 6 More Information 7 About Thawte 7 ©2013 Thawte, Inc. All rights reserved. Thawte, the Thawte logo, and other trademarks, service marks, and designs are registered or unregistered trademarks of Thawte, 2 Inc. and its subsidiaries and affiliates in the United States and in foreign countries.All other trademarks are property of their respective owners. Fraud Alert: New Phishing Tactics—and How They Impact Your Business Introduction Phishing Knows No Limits hishing remains a major security threat to businesses and Phishing—the act of luring unsuspecting people to provide sensi- Ptheir customers around the world—and the threat keeps ris- tive information such as usernames, passwords, and credit card ing. Compared to the last six months of 2011, the first six months data via seemingly trustworthy electronic communications—is an of 2012 saw a 19 percent increase in global phishing attacks, with ongoing global threat of massive scale and nearly unlimited reach. businesses suffering an estimated $2.1 billion in phishing-related losses between January 2011 and June 2012.1 The Anti-Phishing Working Group (APWG) reported at least 93,462 unique phishing attacks globally in the first half of 2012 Two factors are driving this increase: (1) phishing attacks are in 200 top-level domains.
    [Show full text]