Last Friday, Google became aware of unauthorized digital certificates for several Google domains. In an article written by Google’s Adam Langley, Security Engineer, he detailed the source of the forged certificates and the systematic way that Google was able to find the certificates’ source in order secure the browsers we use everyday.
By analyzing the unauthorized certificates, Google was able to trace them back to MCS Holdings as the certificate authority and the issuers, CNNIC, acting as an intermediate company. Google has since alerted CNNIC and blocked all of the certificates issued by MCS Holdings in Chrome through their revocation process called CRLSet push. The forged transport layer security certificates are readable and considered authentic by all major operating systems and browsers, but public-key pinning functionality prevented Chrome on Windows, OS X, and Linux, ChromeOS, and Firefox 33 browsers from accepting those certificates of authenticity before the vulnerability was identified and addressed.
Let’s quickly go over the Secure Socket Layer (SSL) protocol to better understand where the vulnerability was expressed! When you type a url into the address bar of your chosen web browser, the browser requests a secure page (denoted by “https”) and the web server where the site is hosted sends its public key along with its certificate that was issued by the Certificate Authority (CA). Your browser says ‘hello,’ validates the authenticity of the certificate issued, that the certificate is still valid, and that the certificate is registered to the site that you wish to navigate to. Your browser and the host server begin the ‘handshake’ by using a public key to encrypt a random symmetric encryption key between your browser and the host server with the encrypted URL required as well as other encrypted http data. The host server decrypts the symmetric encryption key using their shared private key and uses the agreed upon symmetric key to decrypt the URL and http data, then the host server returns the site to your browser and allows you to browse and shop in a secure environment.
CNNIC explained that they go through MCS Holdings to receive certificates for domains they have registered, but the coveted private keys that keep interactions between your browser and the host server secure were stored in a https://mitmproxy.org/doc/howmitmproxy.html man-in-the-middle proxy (MITM) that literally acts as a middle man in the information transaction between your browser and the host server, decrypting and exchanging information for both parties-which the CA system is designed to prevent, but by allowing a trusted third-party to cryptographically sign a server’s SSL certificates to verify that they are legitimate, the man-in-the-middle can continue to be utilized by companies. The safer Hardware Security Module (HSM) securely generates, stores, and manages encrypted data keys in a computing environment away from the host server, eliminating the want or need for a man-in-the-middle proxy.
When Google realized that this was going on, they abruptly flexed their certificate acceptance abilities with their CRLSet push that enforced the existing security features in place. With Ayoka’s focus on providing secure custom software development services with best practices in mind, we help our clients stay apprised of security risks and keep communication lines open to discuss changes we may need to make to your information technology environment. Contact Us today if you have questions about your software!
