On June 2, 2015, Facebook announced that it would stop supporting Facebook-connected apps that were signed with SHA-1, as of October 1, 2015.
“These changes are part of a broader shift in how browsers and web sites encrypt traffic to protect the contents of online communications. Typically, web browsers use a hash function to create a unique fingerprint for a chunk of data or a message. This fingerprint is then digitally signed to prove that a message has not been altered or tampered with when passing through the various servers and systems between your computer and Facebook’s servers.” [https://developers.facebook.com/blog/post/2015/06/02/SHA-2-Updates-Needed/]
You have a dilemma. You want to continue to deploy your web service but are running out of IPv4 addresses. You consider deploying multiple virtual servers that will use the same IP address. However, your thought is that you can only have one SSL certificate per IP address. How will you make your service secure?
Server Name Indication (SNI) is an extension to the SSL/TLS protocol that allows the browser or client software to indicate which hostname it is attempting to connect. SNI is defined in RFC 6066.
Another flaw has been found in the basic encryption algorithms that secure the Internet. This flaw, named the Logjam attack by its discoverers (researchers from various universities and companies), allows an attacker that can carry out man-in-the-middle (MitM) attacks to weaken the encryption used in secure connections (such as HTTPS, SSH, and VPNs). In theory, this means that an attacker (with sufficient resources) can break the encryption and read the “secure” traffic.
The group that manages the Payment Card Industry Data Security Standard quietly announced in February that an imminent update was coming to its payment card and application requirements related to the use of the SSL encryption protocol. Since then, there has been growing concern among merchants about what the changes mean to them.
The confusion among retailers generally can be boiled down to two questions:
What will the new updates require me to do?
What happens to my TSL/SSL certificates?
First let’s explain what’s going on: On Feb. 13, the PCI Security Standards Council informed its assessor community that SSL (Secure Sockets Layer) – a protocol designed to ensure that data provided between a web server and a web browser, such as credit card information, remains secure – is no longer an acceptable way to provide “strong cryptography.” This is due to a number of known fundamental vulnerabilities – some of which, such as Heartbleed, we have documented here, here and here – that essentially make SSL, as an encryption mechanism, obsolete.
Since we last wrote about SSL/TLS performance, there has been a lot of activity in the IETF HTTP Working Group, resulting in the February announcement that the next version of HTTP has been approved. This is big news because it means that major SSL/TLS performance improvements are on the way.
Background
When your browser connects to a website today, it most likely uses the HTTP/1.1 protocol that was defined in 1999 in RFC 2616. Over the past 15 years, HTTP/1.1 has served us well and many tweaks have been discovered to make the most of it. However, in that time the web has transformed into a platform for interactive content and applications. Today, browsers load much more data from many more sources to build the typical web page.
San Francisco – April 13, 2015 – The CA Security Council (CASC), an advocacy group committed to the advancement of the security of websites and online transactions, today released its 2015 Consumer Trust Survey which found that validation matters. While consumers are confused about some aspects of security, they recognize and trust the security that SSL brings to e-commerce sites. Fifty-three percent of respondents identify the padlock as adding confidence in an e-commerce site, with 42 percent associating the green bar and organization name in the URL with greater safety.
As we have stated previously, website owners have a concern that an attacker can have a certificate issued for their domain name. We now have two systems which will help monitor certificates for domains: Certificate Transparency (CT) and Certificate Reputation.
At the start of 2015, most certification authorities (CAs) support CT as requested by Google. CT works for extended validation (EV) SSL certificates and will allow all EV certificates to be monitored.
In March 2015, Microsoft deployed Certificate Reputation. Through the use of Windows, Internet Explorer and other applications, certificate data for all types of SSL certificates is collected and provided to Microsoft. In addition, Microsoft has stated that they don’t collect any information that could be used to identify the user.
Once again Browsers and Certificate Authorities are in the news over the reported mis-issuance of an SSL server certificate to a google.com domain. 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 to that proxy would visit. (MITM is described in more detail in our previous blog here: https://casecurity.org/2015/01/08/gogo-found-spoofing-google-ssl-certificates/)
All the major browsers provide “security user interface”, meaning visual elements to inform the user of the security of their connection to the web page they’re visiting. Up until now, those interface elements were tied to the use of SSL/TLS certificates served by the web site. For example, if you went to http://www.example.com, no special elements would be displayed, but if you visited https://www.example.com, you would see a lock icon indicating the presence of a trusted SSL/TLS certificate. You would also see in the address bar the name of the company responsible for the web site, if the web site used an EV certificate. Most browsers change user interface indicators for mixed content (when a secure page loaded scripts, images or other content from a non-secure site).
