Chromium‎ > ‎Chromium Security‎ > ‎Education‎ > ‎

TLS / SSL

Data delivered over an unencrypted channel (e.g. HTTP) is insecure, untrustworthy, and trivially intercepted. TLS can help!


What's TLS? 

TLS (also known as SSL) is the industry standard for providing communication security over the Internet. TLS guarantees security properties like identification / non-repudiation, confidentiality, and integrity. Identification / non-repudiation is important because it ensures that the user is talking to the web site they think they're talking to — i.e. your bank, not a malicious intermediary. Confidentiality (via encryption) is important because it ensures that no one with access to the data channel can understand the communication. Integrity is important because it ensures that no one tampered with the data in transit.

In other words, TLS ensures that a Man-in-the-Middle (MitM) can't snoop or tamper with an Internet connection between a user and website. 

TLS in Chrome

HTTP Strict Transport Security (HSTS)

HSTS is a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent to interact with given sites only over secure connections. Chrome supports HSTS and comes preloaded with a set of domains that use HSTS by default. More details, including how to add a site to Chrome's preloaded HSTS list, here.

Certificates

TLS relies on websites serving authenticated (X.509) certificates to prove their identities, which prevents an attacker from pretending to be the website. Certificates bind a public key and an identity (commonly a DNS name) together and are typically issued for a period of several years.

Certificate Pinning

Chrome has HTTPS "pins" for most Google properties — i.e. certificate chains for Google properties must have a whitelisted public key, or it will result in a fatal error. This feature helped Google detect a widespread MITM attack to Gmail users in 2011. You can read more about pinning here. There's also an Internet-Draft for HTTP-based public key pinning.

Certificate Revocation

Sometimes events occur that invalidate the binding of public key and name, and the certificate needs to be revokedFor example, a major flaw in the implementation of OpenSSL left site operators' private key vulnerable to theft, so operators needed to invalidate their certificates. Revocation is the process of invalidating a certificate before its expiry date. Chrome uses CRLSets to implement certificate revocation. You can read about the how and why of Chrome's certificate revocation in our Security FAQ.

TLS Error Handling

If there is an error in the certificate, Chrome can’t distinguish between a configuration bug in the site and a real MiTM attack, so Chrome takes proactive steps to protect users.

If a site has elected to use HSTS, all certificate errors are fatal.

Otherwise:

  • Certificate pinning error: A certificate pinning error from a site will result in a fatal error displayed to the user (see http://tools.ietf.org/html/draft-ietf-websec-key-pinning-13#section-2.6).
  • Non-pinning error: Users are shown a full-screen warning interstitial they can elect to bypass.

TLS Resources for Developers and Site Operators

TLS Myths

My site doesn't need TLS. I'm not a bank.

More people are connected to the web than ever before and from more places and more devices (laptops, phones, tablets, and other things). Very often, this access is over untrusted or hostile networks. Data delivered over a clear text protocol, like HTTP, is insecure, untrustworthy, and trivially intercepted. Neither the user / user-agent nor the web server / application can trust that the data was not tampered with or snooped by some third party - that's a terrible situation for both users and web site operators!

With so much of people's lives moving online, it’s imperative developers take steps to protect their sites' and users' data, which can even include the mere usage of a web site. By analyzing and correlating the sites and pages a user visits, observers like schools, ISPs, and governments can learn quite a bit about a user that the user would wish to keep confidential, such as a users' sexual orientation (http://blogs.wsj.com/digits/2010/03/12/ftcs-privacy-worries-prompt-netflix-to-cancel-contest/) or physical location (http://www.theregister.co.uk/2009/05/21/geo_location_data/).

TLS is too slow.

Historically, TLS used to have a significant performance on web applications. So, istlsfastyet.com? (Spoiler: Yes!) Check out https://istlsfastyet.com/ for more details and a performance checklist.

TLS is too expensive.

You can get a FREE certificate (for non-commercial purposes) at https://www.startssl.com/.

TLS is a privacy / security silver bullet.

TLS does not guarantee perfect privacy or solve all security problems.

For example, when used to secure HTTP traffic (i.e. HTTPS), we’re piggybacking HTTP entirely on top of TLS. This means the entirety of the HTTP protocol can be encrypted (request URL, query parameters, headers, and cookies), however, because host IP addresses and port numbers are necessarily part of the underlying TCP/IP protocols, a third party can still infer these. Also, while you can’t infer the contents of the communication, you can infer the amount and duration of the communication. For specific applications, it’s been demonstrated that this can leak useful information for an attacker, and services have added padding to counter the timing or pattern analysis.

Also, since TLS is a transport protocol, attacks at other layers of the network stack remain. In particular, IP-level threats (e.g. spoofing, SYD floods, DDoS by data flood) are not protected and TLS doesn’t address common web application vulnerabilities, like cross-site scripting or cross-site request forgery.

Common Pitfalls

Deploying TLS

SSL Labs puts out a great Deployment Best Practice Guide that should help site operators avoid the most common deployment mistakes. You can also test your setup via https://www.ssllabs.com/ssltest/.

Mixed Content (HTTP / HTTPS) Vulnerabilities

A mixed content vulnerability refers to a page served over HTTPS that includes content served over HTTP, making the page vulnerable to MitM attacks. This is especially problematic when the HTTP resources are active content (e.g. Javascript, plug-in content, CSS, or iframes). To protect users, Chrome will block mixed-content iframes, Javascript, CSS and plug-in loads by default. So beyond the security risk, mixed content bugs may degrade your page for users in unintended ways.

To fix mixed content issues, make sure that all the resources loaded by an HTTPS page are also sent over HTTPS. If the resources are available on the same domain, you can use hostname-relative URLs (e.g. <img src="something.png">). You can also use scheme-relative URLs (e.g. <img src="//example.com/something.png">) — the browser will use the same scheme as the enclosing page to load these subresources. If the server does not serve these resources over HTTPS, you may have to serve them from elsewhere or enable HTTPS on that server.

Appendex

Man-in-the-Middle Attacks

Man-in-the-middle (MiTM) is a term used to describe a third party that can passively monitor and/or actively tamper with a connection between two unknowing parties. A MiTM attacker relays messages between two parties, making them believe that they are talking directly to each other, when in fact the entire conversation is controlled by the attacker.

MiTM attacks happen in real life! Here are some recent examples: