Blogs

    Publish
     
      • Certificate Authority Authorization Checking: What is it, and why should you care?

        Aug 30 2017, 6:12 PM

        by Lee-Lin Thye 0

        Certificate Authority Authorization checking: what is it, and why should you care?

        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 are not trusted.

        Up to now, 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 and operators options to change CAs at their discretion. The downside to this is that certificate issuance can happen without the knowledge of website operators, either by mistake or intentionally by malicious actors.

        A number of technologies have been created in an attempt to highlight instances of “unknown” issuance, such as Certificate Transparency. These have been effective in making the internet a safer, more trustworthy place but they are reactionary measures – only .allowing website operators to address the issue 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 unknown certificate issuance by:

        1.Allowing domain owners to specify which CAs are authorized to issue certificates for their domains; and

        2.Giving CAs the ability to check this authorization before issuing a certificate.

        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 which allows a domain owner to specify which CAs are authorized to issue certificates for their domain(s) 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 authentication checks succeed. However, if it does encounter one or more CAA 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 unauthorized certificate issuance requests by unauthorized parties or bad actors.

        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:

        1.Many domains don’t have a CAA Resource Record; and

        2.Checking CAA records is not mandatory.

        Because it may take some work to create a CAA record, it’s a matter of customers or website operators 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 they limit 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.

        First, 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. Second, 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 ballot (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:

        1.The CA does not find any CAA records for the domain

        2.The certificate request is consistent with the applicable CAA Resource Record(s)

        The rule is effective as of 8 September 2017. You can read the ballot 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 specify a set number of CAs, knowing no other CA can issue a certificate to its domains.  This will help reduce the risks of certificate issuance by unauthorized CAs and help create a more secure and transparent online ecosystem.

        For more information on CAA with Symantec Certificates go to Symantec Knowledge Center

        • Products
        • Certificate Authority
        • TLS
        • Thought Leadership
        • CA
        • Symantec Website Security
        • SSL
        • DigiCert Code Signing
        • certificates
      • Raising the Bar for Security and Trust on the Web

        Sep 11 2015, 7:38 PM

        by Brook Chelmo 1

        Recently, Symantec updated its certificate issuance controls to pay special attention to domains flagged for excessive abuse, malware, spam, and other suspicious activity.  We recently received intelligence that .PW domains had a history of suspicious and abusive behavior.  After further analysis, we decided to place a hold on issuing minimally-authenticated Domain Validated SSL/TLS certificates and are instituting a policy of only offering the stronger authenticated Organization and Extended Validation SSL/TLS certificates to .PW domains.  Part of this change included the revocation of a small number of domain validated SSL/TLS certificates previously issued for these domains.  Additionally, we have engaged with the registry that controls .PW to identify ways that can improve the safety of this top level domain for consumers.  Several other country-code and generic top level domains are also special targets for attackers, which we will continue to evaluate on an on-going basis as well.

        In contrast, forward looking, security minded registries, such as fTLD Registry Services, the owner of the .bank and .insurance top level domains are raising the bar for security for all of its customers. Considered a best practice, before authorizing a domain sale, these registries ensure that only valid, qualified entities operate on these domains and thereby protect the reputation of these spaces. As the original Certification Authority and the market leader for website security solutions, Symantec believes that verifying identity is critical for establishing trust and for ensuring the security of both consumers and the organizations they connect with online.

        Symantec works with the general public to help identify fraudulent websites.  If you would like to report SSL/TLS misuse, please log it here

        • domains
        • DigiCert Code Signing
        • certificate
        • Products
        • TLS
        • website security solutions
        • issue
        • Symantec Website Security
        • .pw
        • SSL
        • revoke
        • Products and Solutions
        • Security
      • Perfect Forward Secrecy - Protecting the gateway to your world

        Jul 31 2014, 10:40 AM

        by Robert Lin 0

        Remember the movie "The Truman Show", where Jim Carrey played the main character of a TV show that chronicled the life of a man who was initially unaware that he was living in a constructed reality television show, broadcast around the clock to billions of people around the globe. Imagine that your organisation is chronicled the same way. Every online transaction, secured or not.

        That's what Heartbleed can do.  Fortunately most systems using OpenSSL libraries have been patched (hopefully) to counter this. What if there is another way that this can be done. That this could be happening right now, on a  daily basis and that this is not a vulnerability, but is actually how most clients connect to organisations during SSL/TLS negotitaions for the past decade?

        Fristly have a look at how SSL/TLS handshake works. 

        Consider this scenario:

        A script kiddie downloads Wireshark and uses it to track network activities within your organisation. Entire transations are recorded, including SSL sessions.  Several years later, after gaining much experience, he can now gain access to the servers and the expired Private Key pairs that were once used to encrypt these sessions. These sessions were encrypted with RSA key exchange. He emails the CSO, "I know what you did last summer".

        OK. A bit too dramatic and over the top, but perfectly possible. This is the flaw (not vulnerability) when using RSA Key Exchange in SSL/TLS negotiations without proper Key Management. As each session is related to the RSA private key used, recorded sessions can be decrypted later.

        An alternative to the RSA key exchange is to use another algorithm, Diffie-Hellman, which creates sessions that are not associated with the private key. Even if the session information is recorded there is no easy way to decipher the computations. With proper Diffie-Hellman implementation, encrypted information cannot be deciphered in the future. This is called Forward Secrecy.

        To see how Perfect Forward Secrecy can be be achieved, ready your coffee, get your thinking cap on and start reading the document attached. 

        • DSA
        • DigiCert Code Signing
        • key management
        • ECDHE
        • Security Community Blog
        • Products
        • TLS
        • Symantec Enterprise Security
        • Thought Leadership
        • ECC
        • Symantec Website Security
        • SSL
        • encryption
        • cipher
        • DHE
        • RSA
      • 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
      • Think you're safe? Think again - SSL Attack Survey

        Aug 05 2014, 1:21 PM

        by Robert Lin 0

        Look! I have a lock, I see https://, I even see the Green Bar, I believe I have protected my server and the clients connecting to our services from attackers now. I can't start increasing security and block clients to my site by disabling SSLv3, MD5 or RC4. I'll be losing customers and profit! I can accept a weaker security as long as user traffic and profit are not affected.

        Performance vs Security is a constant struggle between security experts and management. When it comes to SSL it is no different. Do we allow as many clients to access our site as possible, or do we block all the weak connectivities. There has been numerous studies on this, so I won't go into it here. As a SSL security expert, allow me to take sides this time. Allow me to provide some more gear for us to convince our management why SSL security is more important and how we can migitate the risks without affecting performance or traffic too much.

        Last year September a comprehensive survey was done by iSECPartners,Inc on the various vulnerabilities with the SSL/TLS technology.

        Have a look: Attack on SSL

        • Products
        • TLS
        • Symantec Enterprise Security
        • Thought Leadership
        • Symantec Website Security
        • SSL
        • encryption
        • Vulnerabilities
        • DigiCert Code Signing
        • cipher
        • Security Community Blog