Blogs

    Publish
     
      • What is HTTP Public Key Pinning, and how can you get it right?

        Mar 30 2018, 4:19 PM

        by Rufus Connell 0

        HTTP public key pinning (or just ‘public key pinning’ or HPKP) is a security mechanism designed to improve online privacy. But like other mechanisms, such as Certificate Transparency (CT) and Certification Authority Authorization (CAA) checking, it has its drawbacks.

        In this article we’ll explain what public key pinning is, discuss its problems, and explain how you can implement it both securely and effectively. 

        The context

        First, let’s take a step back first and review the basics: client/server applications use the Transport Layer Security (TLS) protocol to communicate across a network. TLS aims to provide a level of privacy and security between client/server applications in a way that prevents eavesdropping, tampering or message forgery. It typically involves a client connecting to a server and proving that the server has a private key chained up to a root certificate in the client’s trust store.

        When TLS/SSL was first envisaged, it was considered a foolproof way to connect clients and servers without the risk of man-in-the-middle (MITM) attacks. However, over time, people realized that another entity could sit in between client and server (creating two TLS connections in place of one) without revealing itself to either end. There are legitimate uses for this, but malicious parties can do this too. This is where HPKP comes in.

        HTTP public key pinning: the how and why

        Public key pinning is a mechanism for detecting and blocking certain kinds of man-in-the-middle attacks.

        So how does it work? A domain owner pins the hash of one or more public keys in the certificate chain for their website, creating what is called a HPKP policy. This policy specifies hashes for one or more of the certificates in the website’s public key certificate chain.

        When someone visits the website, it returns the public key pins to the visitor’s browser via HTTP headers. The browser checks that at least one of the pins is valid for the certificate chain, and caches the pins for the next visit. In order to validate the chain, at least one of the certificate chain’s public keys needs to match a pinned public key.

        The whole mechanism tells an application that the certificate chain from a server must contain at least one of the pinned certificates - and to sound the alarm if it finds none. In doing so, users can be more certain there is no-one interfering with (or eavesdropping on) communication over a network, which is especially important for websites that handle sensitive information like healthcare or financial records.

        Above all, public key pinning gives domain operators the ability to reduce the risk of MITM attacks and other false-authentication problems. But it’s not a silver bullet, and it does have its drawbacks.

        Public key pinning is not foolproof

        Although public key pinning can reduce the risk of a MITM attack, it’s not a perfect defense against attackers - especially those capable of passing certificate chain validation procedures.

        In reality, public key pinning is a brittle mechanism and can be problematic by design. Here are some of the issues:

        • Pins have a set lifetime. Once set in a browser’s cache, they remain valid for a period of time and become associated with a unique cryptographic identity that your website must possess to remain in operation. If you lose these and you don’t have a backup key, you’ll effectively block clients from visiting your website.
        • It’s tricky to setup and deploy. If you ever change your configuration by, say, renewing a certificate, you need to make sure that at least one pin matches the configuration you offered to previous users. If it doesn’t match, you’ll block clients from visiting your website.
        • It can be abused by motivated attackers. If someone breaks into your server and gains control of your website, they can alter HPKP policy and serve alternate pinning instructions to your user base. If they later remove these pinning keys, your website will be ‘bricked,’ meaning that clients will be blocked from visiting.

        With great power comes great responsibility: how to get HPKP right

        Public key pinning is powerful, but it can be dangerous too - especially given that the risk of misconfigured pinning policies is quite high.

        Our advice is to avoid deploying HPKP unless you’ve studied the specifications, have a system in place for auditing your configuration (and to detect unwanted pinning) and have a strong understanding of the necessary steps. You should also be careful which certificate you pin to.

        When a Certification Authority (CA) certifies your website’s domain, they’ll give you an end entity certificate signed by an intermediate certificate that is, in turn, signed by a root certificate embedded in browsers. We recommend pinning to the end entity certificate. Why? Because this means you can update your pin whenever your end entity certificate is updated. Pinning an intermediate or root certificate is more dangerous because the CA might change them without knowing that you are using them as HPKP pins.

        Pinning your end entity certificate is a little more work than pinning to your intermediate certificate or root certificate, but you remain in control.

        • DigiCert SSL TLS Certificates
        • Products
        • Products and Solutions
      • Migrating from SHA-1 to SHA-2: what’s all the fuss about?

        Mar 29 2018, 11:00 PM

        by Rufus Connell 0

        At the beginning of 2017, SHA-1 collisions quickly became a reality. With millions of TLS certificates still relying on the SHA-1 based signature algorithm for data integrity, upgrading to SHA-2 certificates is now a critical necessity.

        Firefox and Chrome have already ended their support of SHA-1 TLS certificates, and Safari is set to follow suit this spring. For those still using the deprecated hash function, the security and reputation of your website is at greater risk.

        Symantec has long supported the move to SHA-256 signed certificates and now we are urging you to make the switch as soon as possible, if you haven’t already.

        What are SHA-1’s biggest flaws?

        While the NSA officially deprecated SHA-1 in 2011, in February 2017, Google and CWI Amsterdam exposed its theoretical vulnerabilities in practice. 

        Growing computational power is increasing the probability and affordability of these collisions. Google’s success proves two disparate data files can now obtain the same digital signature in a viable timeframe. This weakness can be abused to target vulnerable TLS and SSL certificates, allowing bad actors to certify malicious websites and code by assigning them the hash function of an authorised certificate.

        Posing as a Certificate Authority (CA), an attacker can sign their own certificates using SHA-1’s vulnerability and appear to hold the private key of a legitimate certificate. Browsers won’t flag these certificates as rogue because the hash function features in their list of trusted signatures. The attackers can then redirect users to a malicious website, maintaining the HTTPS security icons of the original.

        Since SSL and TLS certificates are synonymous with data protection, a reliance on SHA-1 could spark widespread manipulation from hackers in the near future.

        Why is SHA-256 so superior?

        SHA-256 is significantly different from SHA-1, and addresses all the vulnerabilities present in its predecessor. By switching to SHA-256, website owners can protect against the rising likelihood of an attack. While a SHA-256 collision is achievable in theory, in practice it would take today’s top-performing processors billions of years to compute.

        At a granular level, its superiority comes from its increased bit-size (256 bits compared to SHA-1’s 160). While this might not seem like a radical change, the bit-size of SHA-256 protects it against the brute force of current collision attacks.

        With browsers now ending their support for SHA-1 certificates, websites and systems that continue to use the hash algorithm will soon find their SSL/TLS certificates untrusted. Since SHA-256 shows no signs of the same vulnerabilities, replacing outdated certificates will prevent issues with user access.

        Why is now the right time to migrate?

        Despite its known weaknesses, many website owners still employ the SHA-1 has in certificate encryption. Their reluctance to upgrade stems from three factors:

        • Migration time
        • Migration cost
        • Fear of technical issues

        But these aren’t valid excuses, especially when you consider the consequences of not upgrading. By the end of spring, all major browsers will have ended their support for SHA-1. These changes affect active SSL/TLS certificates as well as expiring ones, flagging your site as untrusted when users attempt to connect. The only way to avoid this inconvenience is to make the switch to SHA-256.

        With Symantec, you can migrate in four simple steps:

        1. Inventory your certificates. Discover and manage your SSL/TLS certificates with the Symantec Certificate Intelligence Center. You can deploy this tool to check for existing SHA-1 certificates.
        2. Replace all SHA-1 certificates. Once you’ve located all SHA-1 certificates, create a new Certificate Signing Request (CRS) for each, and submit it to Symantec. While this takes time, it’s a crucial step in protecting your website’s future. We’ll renew every certificate with SHA-2 for free. 
        3. Install new certificates. The next step is to install these certificates on you network. Follow our installation advice to ensure you’re installing them correctly on your specific server vendor.
        4. Test your certificates. Use our CryptoReport tool to check for successful SSL/TLS certificate installations and remove cross-root certificates to ensure better performance and security compliance.

        Audit and secure all your defences

        SHA-1 is the most talked about vulnerability in cybersecurity right now, but you shouldn’t neglect or forget to patch other weak links in your system defences. Our Complete Website Security package includes SSL/TLS certificate assessment, DDoS protection and a Secure App Service so you can focus on converting leads and generating profit.

        • DigiCert SSL TLS Certificates
        • Products
        • Products and Solutions
      • Code signing minimum requirements: standardizing the security of digital signatures

        Mar 29 2018, 9:00 PM

        by Rufus Connell 0

        Following collaboration between the Certificate Authority Security Council (CASC) and Microsoft, a series of Minimum Requirements (MRs) are now in place for all code signing authorities. For business owners, this will help standardise security protocol. The main requirements to consider are:

        • The use of verified company names, state and locality
        • The storage of private keys
        • New timestamping procedures

        As a long-time advocate for these baseline requirements, Symantec is reconfiguring its own authentication process in order to comply with the CASC’s decision. Through widespread adoption of the MRs, signed code use will become significantly securer and more transparent.

        In this article, we’ll discuss how the new regulations will improve your business’ security.

        The Microsoft story: preventing an increase in certified malware

        The driving force behind Microsoft’s bid for code signing standardization is the rise of certified malware.

        ‘Previously, there were no standards, which meant that if one CA rejected a company’s application, that company could submit the same application to a different CA,’ said Dean J. Coclin, Senior Director, Business Development at Symantec.

        With many untrusted CAs in operation, a fraudulent company could continue applying for a certificate until they found a negligent CA willing to authenticate their submission. Incidences of stolen certificates have also increased, with thieves using compromised user keys to digitally sign their own malicious code.

        While Microsoft has been able to track and revoke many of these certificates using its SmartScreen filter, it could do little to prevent misconduct from reoccurring. However, the introduction of MRs makes it easier for CAs to identify the original code publisher and authenticate its digital signature.

        The benefits of universal code-signing regulations

        From a business perspective, the MRs will enable end users and companies to verify and use code with increased assurance. Here are four ways the CASC guidelines will improve code verification:

        1.     Stronger private key protection

        The theft and improper issuance of private keys enables the authentication of malicious code by attackers. Under the new regulations private keys must be kept in secure locations, preferably in hardware, either on-premises or in a legitimate cloud-based code-signing service, to help prevent this threat.

        If a CA generates the private key on behalf of a subscriber and transports it from a secure infrastructure, it must be encrypted with at least 128-bits of encryption strength or transferred via hardware with an equivalent activation method.

        2.     Easier certificate revocation

        If an application software supplier such as Microsoft discovers that one of its users has published malicious code (malware), it will request a certificate revocation. Exploiting keys and running malware is extremely profitable, since there has always been a window of vulnerability before a CA can discover and revoke the associated certificate.  

        The MRs now dictate that a CA has two days to revoke the certificate or launch an investigation into its use, closing this window and ensuring rogue code is caught and eliminated earlier. Businesses that register with untrusted CAs are likely to find their certificates questioned in the future, so it’s important you choose a compliant authority with a strong reputation.

        3.     Standardized Blacklisting

        A higher standard of individual authentication will make it more difficult for bad actors to obtain code signing certificates. The new MRs require CAs to check blacklists of known and suspect malware during identity verification. These are provided by anti-malware organisations and application software providers.

        CAs must also maintain an internal database of revoked code signing certificates (used to sign malicious code) and rejected certificate requests. The aim is to prevent bad actors from switching between CAs in order to get their code authenticated.

        4.     Improved timestamping

        Timestamps are important for businesses that require extended signature verification. The use of a timestamp allows code to be trusted beyond the expiration of the associated certificate. Authenticating code signatures in this way gives relying parties the ability to identify when a certificate was issued and whether it was valid at the moment the timestamp was given, even if that’s after the certificate has expired.

        Symantec offer time-stamping as part of the code signing process, ensuring your code is recognised and accepted by Microsoft software. We create digital timestamps for Windows, Adobe, Android, Java and more.

        What are my code signing options?

        As an enterprise, it’s important to know where you stand. In terms of code-signing, you have two options when it comes to key management:

        1. Local certification – you’re responsible for managing your own certificates, private keys, and code-signing processes. You must contact your chosen CA for certification.
        2. Service orientation – If your CA provides code-signing as a service, and it complies with the MRs, it will have to employ multi-factor authentication.

        Symantec’s Secure App Service (SAS) provides code-signing and time-stamping, with two-factor authentication as standard. Since February 1st 2017, we’ve introduced new measures to our SAS to improve the security of your certificates:

        1. The SAS API now requires the use of both user/password credentials and a client certificate.
        2. The SAS portal now requires both a client certificate and a One-Time Password (OTP) authentication mechanism, provided by our Symantec VIP solution.

        Because Microsoft owns more than 90 percent of the desktop OS market, we’re striving to meet the company’s MRs and ensure our customers can continue to digitally sign and use their software without constraint. 

        • Products
        • DigiCert Code Signing
        • DigiCert Complete Website Security
        • DigiCert SSL TLS Certificates
        • Products and Solutions
      • Symantec CA’s Initial Response to Google’s Revised Proposal

        Mar 29 2018, 8:38 PM

        by Roxane Divol 0

        Today, Google put forward a revised proposal regarding our CA business, which we are currently reviewing. Google’s proposal follows collaborative and constructive community discussions. Our goal has been to reach a solution that minimizes disruption for our customers and is in the best interests of the entire Internet community.

        While there remain details to be considered, we believe Google has put forth a new proposal that limits business disruption for customers as compared to prior proposals. Notably, Google’s revised proposal would not require Symantec to move to shorter-term validity certificates beyond what was approved by the CA/B forum in Ballot 193 for all CAs and Symantec’s Extended Validation certificates would remain intact. Given the potential impact of any changes that might be implemented, we are carefully reviewing this proposal and will respond shortly with feedback for the community’s consideration.

        We thank our customers and the community for their patience and participation in this important discussion.

        Best Regards,

        Roxane Divol

        Executive Vice President & GM, Symantec Website Security

        • DigiCert SSL TLS Certificates
        • Products
        • Products and Solutions
      • Symantec CA Continues the Public Dialogue

        Mar 29 2018, 8:57 PM

        by connect 0

        We believe that we have put forward a proposal [1] that provides the highest level of transparency and reassurance of trust in active SSL/TLS certificates available in the industry.  We also believe that our proposal avoids the imposition of significant compatibility and interoperability risks, as well as customer business disruption, which would result from any proposal that limits the trust of existing Symantec SSL/TLS certificates, imposes shorter validity periods on newly issued Symantec certificates, and/or removes EV recognition for our certificates in browsers. This post responds to comments about our proposal made by Ryan Sleevi in his post summarizing Google’s discussions with Symantec [2] and by Gervase Markham in his draft proposal on behalf of Mozilla [3].

             1.  We are confident in our issuance processes and in the additive protection measures already in place, which is why we are conducting extensive audits that will be made public as outlined in our proposal. We have proposed audits that go far beyond the scope of traditional WebTrust for CAs and Baseline Requirements audits.

                  a.  In the case of EV certs we will have an external auditor examine 100% of the active EV certificates issued. We are confident in our processes and a full, detailed external audit is the best mechanism we are aware of to showcase this.

                  b.  In the case of our SSL/TLS RA program, we have taken the most conservative action possible: we have shut it down. Additionally we have almost completed our revalidation of every active certificate that our former TLS RA partners have authenticated. As of May 4, 2017, the status of the revalidation or review of the active certificates authenticated by our former TLS RA partners is as follows:

                                  CA response chart.jpg

        * The certificates in the “Errors” column of the table above, which we have revoked and replaced, were due to spelling mistakes in information in the organization name, imprecise values in locality (e.g. related to the name change of Distrito Federal to Ciudad de Mexico, similar to those called out by other CAs and considered acceptable exceptions to the Baseline Requirements by Google [4] and Mozilla [5]), or instances where we did not receive sufficient documentation to substantiate subject information. In the case of Certisur, after receipt of additional substantiating information and further review, we concluded that 6 of the revoked certificates were compliant with the Baseline Requirements and satisfied Symantec policies.

                  c.  Further, we have proposed to have an external auditor revalidate all of our work described in the table above with RAs and make that report public. For clarity, we are not proposing an audit that is subject to standard audit sampling practices, but rather third party review and validation of 100% of these active, RA-validated certificates.

             In addition, we previously added extensive controls to our issuance process in response to the 2015 test certificate mis-issuance incident documented here [6]. This included an automated compliance checking engine that blocks non-compliance with the Baseline Requirements.

             Moreover, the additional transparency we are already providing by logging all certificates issued to Certificate Transparency logs – including DV and OV – is a practice that the rest of the industry has yet to adopt. This transparency effort included explicitly providing to Google for whitelisting the certificates that were issued by Symantec prior to us fully deploying CT support.

             Finally, we have proposed moving to quarterly WebTrust audits going forward to provide the community with even more frequent updates on the reliability of our processes.  

             These measures are designed to demonstrate the integrity of our active certificates and to provide timely visibility into the integrity of our future certificate issuances. A third party review of all (100%) active EV and RA-issued certificates is at the extreme end of transparency and we believe such reviews will assure the community about our issuance practices.

             2.  Mr. Sleevi has set forth a second proposal that involves Symantec outsourcing its SSL/TLS issuance to a third party. We have evaluated this sub-CA proposal and believe it is unwarranted and not proportional to the actual or perceived risk that is mitigated under our proposal. We believe our issuance processes are sound and that the transparency initiatives outlined above – specifically, published reports from our third party audits that we expect to complete by August 31, 2017 – will confirm this for the community. Until the audit results are available for public review, we think it is premature to suggest that Symantec consider any such sub-CA proposal.

             3.  While we recognize that shorter validity certificates may reduce exposure to certain security risks, we believe any such change must be consistent across the entire CA industry and be phased in over a period of time taking into consideration existing barriers to adoption. Both Mr. Sleevi (in his latest proposal) and Mr. Markham propose a 13-month validity limit for Symantec certificates. Limiting Symantec’s ability to issue longer-lived certificates while not imposing that same limit on other CAs is uniquely punitive to Symantec’s CA business and unjustified. We also do not believe that a 13-month validity limit should be imposed on the CA industry at this time – a conclusion that is reinforced by the recent CA/Browser Forum vote rejecting ballot 185, which proposed to limit the maximum validity of SSL/TLS certificates issued by all CAs to 13 months. As we have stated in our public response, many enterprises are not at the level of automation maturity necessary to practically and cost-effectively adopt shorter validity certificates. For these organizations, standardizing on shorter validity certificates would present substantial increases in their operating costs. A significant percentage of our active certificates have a validity period greater than 13 months. We have heard from many customers that they will move to another CA if a major browser limits the validity of Symantec certificates to 13 months or less to avoid the operational burden of replacing certificates more frequently – particularly when commercial alternatives exist. If this action is taken exclusively against Symantec, it will create significant disruption for hundreds of thousands of customers / users and will harm our CA business.

                  In light of the difficulty of currently operationalizing the replacement cycle of short-lived certificates for many of our customers, we have proposed 9-month domain revalidation of all of our certificates. An initial certificate validation is one level of authentication. Certificate domain revalidation post-deployment further extends the trustworthiness of the initial certificate, which is a positive extension of the CA trust model.  This 9-month domain revalidation proposal is intended to supplement our proposed expanded offering of shorter validity certificates for those customers for whom it would be a significant burden to adopt them. We’ve proposed reporting our revalidation findings externally and, working with the browser community, we believe we can establish appropriate transparency mechanisms (e.g. through an OCSP extension or a signed revalidation list) that provide an attestation to this revalidation and ensure accountability of our implementation of this action.  We’ve also proposed continuing our investments in automation to enable organizations with even the most complex infrastructure to practically and cost-effectively adopt shorter validity certificates.  

             4.  Portions of Mr. Sleevi’s sub-CA proposal were redacted and he mentioned that Symantec shared additional details with Google during our joint meetings that Symantec did not make public in its response. In our private discussions with Google, we shared key elements of our current solution roadmap, which, as a normal evolution of our business, includes enhancing our issuance platform to create a competitive advantage in the marketplace. We publicly highlighted our investments in this area in our proposal as part of our discussion of automation and supporting shorter validity certificates – specifically, “[o]ur near term investments will focus on modernizing our certificate issuance systems and workflows to enable faster issuance, and developing tools that enable customers to rapidly and securely implement their certificates and configure their systems.” We intend to keep the community informed about our progress here as part of the quarterly updates we have proposed to deliver to the community.

        In summary, we believe our proposal provides the most open and transparent posture of any CA in the industry and reassures trust in active Symantec certificates and our current issuance practices. Our proposal also mitigates the significant compatibility and interoperability risks, as well as customer burden, which would result from any proposal that limits the trust of existing Symantec SSL/TLS certificates, imposes shorter validity periods on newly issued Symantec certificates, and/or removes EV recognition for our certificates in browsers.

        We understand our role as a key player in the trust ecosystem of the Internet and take it very seriously, including the obligation to follow the compliance frameworks set forth by the CA/Browser Forum and browser root programs.  We believe the error rate of our issuances is low compared to our peers and we welcome objective third party information that puts this into context. While third party, comparative data from Netcraft supports our position that our certificate issuances are equal to or better than other CAs, we always work to do better.

        We encourage the community to consider objective, comparative results of our processes with others along with the merits of our proposal. It is important that any actions taken by Google and Mozilla don’t overreach and result in unnecessary business disruption to customers and users of sites that rely on Symantec SSL/TLS certificates. We believe careful and deliberate consideration of the strengths and weaknesses of Symantec’s proposal as compared to those proposed by Google and Mozilla requires more time than has been implied by Mr. Markham and should involve more feedback from the affected stakeholders in the Internet ecosystem than has been received to date.  To that end, we recommend that Google and Mozilla take the time to proactively reach out to the enterprises whose voice is greatly underrepresented in these forums to truly understand the customer use cases we have described and the reasoning behind our proposal.

        [1]: https://www.symantec.com/connect/blogs/symantec-ca-proposal

        [2]: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/lOHrTr97Qx0/2IkcSGq9AQAJ

        [3]: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/IZYmm8zsSKU/vwPIi2L1AgAJ

        [4]: https://groups.google.com/d/msg/mozilla.dev.security.policy/DgeLqKMzIds/x-Rj2AgSAwAJ

        [5]: https://groups.google.com/d/msg/mozilla.dev.security.policy/DgeLqKMzIds/emMZb_E4AwAJ

        [6]: https://www.symantec.com/page.jsp?id=test-certs-update#

          

        • DigiCert SSL TLS Certificates
        • Products
        • Products and Solutions