Blogs

    Publish
     
      • 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
      • SHA1 certificate shown as insecure or with mix content warning on Google Chrome 39

        Sep 09 2014, 8:59 AM

        by Robert Lin 1

        As of late 2014, SHA1 certificates and it's SHA1 trust chain (not including the Root CA) will be considered insecure by Google Chrome.

        A three step process will increase the severity of the warning:

        1. Initially SHA1 certificates that expire on/after 2017/1/1, and which contain SHA-1-based signatures in the validated chain, will be shown the "Secure, but minor errors" icon.  This is a lock with a yellow triangle alert icon
           
        2. Severity will increase thereafter, where:  
          SHA1 certificates that expire between 2016/6/1 and 2016/12/31, inclusively, and which contain SHA-1-based signatures in the validated chain, will be shown the "Secure, but minor errors" icon. This is a lock with a yellow triangle. alert icon

          SHA1 certificates that expire on/after 2017/1/1, and which contain SHA-1-based signatures in the validated chain, will be shown the "Neutral, no security" icon. This is the blank page icon, as shown by HTTP URLs. Blank page icon
           
        3. Finally Chrome will render websites with SHA1 certificates that expire on/after 2017/1/1 and which contain SHA-1-based signatures in the validated chain, with the "Affirmatively insecure, major errors" icon. The "Affirmatively insecure, major errors" icon is a lock with a red X. red https
           

        To resolve this issue SHA2 certificates must be installed.

        Google: Gradually sunsetting SHA-1

        What about the Cross Root Chaining? For example:
        Chain one : >>    (1) example.org-int1(sha256) <- int1-ca1(sha-256) <- ca1-ca1(N/A)
        or
        Chain two : >>    (2) example.org-int1(sha256) <- int1-ca1(sha-256) <- ca1-ca2(sha1)<- ca2-ca2(N/A)

        or
        Chain three: >>   (3) example.org-int1(sha256) <- int1-ca1(sha-256) <- ca1-ca2(sha256) <- ca2-ca2(N/A)

        As per Ryan from Google:

        "On all of our platforms, it will prefer (1) if ca1 is trusted. It would only go to (2) if ca1 is not trusted.
        On the platforms where this is the case, the peer supplying ca1-ca2(sha256) as part of the handshake ensures that (3) is preferred, if ca2 is trusted."

        • Products
        • Google Chrome
        • Public Key Infrastructure (PKI)
        • Symantec Enterprise Security
        • Thought Leadership
        • Symantec Website Security
        • SHA1
        • DigiCert Code Signing
        • DigiCert SSL TLS Certificates
        • Security Community Blog
        • SHA256
        • Google
      • How does SSL work? What is an SSL handshake?

        Sep 15 2014, 10:24 AM

        by Robert Lin 0

        A special request was made today: "How does SSL work? What is an SSL handshake?"

        Here are some quick info.

        SSL/TLS are protocols used for encrypting information between two points. It is usually between server and client, but there are times when server to server and client to client encryption are needed. For the purpose of this blog, I will focus only on the negotiation between server and client.

        For SSL/TLS negotiation to take place, the system administrator must prepare the minimum of 2 files: Private Key and Certificate. When requesting from a Certificate Authority such as Symantec Trust Services, an additional file must be created. This file is called Certificate Signing Request, generated from the Private Key. The process for generating the files are dependent on the software that will be using the files for encryption.

        For a list of the server softwares Symantec has, have a look at: Symantec CSR Generation

        Note that although certifcates requested from Certificate Authorities such as Symantec are inherently trusted by most clients, additional certificates called Intermediate Certificate Authority Certificates and Certificate Authority Root Certificates may need to be installed on the server. This is again server software dependent. There is usually no need to install the Intermediate and Root CA files on the client applications or browsers.

        Once the files are ready and correctly installed, just start the SSL/TLS negotiation by using the secured protocol.  On browser applications it is usually https://www.yourwebsite.com.

        Remember to use your secured website address. Above is just a sample address.

        That will start the SSL/TLS negotiation:

        Keys and Secrets during RSA SSL negotiation

        The following is a standard SSL handshake when RSA key exchange algorithm is used:

        1. Client Hello
          - Information that the server needs to communicate with the client using SSL.
          - Including SSL version number, cipher settings, session-specific data.
           
        2. Server Hello
          - Information that the client needs to communicate with the server using SSL.
          - Including SSL version number, cipher settings, session-specific data.
          - Including Server’s Certificate (Public Key)
           
        3. Authentication and Pre-Master Secret
          - Client authenticates the server certificate. (e.g. Common Name / Date / Issuer)
          - Client (depending on the cipher) creates the pre-master secret for the session,
          - Encrypts with the server's public key and sends the encrypted pre-master secret to the server.
           
        4. Decryption and Master Secret
          - Server uses its private key to decrypt the pre-master secret,
          - Both Server and Client perform steps to generate the master secret with the agreed cipher.
           
        5. Generate Session Keys
          - Both the client and the server use the master secret to generate the session keys,  which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session
           
        6. Encryption with Session Key
          - Both client and server exchange messages to inform that future messages will be encrypted.

        (Wikipedia: Transport Layer Security)

        Tools such as OpenSSL can be used check the SSL/TLS negotiations:

        OpenSSL s_client -connect www.symantec.com:443 -state -ssl3
        Loading 'screen' into random state - done
        CONNECTED(000001C0)
        SSL_connect:before/connect initialization
        SSL_connect:SSLv3 write client hello A
        SSL_connect:SSLv3 read server hello A
        depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5

        SSL_connect:SSLv3 read server certificate A
        SSL_connect:SSLv3 read server done A
        SSL_connect:SSLv3 write client key exchange A
        SSL_connect:SSLv3 write change cipher spec A
        SSL_connect:SSLv3 write finished A
        SSL_connect:SSLv3 flush data
        SSL_connect:SSLv3 read finished A
        ---
        Certificate chain
         0 s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/businessCategory=Private Organization/serialNumber=2158113/C=US/postalCode=94043/ST=California/L=Mountain View/street=350 Ellis Street/O=Symantec Corporation/OU=Corp Mktg & Comms - Online Exp/CN=www.symantec.com

        There it is. SSL and SSL Negotiation summarized. Mission complete.

        Now! Do Not Forget To Back Up Your Private Key and Certificate in a Secure place in case of system issues!

        • Public Key Infrastructure (PKI)
        • DigiCert Code Signing
        • certificate
        • Security Community Blog
        • Products
        • SSL Negotiation
        • TLS
        • Symantec Enterprise Security
        • Thought Leadership
        • Symantec Website Security
        • SSL
        • private key
        • #CSR
        • Trust Services