HTTP and HTTPS
HTTPS is a network protocol browsers use to securely communicate with web servers. HTTPS is a secure alternative to a much older protocol, called Hyper Text Transfer Protocol, or HTTP. HTTPS can protect users, because it requires encryption of that all exchanged web (or HTTP) data are via a cryptographic protocol, called TLS (HTTPS is literally *HTTP* over *TLS*).
Encrypting web data with a secret key (like TLS does) improves user security by preventing attackers from reading or altering the original content in transit. Such network attacks are known as man-in-the-middle (MITM) attacks. Researchers have repeatedly demonstrated that MITM attackers can, in essence, read or modify any HTTP traffic, without the user knowing about it.
The added security makes HTTPS ideal for web applications handling sensitive data, and most servers (e.g. banking or e-mail servers) have already been upgraded. Unfortunately not all web servers support it, due to various operational restrictions, such as increased bandwidth, legacy issues and so on. Since there is potential danger, concerned users need to know whether they are browsing over an insecure connection.
Enter security indicators
Browsers inform users about the security status of a web connection, in the form of graphics shown in the address bar (e.g. the lock icon before the URL of this article). These security indicators can be either negative and warn users that they are in potential danger, or positive, to reassure them their connection is secure.
Security indicators are used to communicate two aspects of a web connection; connection security and the authenticity of the remote web server.
Connection security through encryption
Indicators inform about connection security by distinguishing among encrypted, unencrypted and mixed content connections. Encrypted and unencrypted sites protect either all or no content. Mixed content means some components of otherwise-encrypted web sites are being retrieved through unencrypted channels.
Components which can modify the content of the page (such as scripts or vectors) are called active content. Components with fixed identities (like static images or fonts) are called passive content.
Although a fully encrypted web connection sounds secure, this alone does not mean that a web site is safe to browse.
Server authentication and digital certificates
Attackers can (and do) copy the content of a web site and redirect network traffic to their own malicious server, even over encrypted connections. Their server would only have to present a different, known TLS key instead of the original secret. Having no reason to doubt the legitimacy of the connection, unsuspecting users could then be persuaded to log in or disclose any other sensitive information.
In response, browsers authenticate servers by correlating the credentials of legitimate web server owners with the unique encryption key each server presents. That way, browsers delegate this credential verification to third-party entities, called Certificate Authorities (CAs). Major browsers maintain root programs to manage their own trust of CAs, which must adhere to strict standards and audit requirements to be trusted by the browser.
A web server owner requesting a certificate from a trusted CA, such as SSL.com, must present a valid public key and prove that they control the domain name and the server it points to. If these checks are successful, the CA issues a digital certificate to the owner, who uses it to both encrypt and authenticate connections to their site.
Certificates are digital identities, containing information about the person or organization that owns a server. CAs cryptographically sign each certificate with a digital signature, an integrity mechanism analogous to wax seals – attackers cannot duplicate the signature, and they would have to invalidate it before modifying the content. HTTPS requires a web server to greet a browser connection with that server’s valid certificate. The browsers then checks the certificate – if it was signed by a trusted CA, the connection may proceed. (If a server presents a different, revoked or otherwise invalid certificate, the browser terminates or disallows the connection and warns the user, using error messages which we will examine in detail in a future article).
It should be noted that not all certificates offer the same level of security, and security indicators may distinguish between the different certificate types issued for different levels of validation.
CAs issue Domain Validated (DV) certificates to customers that have demonstrated control over a DNS domain. Organization Validated (OV) certificates are vetted to authenticate an organization is a legal entity, as well as domain control. Finally, Extended Validated (EV) certificates – which can display company information in the browser bar itself – are reserved for customers that have passed multiple independent verification checks (including human-to-human contact, reference to qualified databases and followup reviews) as well as the OV- and DV-level steps.
Current status of indicators
In the early days of the internet, HTTP was the norm and HTTPS was introduced as an option for the very most security minded. As a result, most browsers only used positive indicators, i.e. a lock showing an HTTPS connection, and (optionally) whether that connection uses an EV certificate. Today, to promote security consciousness more broadly, Chrome, along with Firefox and Safari, have also started adopting the use of negative indicators, warning users of pages with unencrypted or mixed active content pages. The following table is a summary for the general state of security indicators in browsers. Starting with HTTP (which is not secure at all) each item further along the list is more secure than the previous ones.
(Click on image to enlarge)
Upcoming changes and plans for the future
Chrome’s Usable Security team has released a proposal for changing this browser behavior. They suggest that all browsers should start to actively warn users against unsafe HTTP (or mixed content HTTPS) web sites, with negative indicators, while they try to remove positive security indicators from HTTPS web sites altogether.
They base their decision on research that was published in 2007, stating that positive security indicators are ignored by users, as opposed to negative indicators which are perceived as more serious. Chrome has also argued in their original proposal, that “users should expect that the web is safe by default, and they’ll be warned when there’s an issue”.
Subscribed to this idea, starting September of 2018, newer Chrome versions (69+) display a “Not secure” negative indicator on all HTTP web sites, and will not show the “Secure” positive indicator for HTTPS.
Mozilla’s Firefox (since version 58+) is one of the two other browsers that have adopted negative security indicators, but only for sites with mixed active content. Furthermore, in an official blog post, they have announced their future plans for UI security indicators in Firefox: “Firefox will eventually display the struck-through lock icon for all pages that don’t use HTTPS, to make clear they are not secure”.
Apple’s Safari (tech release 46+) is the remaining browser that uses negative indicators for web sites with mixed active content, although they have not made any public statements regarding their plans for security indicators in the future.
Microsoft’s Edge and Opera browsers have not spoken publicly on their plans about UI security indicators.
Being safe on the Internet should be the default, and active browser warnings against insecure HTTP connections could provide great motivation for some legacy web server owners to pay attention to the security of their sites and their visitors. Moreover, removing the “Secure” indicator from HTTPS web sites is (arguably) a step towards making HTTPS the expected norm. As far as entirely removing positive indicators, some indicators, such as EV indicators, can still provide important assurance to vistors in some circumstances. Whatever the future may be, as global HTTPS usage increases there are bound to be some interesting changes and challenges – so keep checking back with us for future information on these and other security topics.
As always, thanks for reading these words from SSL.com, where we believe a safer Internet is a better Internet.