LuxSci

What is your browser telling you about SSL/TLS?

Published: August 7th, 2017

Interpreting a browser’s visual clues about security

The continuous drumbeat of news about pervasive surveillance, security breaches, identity theft, malware, phishing and so forth has had at least one salutary effect on our interactions on the web. The general public is increasingly aware of the need for safe browsing habits, such as not clicking on unknown links in webmail, hovering your cursor over hyperlinks to see if you recognize the URL revealed, and, above all, to “Look for the Lock”.

Such mnemonics and visual aids are important ways to communicate security features to end users, allowing them to take informed decisions on what level of trust they should expect during a particular instance of communications on the web. This post will concentrate on these visual indicators, in particular how browsers represent the identity of the server/site with which an end user would like to interact. The SSL/TLS certificate that the server presents to the browser at the start of the communications is the information source which the browser uses to create the appropriate visual representation that guides the user. Readers would do well to brush up their knowledge on the different types of certificates that are available by reading our previous posts on the subject, as what follows will assume that the reader is aware (at least at a high level) of their basic properties and differences.

Most people are now aware of the need to look for the https://….. in the browser address bar as well as the lock symbol accompanying it. This is the part of the screen that is controlled purely by the browser, which populates it with the site URL and other security information gathered from the SSL/TLS certificate used to secure the connection.

For instance, look at the images below of the luxsci.com website as shown in the address bar of Google’s Chrome, Microsoft’s Internet Explorer (IE), Mozilla’s Firefox and Microsoft’s Edge browsers.

Chrome

Internet Explorer

Mozilla Firefox

Microsoft Edge

(The screen shots were taken using Chrome version 59.0.3071.115, IE version 11.0.9600, Firefox 10.0.2 and Edge 38.14393.1066.)

Note that each looks similar in terms of layout and information presentation[1]. Chrome, Firefox and Edge use a green lock icon, while IE colors the entire URL display area green. However, all manage to convey in a general way that the site is safe to visit.

One feature of the Extended Validation (EV) certificate, which luxsci.com uses, is that the business’s name[2] is prominently displayed on the address bar. This is obtained from the “Subject” field of the EV certificate, which we’ll show how to access in the next section. As we shall see, this field is not detailed enough for non-EV certificates, so that the address bar display provides only a generic description, usually just the words “Secure”, if that.

These visual clues can provide sufficient assurance to the general user of safe browsing, but a more security-conscious visitor may well be tempted, perhaps after reading our previous post on the mis-issuance of certificates, to probe the specifics of the underlying trust by trying to view the SSL/TLS certificate that was used to identify this site to the browser. In fact, it would be prudent for cautious users to check the certificate, to verify who issued it, to which organization and for what period, especially if they are doing some e-commerce or banking transaction that requires confidential data exchange.

The path to accessing the security information of a connection, especially the certificate, is where the browsers differ, though.

How to access the certificate

At this time, Chrome’s security user interface (UX) for gaining access to the certificate details is the most cumbersome. To gain access to the certificate information, you have to click on the “more” icon   on the extreme right hand side, and then navigate via More Tools -> Developer Tools to the Security tab, which finally displays the overall security setting (see the left hand side below). Once there, it provides details about the connection security – the protocol used (e.g., TLS version), the cipher strengths, etc. You still have to click on the “See Certificate” button to review the SSL/TLS certificate offered by the site (see the right hand figure below).

That’s a lot of clicking and steps to remember, and the path to it might change (and has) between Chrome releases.

IE offers a very simple way to access the certificate. Clicking the lock icon immediately reveals key details about the certificate (please see below).

It directly shows the domain name, the issuer’s name and Lux Scientiae’s geographic location, three important pieces of information available in the site’s EV certificate and presumably sufficiently reassuring to the end user. Clicking on “View Certificate” immediately reveals the same detailed certificate information as that for Chrome (see the right hand side image above.)

Mozilla Firefox offers a very similar experience to IE. Clicking the lock icon provides the key information from the certificate of most direct use to an end user (see left hand side below) while clicking More Information provides access to the certificate, albeit after one further click (see the right hand side)

At this time, Microsoft Edge is simply not in the same league with respect to viewing certificates. In fact, you cannot view a site’s certificate without switching to the “Open with Internet Explorer” compatibility mode, accessed via the three-dashes [ ] “more options” icon on the top right hand corner. This may have been a deliberate choice on the part of Microsoft to remove access to details not relevant to the majority of users so as to make Edge a particularly easy browser to use, although why it could not have been a hidden “developer option” remains a mystery. However, clicking on the lock icon in Edge shows similar information[3] (please see below) to that offered by IE.

Until this lack of visibility to detailed security information is remedied, Edge is likely not to be recommended by corporate IT staff for use by their enterprise users.

Distinguishing between sites protected by DV and OV certificates

But what about sites that are not protected by EV certificates?  These are ones which use Domain Validation (DV) or Organization Validation (OV) certificates. The short answer is that there is a distinction in visual clues between sites that use EV certificates and all others that use either of the other two – Domain Validated and Organization Validation – certificates. However, there are no special visual clues provided to distinguish between sites that use DV and those that use OV certificates. (We’ll devote a separate post in the near future to motivating the differences between these three types of certificates and reasons for choosing one over the others, but, for now, we’ll stick to the topic of visual representation of security features in browsers.)

Let’s see below how a non-EV site is represented on the address bar of various browsers.

Chrome

Internet Explorer

Mozilla Firefox

Microsoft Edge

The representation above is quite different from that of our EV-protected site shown earlier. Note the absence of any information identifying the organization behind this site, and the absence of color for all, save Chrome. However, all have the lock icon representing a secure connection to the site. (Note, though, that Edge’s lock icon is not filled in, which is its indication that the site, while secure, uses a non-EV certificate. However, how many users would know that, or even note the subtle change?) Clicking the lock icon gives the same response as described earlier except with much more limited information.

So how can one find out what type of certificate – DV or OV – the site offers to the browser during the secure connection setup? For this, we have to use the same instructions as provided earlier for each type of browser to gain access to the actual certificate.

Here is the certificate provided by Wikipedia.org, opened at the Details tab with the Subject field highlighted.

It tells us some basic details about the registered domain [in CN, for Common Name], the organization [O] controlling the domain, the locality [L], state [S] and country [C] where it is registered for business. All these attributes are parts of the standard format for certificates, defined in the X.509 standard created by the open, consensus-driven process of the Internet Engineering Task Force (IETF). The presence of these details suggests that this is an OV certificate, because obtaining such certificates requires a basic check of the organization that “owns” the domain in question.

Contrast this with the same field for a DV certificate, where no information is provided about the organization behind the domain. We show below the certificate details of a DV certificate from www.ietf.org, which protects the Internet Engineering Task Force’s portal. (The reader can verify, by visiting https://www.ietf.org, that the visual representation of the address bar remains the same as that shown above for Wikipedia’s OV-protected site.)

The Subject line attribute Organization Unit (OU) with value “Domain Control Validated” simply states that the issuing CA (Issuer = Starfield Secure Certificate Authority) has validated that *.ietf.org [CN] has been properly registered with DNS and that the site owner controls this site because it has shown the ability to add resources to it. No further information is known about the organization that controls this domain!

For completeness of contrast, compare the two examples above with the richer details offered by an EV certificate, such as that for luxsci.com shown below.

There is a more definitive way to distinguish between DV and OV certificates: the Policy Identifier field in the Extensions portion of the Certificate (viewed by scrolling down the same Details tab) takes the value 2.23.140.1.2.1 for DV, and 2.23.140.1.2.2 for OV certificates. These are unique and persistent values, formally Object IDs, that link to the basic policy defining how such sites have been vetted. The CA can also provide an Object ID value identifying its particular policy and a link to its certification policy document for each type of certificate. (We’ll talk more about these IDs in a future blog post on the differences, and pros and cons of each type of certificate.)

Viewing sites with security problems

Finally, what of sites whose security characteristics cannot be determined or are found problematic by the browser based on the offered certificate? Unfortunately, again each browser handles things differently.

Take, for instance, the Wikipedia page on the favicon that we mentioned earlier in a footnote. Chrome’s address bar shows:

Note the presence of the “i” instead of a lock icon, suggesting that there is some issue with the security setup. The usual manipulations described earlier to get security information from Chrome shows (please see below) that the page has a valid certificate; however, the page contains mixed content, accessed using both HTTPS and HTTP. This is just a warning, as cross site attacks could be possible in general in such situations – although there are none for this specific page.

Firefox uses a different technique, a more direct way to alert the user. It throws a direct security warning (please see below), which the user has to confront and click through to proceed further.

When dismissed, the Firefox address bar does not show the lock icon.

To complete the picture, the lock icon is missing in Internet Explorer’s address bar. It also offers another visual clue that is so subtle as to be invisible to anyone except the most alert user. It simply reloads the page as http://…. .

However, what about more serious security failings? Here, all four browsers respond with clear alert messages splashed prominently across the page. See below Mozilla’s warning (left) and Chrome’s (right).

There has been a lot of research to try and find the best way to convey in a straightforward way the nature of the problem, without technical jargon or undue exaggeration. This paper shows the complexities facing UX designers in coming up with warning screens such as those above.

The address bars for each browser is shown below, when visiting an exemplary page from the site with an untrusted root certificate, which generated the above warnings on the page without loading it.

Chrome

Internet Explorer

Mozilla Firefox

Microsoft Edge

Unlike Chrome and Firefox, note that IE and Edge do not show any additional visual clues to alert the user beyond the absence of the lock icon. However, while not shown earlier, both provide a clear explanation (albeit with technical words like ‘certificate’) on the screen alerting the user to the problem with the visited page.

Closing thoughts

Hopefully, the reader has implicitly caught onto something from the above descriptions: safe interactions on the web require a tripartite understanding between end users, browser vendors and CAs on safe behavior. CAs express the trust that underlie the security infrastructure of the web through signed certificates, but fake and mis-issued certificates do and will occur. Our previous post provided an overview of the steps being taken by the industry to reduce or possibly even eliminate this, and we shall elaborate on such steps in future posts. Browser vendors rely on the CA’s certificate information and interpret it visually for the end user’s benefit in a way that attempts to balance usability for the general user without providing false guarantees. End users, though, have to remain alert when surfing the web, particularly when there is transactional information exchange as opposed to mere information retrieval. Ultimately, they have to take the responsibility for their actions evaluating these visual clues and the security information appropriately in the context of their interactions.

Users typically get used to particular browsers, and it is well to learn how to access and interpret the security features of one’s browser of choice. However, for various reasons, users do change their browsers. Hopefully, this brief guide will serve as a helpful introduction to the user on how to access the security features and interpret the visual clues, especially as these are not always consistent across the most popular browsers currently in use.

 


[1] As an aside, IE appears to be the only one that includes a favicon, the small site-specific logo, in the address bar. This has been removed from the latest versions of Chrome and IE after concerns that a malicious site without SSL support could use the lock symbol as a favicon to mislead users.

[2] Note the addition of the jurisdiction, “[US]”, to distinguish us from another Lux Scientiae that just might happen to be registered in another country.

[3] USERTrust Network is an intermediate CA owned by COMODO.

Leave a Comment


You must be connected or logged in to post a comment. This is to reduce spam comments.

If you have not previously commented, you can connect using existing social media account, or register with a new username and password.