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.
What security properties does TLS give me?
TLS guarantees identification, confidentiality, and integrity between a client (a computer) and a server.
- Server identification means that the user is talking to the right server — i.e., your bank's server, and not someone on the network pretending to be your bank's server.
- Confidentiality (via encryption) ensures that no one with access to the data going over the connection can understand the contents of the communication.
- Integrity means that no one can tamper 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. A 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:
- Opportunistic attacks on wifi networks are easy to conduct via freely available tools like sslstrip or firesheep
- NSA MiTM monitoring of email, chat, and other Internet communication
- ISPs collecting data via MiTM sniffing for marketing purposes
- ISPs modifying web pages (adding ads) via MiTM tampering
- Chinese hackers targeting github
What security properties does TLS not give me?
TLS only protects the connection between your computer and the server. It does not protect data on the client or data on the server. This means:
- If malware is installed on your computer, it will be able to see and modify your web traffic.
- If your system administrator has installed local trust anchors or a local proxy (for example, on a company computer), then the system administrator may be able to see and modify your web traffic.
- If malware is installed on the server, your data on the server may be at risk.
- TLS does not stop compromised or rogue servers from trying to install malware on your computer. Instead, Google Safe Browsing scans websites and files for signs of malware. If Google Safe Browsing flags a website or file as malicious, you will see a separate malware warning for the website or file. This is unrelated to TLS.
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. Ensure that your CA gives you a SHA-256 certificate, as SHA-1 certificates are deprecated (see below).
Certificate Pinning
Chrome has HTTPS "pins" for most Google properties — i.e. certificate chains for Google properties must have a explicitly listed 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 revoked. For 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.
Certificate Errors
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. Certificate pinning errors are also fatal. Otherwise, users are shown a full-screen warning interstitial they can elect to bypass.
Cipher Suites
TLS connections negotiate a cipher suite which determines how data is encrypted and authenticated. Server products typically leave configuring this to the administrator. Many cipher suites available in TLS are obsolete and, while currently supported by Chrome, are not recommended. If an obsolete cipher suite is used, Chrome may display this message when clicking the lock icon:
“Your connection to example.com is encrypted with obsolete cryptography.”
To avoid this message, use TLS 1.2 and prioritize an ECDHE cipher suite with AES_128_GCM or CHACHA20_POLY1305. Most servers will wish to negotiate TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
Deprecated and Removed Features
SHA-1 Certificate Signatures
You may see this message when you click on the lock icon in Chrome:
"This site uses a weak security configuration (SHA-1 signatures), so your connection may not be private."
This means that the certificate chain for the current page is contains a certificate using a SHA-1-based signature, which is outdated and deprecated in Chrome. There are two criteria that determine which lock icon is shown in Chrome:
- the expiration date of the leaf certificate and
- whether there is a SHA-1-based signature in the certificate chain (leaf certificate OR intermediate certificate).
Note that the expiration dates of the intermediate certificate do not matter. Also, SHA-1-based signatures for root certificates are not a problem because Chrome trusts them by their identity, rather than by the signature of their hash. Starting in Chrome 42, the following logic applies:
- If a leaf certificate expires in 2016 and the chain contains a SHA-1 signature, the page will be marked as "secure, but with minor errors" (yellow icon).
- If a leaf certificate expires in 2017 or later and the chain contains a SHA-1 signature, the page will be treated as "affirmatively insecure" (red icon).
Note that this use of SHA-1 is not related to TLS message authentication (“The connection is using [cipher], with HMAC-SHA1 for message authentication.”).
Please see this page for more details on deprecation dates and private enterprise PKIs.
Weak Ephemeral Diffie-Hellman Key Exchange (ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY)
Chrome requires a minimum DHE group size of 1024-bits. See this announcement and this page for more details. Affected sites will fail to load with ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY.
SSLv3
SSLv3 is no longer supported in Chrome. See this announcement for more details.
RC4
Chrome will remove support for the RC4 cipher in a future release around January or February 2016. Server operations should tweak their configuration to support other cipher suites. If available, TLS 1.2 with TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is recommended. See this announcement for more details.
Insecure Version Fallback (ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION)
Historically, some buggy servers have required an insecure version fallback to function. This has been partially removed in Chrome and will be fully removed at a later date. See this announcement for more details. Affected sites will fail to load with ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION.
TLS Resources for Developers and Site Operators
TLS Myths
The only security guarantee TLS provides is confidentiality.
When properly deployed, TLS provides three guarantees: authentication of the server, data integrity (tamper-evidence), and data confidentiality. People often think TLS and HTTPS only apply in threat scenarios where data confidentiality is needed, but in fact they apply when any (or, most often, all 3) guarantees are beneficial.
- Authentication and integrity: The authors and readers of a news site want the news to be the true news that the authors intended. (See the New York Times’ statement about this.)
- Authentication and integrity: The users of a financial information site very much need the facts and figures to be true.
- Confidentiality: You could be just browsing the web, and a pervasive passive monitor could use this to build a profile of you, to track your related experiences on a variety of sites, to cross-reference your interactions, and then declare you a “threat” for otherwise benign interactions.
- Confidentiality: You might be reading an article on reproductive health or religious beliefs that are contrary to local norms. Revealing this information could get you in “trouble”, for some definition of trouble.
- Integrity: You could be reading a website supported by advertising, but that advertising might be rewritten to credit the attacker, rather than the site you're reading. Over time, the site you're reading may need to shut down, because all of their revenue has been stolen by attackers.
- Integrity: You could be reading a blog, but which an attacker changes the content to suggest the blogger is endorsing or holding views contrary to what they really hold.
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.
The Let’s Encrypt project offers free certificates.
SSLs.com offers certificates for a very low price, as low as $5.
SSLmate.com is cheap and easy to use — you can buy certificates from the command line.
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.
The identity of the site you are visiting is still (unfortunately) pretty visible to passive eavesdroppers. For example, the IP addresses of client and server are shown in the clear on the network, and the hostname(s) of the sites you are visiting are transmitted in the clear in DNS requests, in the Server Name Indication portion of a TLS handshake, and in the server's certificate(s). 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.
You may also want to consider the upgrade-insecure-requests CSP directive.