Blogs

    Publish
     
      • Website Identity- The Key to Safety in E-Commerce

        Oct 20 2017, 9:17 PM

        by Dean Coclin 0

        Website identity is important for user safety. While encryption is important, knowing who you are encrypting to is paramount when conducting online transactions. While many users can identify the green bar/lettering associated with an Extended Validation (EV) certificate, recent user interface (UI) changes by browsers make it more difficult to differentiate these certificates from low value, domain validated certificates. This makes it a challenge to figure out the true owner of the website.


        For example, Chrome recently changed the certificate UI for Domain Validated (DV) certificates to show a green padlock. With an increase of DV certificates used by fraudsters for phishing (see: http://toolbar.netcraft.com/stats/certificate_authorities), it is becoming more and more difficult for users to determine if a site is legitimate. DV certificates don’t identify the entity behind the website. You just know you are connected to www.example.com. There is no ownership information vetted about example.com. Organizationally Validated (OV) and EV certificates provide ownership information allowing a user to know who the site belongs to. But unfortunately, browsers do not distinguish sites with these types of certificates.

        This chart from the CA Security Council (CASC) shows the confusing UIs that are in current browsers: https://casecurity.org/browser-ui-security-indicators/. It’s no wonder that users have trouble understanding the differences in the various certificates. And they are constantly changing.  

        A proposal from the CASC for a common, easy to understand, user display for website identity is shown below:

        Image.png

        The members of the CASC which include the 7 largest SSL issuers in the world, are endorsing a paper on Website Identity Principles, which was presented at the RSA Conference on February 15, 2017. There are three main principles that summarize the intent of this paper:

        1.  Website identity is important for user safety.

        2. Different TLS certificate types that are used to secure websites – Extended Validation (EV), Organization Validated (OV), and Domain Validated (DV) certificates – should each receive a separate, clearly-defined browser UI security indicator to tell users when a website’s identity has been independently confirmed.

        3.  Browsers should adopt a common set of browser UI security indicators for different certificate types, and should educate users on the differences among these indicators for user safety.

        More information on these principles is available on the CASC website (https://casecurity.org/identity/).

        • Products
        • DigiCert Code Signing
        • DigiCert Complete Website Security
        • DigiCert SSL TLS Certificates
        • Products and Solutions
        • Symantec Website Security
      • The Challenges of Transitioning Non-Browser Applications to SHA-2

        Mar 01 2016, 8:00 PM

        by Dean Coclin 0

        Two weeks ago, Worldpay, a major international payment processor, approached Symantec and the CA/Browser Forum with an urgent situation.  A small but still meaningful portion of the payment terminals within their global network can only function using the SHA-1 hashing algorithm.

        SHA-1 is an older technology that has been shown to be increasingly vulnerable.  According to the current CA/Browser forum standards, starting Jan 1, 2016 Certificate Authorities are no longer allowed to issue new public SHA-1 certificates (although existing certificates can remain in use until they expire or until browsers and operating systems block them, currently planned for January 1, 2017 by several browsers). 

        While Worldpay made considerable efforts to identify all their servers and believed they had obtained all the required certificates last year, some were missed which service roughly 1% of their credit card terminals and ATM machines globally. Due to Worldpay’s large global footprint, that small percentage translates into a number of potentially impacted businesses and end consumers.   

        Following Worldpay’s request to the CA/Browser Forum, Symantec followed up with each of the major browsers directly.  After a public discussion on the Mozilla Dev Security Policy list, Mozilla proposed an approach that would enable Worldpay to get the required exception while minimizing the risk associated with additional SHA-1 certificate issuances.

        The long-standing concerns about continued use of SHA-1 were reiterated by many as were the practical issues posed by Worldpay. We took this issue very seriously, as we had to weigh the additional risk against the potential negative disruption to Worldpay’s global merchant network and consumers.  After ruling out other possible technical options, we concluded that the approach proposed by Mozilla was the best available option. We issued these exception certificates to Worldpay last week and we will continue to work with them on alternate solutions that will adhere to industry best practices for certificate security, compliance, and management. A key element in our decision to issue these exception certificates was that they will be used only with non-browser clients – allowing the browsers to proceed uninterrupted with their upcoming plans to disable SHA-1 support.

        Recognizing today’s complex technical interdependencies, several in the CA/Browser Forum raised the question of how to avoid this type of issue in the future. We are working with Worldpay and other customers to deploy alternate solutions, such as Symantec’s Private CA offering, that will ultimately separate the handling of encryption in credit card terminals, ATMs, cable boxes, and other non-browser clients from that in popular web browsers.

        Symantec fully understands and promotes the necessity for adherence to best practices for certificate security management. That said, we also understand that real-world implementation is sometimes more challenging than we might anticipate, and we need to work together to not only create the right incentives for 100% compliance, but also to handle these real-world cases with the right level of consideration and nuance. We believe by collaborating with Mozilla and others, we have found a short-term solution that will enable businesses around the globe to keep functioning while providing some additional time, clearly required, to allow for the technical migration to SHA-2.

        • Products
        • DigiCert Code Signing
        • Voice of the Customer
        • Symantec Website Security
      • Microsoft’s launch of Certificate Reputation

        Apr 17 2015, 9:51 PM

        by Dean Coclin 0

        A few weeks ago, Microsoft launched a new addition to their Bing Webmaster Tools which allows website operators to monitor their web domains to help insure there are no improperly issued SSL certificates.

        This is a great benefit to those owners because:

        1. It’s easy to use and Microsoft monitors this for free

        2. The Certificate Authorities do not need to do anything special. Certificates are automatically monitored by Microsoft

        3. It’s integrated into the Bing Webmaster toolset. There is no need to sign up separately for the service

        4. It works for all types of SSL certificates, not just EV

        However, there are a few limitations today:

        1. This is currently a “preview” and only collects data from users on Windows 10 which itself is currently only in a preview release. Hence the data is limited. However, this will improve with the formal release of Windows 10.

        2. The data that Microsoft is gathering is not made public which prevents the public at large from also seeing the certificates. However, the need being addressed is that of website owners.

        More details are in this Microsoft blog.

        Trust continues to be enhanced in the Browser/Certificate Authority ecosystem (as discussed in this prior blog) and Certificate Reputation is another tool (along with Certificate Authority Authorization-CAA, Certificate Transparency-CT, and Public Key Pinning) along this path.

        • Products
        • Symantec Enterprise Security
        • Thought Leadership
        • Symantec Website Security
        • SSL
        • Identity and Authentication Services
        • DigiCert Code Signing
        • certificates
        • Security Community Blog
      • DV SSL Certificates and Ecommerce don't mix

        Mar 29 2018, 10:31 PM

        by Dean Coclin 0

        Symantec’s just released Internet Security Threat Report shows that cybercriminals have been busier than ever. And social engineered attacks are one vector that continue to see growth due to the likelihood of success. Although the attacks come in different forms, one approach fools unsuspecting users to click a link which takes them to a “look-a-like” website. That imitation site is typically a highly-phished domain, (i.e. Apple ID or a popular bank or credit card site). But now, to prove their legitimacy, phishers obtain Domain Validated (DV) SSL certificates because they know that consumers have been trained to look for the padlock or “https” in the browser URL window. The appearance of this lock further legitimizes the attack and tricks consumers into disclosing their credentials or banking/credit card details.

        There are three types of SSL certificates, each requiring a different level of authentication: DV, OV and EV. Understanding the differences among each SSL certificate type is important to help prevent falling victim to scammers. For example, DV certificates are quick and easy to procure and don’t require any type of information indicating the person trying to get the DV certificate actually represents a legitimate business. Fraudsters often use DV certificates to lure consumers to phishing websites that look authentic but are designed to steal sensitive information. For this reason, doing any type of ecommerce transaction on a DV-only site poses risk. While there are appropriate use cases for DV certificates, it’s important to know how cybercriminals are taking advantage of DV certificates to conduct phishing scams and how to protect against these types of cybercriminal attacks.

        Online shopping isn’t going away. Until the industry requires an OV or EV certificate for e-commerce sites or an easier way to identify the types of certificates, consumers will have to bear some of the burden of combatting cyber risks. Knowing the risks ahead of time, however, is half the battle. 

        • Products
        • Public Key Infrastructure (PKI)
        • Symantec Enterprise Security
        • Thought Leadership
        • SSL
        • Identity and Authentication Services
        • DigiCert SSL TLS Certificates
        • Security Community Blog
      • Enhancing Trust in the CA/Browser System

        Apr 13 2015, 5:40 PM

        by Dean Coclin 0

        Stop Hand.jpg

        Browsers and Certificate Authorities are in the news again over the reported mis-issuance of an SSL server certificate to google.com domains. Discovered by Google most likely via technology known as key pinning and discussed by Google’s Adam Langley in this blog, a Chinese certificate authority, CNNIC (Chinese Internet Network Information Center), apparently issued an intermediate certificate to an Egyptian company called MCS Holdings. Because the CNNIC root certificate is included in the root store of most major browsers, users would not see any warnings on sites that have certificates issued by CNNIC or MCS Holdings. When MCS installed their intermediate into a Man in the Middle (MITM) proxy device, that device could then issue certificates for sites which users connected via that proxy would visit.

        There are several violations of the CA/B Forum Baseline Requirements and Mozilla Root Program Requirements here. First, Mozilla specifically prohibits using public roots for MITM applications. (While there may be legitimate corporate use cases for these proxy devices, using public root certificates as part of the implementation is prohibited and is a violation of public trust). Second, any sub CA certificates (issued from the Root) must be publicly disclosed and audited or be technically constrained(using the technology known as “name constraints” which limits the domains which the CA can issue to. Neither appears to be the case here. Third, indications are that the key was not generated and stored in a proper Hardware Security Module (HSM). There are several other mistakes as well but these are the major ones.

        CNNIC documents show that the sub CA certificate was only issued for a short duration and was to be used for test purposes only. While this may be the case, it ignores the reality that the misuse of such a certificate can cause great harm to end users. Users can be deceived to go to a fraudulent website and have their credentials stolen. The fact that bogus certificates found their way onto the public Internet due to this “test” makes it clear that improper controls were in place at both CNNIC and MCS Holdings as well as a limited understanding of the rules surrounding public CAs.

        The major browsers quickly moved to un-trust the MCS Holdings certificate to protect their users from potential fraud. MCS sent a report to Mozilla with their assessment of the situation. Google has announced that they are taking action to distrust the CNNIC root certificates.  Google will “whitelist” all existing CNNIC certificates and has provided a path for re-inclusion into their browser by insisting all future certificates use Certificate Transparency.  Firefox will be updated to distrust any CNNIC certificate with a notBefore date of April 1, 2015. The current CNNIC root will remain in the Mozilla root store to validate current certificates and CNNIC can reapply for full inclusion but may be subject to additional scrutiny and controls during the process. This is essentially a punishment for violating the Baseline Requirements and the Mozilla root program rules.  Microsoft is still evaluating whether to take further action than just distrusting the MCS Holdings Intermediate certificate. No word from Apple so far.

        Three recently introduced technologies and controls namely Certificate Authority Authorization (CAA) and Certificate Key Pinning (HPKP), which are designed to prevent mis-issuance, and Certificate Transparency (CT) which is designed to detect mis-issuance, significantly raise the level of security of the CA/Browser cryptography system. CT and HPKP are being implemented by some browsers and CAA is a function that CAs will have to deploy.

        What is the lesson learned here? Not all CAs are created equal. Clearly CNNIC broke the rules and got caught. Whether it was intentional or not is being debated in the public. It doesn’t appear from the evidence that this was intentionally malicious. Symantec and all the SSL issuing CAs are held to high standards with regard to the ecosystem rules including CA/B Forum Baseline Requirements, Network Security controls, and Mozilla, Microsoft, Google, Apple and other root program requirements. We have strict controls in place to insure sub CA certificates are either disclosed or constrained, have strong and knowledgeable vetting and authorization teams, obtain regular audits from accredited WebTrust auditors and work closely with the major browser vendors in the CA/B Forum. While we do issue sub CA certificates to third parties, we are well aware of the strict rules surrounding this practice and the need to remain vigilant. Symantec supports the use of CT, CAA, and HPKP technologies and urges adoption by all participants in the ecosystem.  In the end, it matters which CA you choose so pick one that has a long track record and invests in its infrastructure to insure its customers are protected.

        • Products
        • Public Key Infrastructure (PKI)
        • Symantec Enterprise Security
        • Thought Leadership
        • SSL
        • Identity and Authentication Services
        • Security Community Blog
        • Managed PKI for SSL
      • SSL Certificates: What Consumers Need to Know

        Apr 29 2015, 11:24 PM

        by Dean Coclin 1

        In 1994, the first online purchase crossed the World Wide Web: a large pepperoni pizza with mushrooms and extra cheese from Pizza Hut. Over the next 20 years, e-commerce has exploded into a bustling economy, exceeding $1.2 trillion in sales in 2013.

        This growth in online purchases rests upon a foundation of trust. People trust that the websites they use to track finances and make online purchases are secure and legitimate largely because of Secure Socket Layer (SSL) certificates- otherwise known as that little green padlock in the URL bar of the browser.

        SSL certificates verify that the provider is who they claim to be and also indicate secure connections between personal devices and company websites. Understanding SSL certificates is important to help prevent falling victim to scammers. Because at the end of the day, not all sites, or SSL certificates, are created equal.

        Different types of certificates

        Website owners purchase SSL certificates through Certification Authorities (CA). There are three different types of SSL certificates, each providing a different level of security. The problem is that, even though all of these certificates provide the safety padlock in the URL bar of a browser, along with the HTTPS (“S” indicating “secure”) in the address bar,  the levels of security between types of certificates differ greatly. This is why it is important to understand what kind of SSL certificate a site is using when looking to perform financial transactions or anything involving personal user data.

        • Domain validated (DV): This simply verifies who owns the site. It’s a simple process where the CA will send an email to the website’s registered email address in order to verify their identity. No information about the company itself is required. Cybercriminals commonly use DV certificates because they are easy to obtain and can make a website appear more secure than it actually is. For instance, fraudsters may use DV certificates to lure consumers to phishing websites that look authentic, or to cloned websites that look legitimate, but are designed to steal sensitive information.
        • Organizationally validated (OV): To receive an OV certificate, a CA must validate certain information, including the organization, physical location and its website’s domain name. This process typically takes a couple of days.
        • Extended validation (EV): This certificate has the highest level of security and is the easiest to identify. In order to issue an EV certificate, the CA performs enhanced review of the applicant to increase the level of confidence in the business. The review process includes examination of corporate documents, confirmation of applicant identity and checking information with a third-party database. In addition to adding the padlock in the URL bar of the browser, the “S” part of HTTPS, this adds the company’s name in green in the browser URL bar.

        Can you tell the difference?

        SSL.jpg

        Clearly, the last URL is an EV certificate. The first is the DV certificate and the second is an OV certificate, which both look identical to each other.

        What can people do to stay safe?

        Now knowing what a SSL certificate is, the three different types, and that DV-enabled sites pose a risk for scams, how can users reduce the risk of shopping or performing other sensitive transactions online?

        1. Be aware! Just because a website has the padlock or “https” next to a URL doesn’t make it safe for financial transactions. Users have learned to look for those two things before conducting a transaction, which is exactly why cybercriminals are going through the trouble of obtaining SSL certificates in the first place – to look like a legitimate site.
        2. Know how to look for the type of SSL certificate a website has. As a first step, look for visual cues indicating security, such as a lock symbol and green color in the address bar. Only EV-enabled websites include the company name in the web address bar. Browsers do not distinguish a DV certificate from an OV certificate, however. To make it easy to tell the difference, Norton has created a free tool. You simply paste a URL directly into the tool and it will tell you if the site is DV-, OV- or EV-enabled, with results clearly highlighting how safe a site is.
        3. Only conduct transactions and provide sensitive data to sites that have OV or EV certificates. There’s a time and place for DV certificates, but that doesn’t include using them for e-commerce sites. If you drop a URL into the Norton tool and the tool reports that the site has a DV certificate, rethink conducting any type of transaction via that site. If it’s an OV or EV certificate site, you know that the business information has been confirmed.

        Let’s face it – online shopping isn’t going away. Until the industry requires an OV or EV certificate for e-commerce sites or an easier way to identify the types of certificates, people will have to bear some of the burden of combatting cyber risks. Knowing the risks ahead of time, consumers are less likely to be duped by phishing websites.

        Readers can find more information on SSL certificates in this recent Symantec whitepaper or by visiting our Trust Services page.

        • Products
        • DigiCert Code Signing
        • Symantec Enterprise Security
        • Thought Leadership
        • Security Community Blog
        • Symantec Website Security