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
      • The modern eCommerce landscape: How compliance impacts success

        Apr 20 2017, 10:15 PM

        by Rufus Connell 0

        The more we rely on the web for personal and business use, the more important it is to keep it (and ourselves) safe from cyberthreats. The bulk of this responsibility falls on those in charge of websites, but once you understand the evolving cybersecurity landscape, you’ll realize you can actually shape it to your business advantage.

        Ushering in a new era of cybersecurity
        Key internet stakeholders, including web browsers, cybersecurity companies and organizations in the payment card ecosystem are joining forces and redefining best practices to create a safer, more sustainable internet:

        •    Chrome and Firefox are displaying “Not Secure” warnings on certain web pages that are not encrypted.
        •    Symantec and other security providers are supporting widespread data encryption.
        •    Payment card companies continue to innovate and drive stronger fraud prevention.

        The Payment Card Industry Security Standards Council (PCI) recently updated an important Best Practices for eCommerce Report. The update was created in collaboration with a special interest group including representatives from Symantec as well as merchants, financial institutions, service providers and other payment security professionals. The report offers:

        •    Additional guidance to the PCI Data Security Standards Guide (PCI DSS)  about best practices for securing eCommerce implementations.
        •    Useful information for selecting SSL/ TLS certificates (and the certificate authorities which provide them), especially those which are most appropriate for unique eCommerce environments.
        •    Questions merchants should ask their certificate authorities, eCommerce solution partners and other service providers.

        Staying ahead of these evolving best practices can help you not only protect your customers and your website —but improve your business and profitability.

        The stakes are high
        Cyberthreats are more pervasive than ever before. Customers are increasingly concerned about fraud, and failure to adhere to the latest compliance benchmarks can significantly impact your businesses. If a data breach occurs:

        •    Consumers lose confidence in your brand, making it difficult (if not impossible) to restore your image.
        •    The brunt of financial responsibility typically rests on merchants.
        •    Other liabilities exist in the form of fines and penalties, legal costs, lost jobs and more.

        In short, it all comes down to good governance. Without it, your site and your brand are at risk. With it, the eCommerce world is your oyster, and credibility and profit are the pearls within. 

        The road to success is paved with best practices
        Rather than burdening your business, compliance to evolving standards can actually open up new avenues of opportunity. But to capitalize upon them as an online merchant, your responsibilities include:

        •    Ensuring secure development of software and confirming Payment Application Data Security Standard (PA-DSS) validation of third-party apps
        •    Maintaining written agreements with third parties to ensure cardholder data is protected
        •    Strengthening SSL/TLS certificate authentication, minimizing risk and more

        The better you understand security guidelines, the easier it will be to stay competitive and build a sustainable online business.

        Ready to learn more?
        Register now to attend Online Trust: Where Compliance Meets Profitability, a live webinar that will be held on April 26 at 10 a.m. PST. Representatives from Symantec and VISA, key members of the PCI special interest group, will explore the intersection of compliance and profitability – and how the latest internet security best practices can benefit you, your customers and your business. 

        • Products
        • DigiCert Code Signing
        • Products and Solutions
        • Symantec Website Security