Posted What is HTTP Public Key Pinning, and how can you get it right? on Blog
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.
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:
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.
Mar 07 2018, 9:10 AM
Posted Migrating from SHA-1 to SHA-2: what’s all the fuss about? on Blog
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:
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:
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.
Mar 07 2018, 9:10 AM
Posted Code signing minimum requirements: standardizing the security of digital signatures on Blog
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:
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:
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:
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.
Mar 07 2018, 9:10 AM
Posted CAA checking: what is it, and why should it be mandatory? on Article
The Public Key Infrastructure (PKI) ecosystem relies on root certificates issued by various certification authorities (CAs) like Symantec. This is what browsers use to decide which websites can be trusted, and which ones can’t.
Currently, any CA can issue a TLS certificate for any domain. That’s how the system works, and it’s good in the sense that it gives website owners choice; they can change CAs if they want to. But the downside is that unregulated certification can lead to ‘mis-issuance’, either by mistake or by rogue CAs.
A number of technologies have been created in an attempt to limit instances of miscertification, such as Certificate Pinning and Certificate Transparency. These have been effective in making the internet a safer, more trustworthy place but they’re reactionary. Both are only able to address mis-issuance after it’s happened.
But is it possible to prevent certificates from being mistakenly or inappropriately issued? Yes. Enter: Certification Authority Authorization (CAA).
CAA prevents mis-issuance by:
In this article we’ll explain how CAA works, and why making CAA checking mandatory is a good move for both customers and CAs.
What is Certification Authority Authorization?
A Certification Authority Authorization (CAA) record is a DNS Resource Record. It allows a domain owner to specify which CAs are authorized to issue certificates for their domain and, by implication, which aren’t.
The idea is that a CA will check the CAA record(s) for a domain before issuing a certificate. If it finds that a domain has no CAA record, then it’s free to issue a certificate for it if all other validation checks succeed. However, if it does encounter one or more records, then the CA can only issue a certificate if it’s named in one of the records, indicating that it is authorized to issue a certificate for that domain. The whole process is designed to prevent CAs from inappropriately or mistakenly issuing TLS certificates.
Sounds great. Why isn’t everyone doing this?
Symantec has been checking CAA records for years, but it’s not a common practice. There are two reasons why CAA checking isn’t widely practiced:
Because it may take some work to create a CAA record, it’s a matter of consciously opting-in, not opting-out. Many domain owners use a DNS hosting provider and CAA is not yet supported in some DNS implementations.
This is why CAA records are expected to be used by most high-value domains. These enterprises keep CAA records for their domains because it limits inappropriate (or malicious) certificate requests, and makes it easier to enforce company policies i.e. only using a particular set of CAs.
The limitations of CAA checking
Of course, CAA checking has its limitations.
For one thing, a newly-issued CAA record does not invalidate any previously-issued certificates that may have been issued by a different CA than the one named by the domain owner. Secondly, it doesn’t flag whether a certificate presented by a web server is a legitimate certificate for that domain.
Furthermore, in order for CAA checking to be effective, all CAs need to be doing it; it doesn’t work if only one or two CAs are checking CAA records as matter of process. CAA checking must be widely adopted if it is to serve its purpose, but the good news is that more than ninety percent of CAs (who are members of the CA/Browser Forum) are in favor of it.
The times are changing: CAA checking will become mandatory
In February 2017, the CA/Browser Forum passed a motion (on which Symantec voted in favor) requiring all CAs (even those who aren’t a member of the Forum) to check for a CAA record as part of the certificate issuance process for each domain. In accordance with RFC 6844, CAs can no longer issue a certificate for a domain unless:
The rule is effective as of 8 September 2017. You can read the motion in full here.
A good outcome for all companies
Mandatory CAA record checking requires CAs to abide by the rules set out in specific CAA records, giving domain owners more control over certificate issuance. This makes it easier for companies (especially larger ones) to enforce a certificate issuance policy across business units. With CAA records applicable to every domain, a company can whitelist a set number of CAs, knowing no other authority can issue a certificate.
On a broader level, the new rules will mean that CAs can properly reconcile a certificate request at the domain owner’s discretion, holding themselves accountable for any mis-issuance. At Symantec, we believe this is an important step towards a securer, more transparent online ecosystem.
Mar 07 2018, 9:10 AM
Posted The modern eCommerce landscape: How compliance impacts success on Blog
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
• Chrome and Firefox are displaying “Not Secure” warnings on certain web pages that are not encrypted.
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.
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
• Consumers lose confidence in your brand, making it difficult (if not impossible) to restore your image.
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
• Ensuring secure development of software and confirming Payment Application Data Security Standard (PA-DSS) validation of third-party apps
The better you understand security guidelines, the easier it will be to stay competitive and build a sustainable online business.
Ready to learn more?
Mar 07 2018, 9:10 AM