browsers, security

SSLVersionMin Policy returns to Chrome 66

Chrome 66, releasing to stable this week, again supports the SSLVersionMin policy that enables administrators to control the minimum version of TLS that Chrome is willing to negotiate with a server.

If this policy is in effect and configured to permit, say, only TLS/1.2+ connections, attempting to connect to a site that only supports TLS/1.0 will result in an error page with the status code ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

This policy existed until Chrome 52 and was brought back for Chrome 66 and later. It is therefore possible that your administrators configured it long ago, forgot about the setting, and will be impacted again with Chrome 66’s rollout.

-Eric

Standard
privacy, security

Understanding the Limitations of HTTPS

A colleague recently forwarded me an article about the hazards of browsing on public WiFi with the question: “Doesn’t HTTPS fix this?” And the answer is, “Yes, generally.” As with most interesting questions, however, the complete answer is a bit more complicated.

HTTPS is a powerful technology for helping secure the web; all websites should be using it for all traffic.

If you’re not comfortable with nitty-gritty detail, stop reading here. If your takeaway upon reading the rest of this post is “HTTPS doesn’t solve anything, so don’t bother using it!” you are mistaken, and you should read the post again until you understand why.

HTTPS is a necessary condition for secure browsing, but it is not a sufficient condition.

There are limits to the benefits HTTPS provides, even when deployed properly. This post explores those limits.

Deployment Limitations

HTTPS only works if you use it.

In practice, the most common “exploit against HTTPS” is failing to use it everywhere.

Specify HTTPS:// on every URL, including URLs in documentation, email, advertisements, and everything else. Use Strict-Transport-Security (preload!) and Content-Security-Policy’s Upgrade-Insecure-Requests directive (and optionally Block-All-Mixed-Content) to help mitigate failures to properly set URLs to HTTPS.

Mixed Content – By default, browsers will block non-secure scripts and CSS (called “Active Mixed Content”) from secure pages. However, images and other “Passive Mixed Content” are requested and displayed; the page’s lock icon is silently hidden.

Non-secure Links – While browsers have special code to deal with Active and Passive mixed content, most browsers do nothing at all for Latent Mixed Content, where a secure page contains a link to a non-secure resource. Email trackers are the worst.

Privacy Limitations

SNI / IP-Address – When you connect to a server over HTTPS, the URL you’re requesting is encrypted and invisible to network observers. However, observers can see both the IP address you’re connecting to, and the hostname you’re requesting on that server (via the Server Name Indication ClientHello extension).

TLS 1.3 proposes a means of SNI-encryption, but (unless you’re using something like Tor) an observer is likely to be able to guess which server you’re visiting using only the target IP address. In most cases, a network observer will also see the plaintext of the hostname when your client looks up its IP address via the DNS protocol (maybe fixed someday).

image

Data Length – When you connect to a server over HTTPS, the data you send and receive is encrypted. However, in the majority of cases, no attempt is made to mask the length of data sent or received, meaning that an attacker with knowledge of the site may be able to determine what content you’re browsing on that site. Protocols like HTTP/2 offer built-in options to generate padding frames to mask payload length, and sites can undertake efforts (Twitter manually pads avatar graphics to fixed byte lengths) to help protect privacy. More generally, traffic analysis attacks make use of numerous characteristics of your traffic to attempt to determine what you’re up to; these are used by real-world attackers like the Great Firewall of China. Attacks like BREACH make use of the fact that when compression is in use, leaking just the size of data can also reveal the content of the data; mitigations are non-trivial.

Ticket Linking – TLS tickets can be used to identify the client. (Addressed in TLS1.3)

Referer Header – By default, browsers send a page’s URL via the Referer header (also exposed as the document.referrer DOM property) when navigating or making resource requests from one HTTPS site to another. HTTPS sites wishing to control leakage of their URLs should use Referrer Policy.

Server Identity Limitations

Certificate Verification – During the HTTPS handshake, the server proves its identity by presenting a certificate. Most certificates these days are issued after what’s called “Domain Validation”, a process by which the requestor proves that they are in control of the domain name listed in the certificate.

This means, however, that a bad guy can usually easily get a certificate for a domain name that “looks like” a legitimate site. While an attacker shouldn’t be able to get a certificate for https://paypal.com, there’s little to stop them from getting a certificate for https://paypal.co.com. Bad guys abuse this.

Some sites try to help users notice illegitimate sites by deploying Extended Validation (EV) certificates and relying upon users to notice if the site they’re visiting has not undergone that higher-level of vetting. Sadly, a number of product decisions and abysmal real-world deployment choices mean that EV certificates are of questionable value in the real-world.

Even more often, attackers rely on the fact that users don’t understand URLs at all, and are willing to enter their data into any page containing the expected logos:

image

One Hop – TLS often protects traffic for only one “hop.” For instance, when you connect to my https://fiddlerbook.com, you’ll see that it’s using HTTPS. Hooray!

What you didn’t know is that this domain is fronted by Cloudflare CDN’s free tier. While your communication with the Content Delivery Network is secure, the request from the CDN to my server (http://fiddlerbook.com) is over plain HTTP because my server doesn’t have a valid certificate[1]. A well-positioned attacker could interfere with your connection to the backend site by abusing that non-secure hop. Overall, using Cloudflare for HTTPS fronting improves security in my site’s scenario (protecting against some attackers), but browser UI limits mean that the protection probably isn’t as good as you expected. Here’s a nice video on this.

Multi-hop scenarios exist beyond CDNs; for instance, a HTTPS server might pull in a HTTP web service or use a non-secure connection to a remote database on the backend.

DOM Mixing – When you establish a connection to https://example.com, you can have a level of confidence that the top-level page was delivered unmolested from the example.com server. However, returned HTML pages often pull in third-party resources from other servers, whose certificates are typically not user-visible. This is especially interesting in cases where the top-level page has an EV certificate (“lighting up the green bar”), but scripts or other resources are pulled from a third-party with a domain-validated certificate.

Sadly, in many cases, third-parties are not worthy of the high-level of trust they are granted by inclusion in a first-party page.

Server Compromise – HTTPS only aims to protect the bytes in transit. If a server has been compromised due to a bug or a configuration error, HTTPS does not help (and might even hinder detection of the compromised content, in environments where HTTP traffic is scanned for malware by gateway appliances, for instance). HTTPS does not stop malware.

Server Bugs – Even when not compromised, HTTPS doesn’t make server code magically secure. In visual form:
image

NoSilverBullets

Client Identity Limitations

Client Authentication – HTTPS supports a mode whereby the client proves their identity to the server by presenting a certificate during the HTTPS handshake; this is called “Client Authentication.” In practice, this feature is little used.

Client Tampering – Some developers assume that using HTTPS means that the bytes sent by the client have not been manipulated in any way. In practice, it’s trivial for a user to manipulate the outbound traffic from a browser or application, despite the use of HTTPS.

Features like Certificate Pinning could have made it slightly harder for a user to execute a man-in-the-middle attack against their own traffic, but browser clients like Firefox and Chrome automatically disable Certificate Pinning checks when the received certificate chains to a user-installed root certificate. This is not a bug.

In some cases, the human user is not a party to the attack. HTTPS aims to protect bytes in transit, but does not protect those bytes after they’re loaded in the client application. A man-in-the-browser attack occurs when the client application has been compromised by malware, such that tampering or data leaks are performed before encryption or after decryption. The spyware could take the form of malware in the OS, a malicious or buggy browser extension, etc.

Real-world Implementation Limitations

Early Termination Detection – The TLS specification offers a means for detecting when a data stream was terminated early to prevent truncation attacks. In practice, clients do not typically implement this feature and will often accept truncated content silently, without any notice to the user.

Validation Error Overrides – HTTPS deployment errors are so common that most user-agents allow the user to override errors reported during the certificate validation process (expired certificates, name mismatches, even untrusted CAs etc). Clients range in quality as to how well they present the details of the error and how effectively they dissuade users from making mistakes.

Further Reading

-Eric

[1] A few days after posting, someone pointed out that I can configure Cloudflare to use its (oddly named) “Full” HTTPS mode, which allows it to connect to my server over HTTPS using the (invalid) certificate installed on my server. I’ve now done so, providing protection from passive evesdroppers. But you, as an end-user, cannot tell the difference, which is the point of this post.

Standard
browsers, security

TLS Fallbacks are Dead

Gravestone reading RIP Fallbacks

tl;dr

 

Just over 5 years ago, I wrote a blog post titled “Misbehaving HTTPS Servers Impair TLS 1.1 and TLS 1.2.”

In that post, I noted that enabling versions 1.1 and 1.2 of the TLS protocol in IE would cause some sites to load more slowly, or fail to load at all. Sites that failed to load were sending TCP/IP RST packets when receiving a ClientHello message that indicated support for TLS 1.1 or 1.2; sites that loaded more slowly relied on the fact that the browser would retry with an earlier protocol version if the server had sent a TCP/IP FIN instead.

TLS version fallbacks were an ugly but practical hack– they allowed browsers to enable stronger protocol versions before some popular servers were compatible. But version fallback incurs real costs:

  • security – a MITM attacker can trigger fallback to the weakest supported protocol
  • performance – retrying handshakes takes time
  • complexity – falling back only in the right circumstances, creating new connections as needed
  • compatibility – not all clients are willing or able to fallback (e.g. Fiddler would never fallback)

Fortunately, server compatibility with TLS 1.1 and 1.2 has improved a great deal over the last five years, and browsers have begun to remove their fallbacks; first fallback to SSL 3 was disabled and now Firefox 37+ and Chrome 50+ have removed fallback entirely.

In the rare event that you encounter a site that needs fallback, you’ll see a message like this, in Chrome:

Google Chrome 52 error

or in Firefox:

Firefox 45 error

Currently, both Internet Explorer and Edge fallback; first a TLS 1.2 handshake is attempted:

TLS 1.2 ClientHello bytes

and after it fails (the server sends a TCP/IP FIN), a TLS 1.0 attempt is made:

TLS 1.0 ClientHello bytes

This attempt succeeds and the site loads in IE. If you analyze the affected site using SSLLabs, you can see that it has a lot of problems, the key one for this case is in the middle:

Grade F on SSLLabs

This is repeated later in the analysis:

TLS Version intolerant for versions 1.2 and 1.3

The analyzer finds that the server refuses not only TLS 1.2 but also the upcoming TLS 1.3.

Unfortunately, as an end-user, there’s not much you can safely do here, short of contacting the site owners and asking them to update their server software to support modern standards. Fortunately, this problem is rare– the Chrome team found that only 0.0017% of TLS connections triggered fallbacks, and this tiny number is probably artificially high (since a spurious connection problem will trigger fallback).

 

-Eric

Standard
security

Certificates Matter

Recently, my web host stopped supporting the FrontPage Server Extensions used by Microsoft Expression Web 4 for website publishing (FPSE is now out-of-support). FPSE allowed me to publish to my site over a HTTPS connection, helping keep my password safe and my uploaded files unmodified.

Unfortunately, the alternative FTP transport is completely insecure–passwords and data transfer in plaintext and can be stolen or tampered and Microsoft products generally don’t support FTPS. As a consequence, I had to stop using Expression Web to edit my various websites. Update: As it turns out, you *can* use FTPS inside Expression Web, but only via the Site > Open Site menu, not the File > Open menu. Expression then warns you that FTP is insecure (bizarrely implying HTTP is better), but network monitoring shows that it’s properly using FTPS under the covers.

Fortunately, my favorite text editor, EditPad Pro offers FTPS support and I quickly moved to using it to edit my site.

Except for one thing—even when using a shared host, the server always returned the same certificate, one whose Subject Name didn’t match the hostname of my website. Yet EditPad didn’t complain at all, it just silently accepted any certificate and sent my username and password. An active man-in-the-middle can easily intercept FTPS connections and return a dummy certificate which EditPad would happily use.

I reported this vulnerability to the developer and I’m happy to see that he’s fixed this problem in version 7.4.0; if the certificate presented isn’t valid for the target, a security prompt is shown every time:

TLS Name Mismatch warning

Ideally, my webhost will start using my installed certificate for FTPS and WebDAV connections, but in the interim manual certificate validation serves as a fallback.

If you build any TLS-protected client or server application, you should always validate the certificate presented during the handshake.

Stay safe out there!

-Eric Lawrence

Standard
security

An A+ HTTPS site for $20

After the CEO of an Internet Security company “explained” that it didn’t matter that his company website was only accessible using insecure HTTP (“it’s only marketing pages so we don’t need security”), I decided to build out a new website: https://WhyTLS.com. Here, I’ll be making my case that all websites need to move to HTTPS, and providing links and resources to help site owners do so.

Naturally, I needed to use HTTPS for my site, but my current host already has a certificate for a different hostname, and changing the site to use a multi-domain certificate would be an expensive hassle. Fortunately, I have recently started migrating my domain registrations over to Namecheap, and it turns out that they offer a great deal on their first year of hosting and HTTPS; adding these to my order was as simple as clicking two buttons.

image

So, for under $20, I’m now the proud owner of a new HTTPS-secured site.

When I bought a certificate for my old site, it was a bit of a pain—I had to create an account with a Certificate Authority and do some complicated dances to prove my ownership of the domain. I then had to give the hosting company $20 to “install” my new certificate on the domain, and pay them the same amount each time I renewed to a new certificate.

Fortunately, Namecheap’s integrated process was much simpler—the form to obtain the certificate was on Namecheap’s Control Panel, and was completely pre-filled out except for “Job Title”, “Company” and “Phone Number” fields (the CA wanted these). With the click of two buttons and a wait of about 10 minutes, I got email telling me that my certificate was ready to install. I clicked “Activate” in the Control Panel and my HTTPS site was live!

I immediately headed over to SSLLabs.com’s Server Test to see how the security of my site measures up. It got an “A”, beating the “B” my other site gets (that one is hindered by running on Windows Server 2008, which only supports older ciphers). Now, an A is good, but I want an A+. That’s easy—I just need to add a HTTP Strict Transport Security (HSTS) policy to combat SSLStripping attacks.

Using my editor, I created /www/.htaccess and added the following lines:

RewriteEngine on
# force ssl
RewriteCond     %{SERVER_PORT} ^80$
RewriteRule     ^(.*)$
https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]
# Send HSTS policy
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS

I saved the file, and here we go– A+ HTTPS configuration, with minimal hassle, for under $20.

Now, is it perfect?

No. Let’s take a closer look at the SSLLabs report.

SNI Required

At the top, there’s a small banner: image. I’ve written about SNI before but SSLLabs’ “Handshake Simulation” report shows exactly what this means: My site will show a certificate error on Android 2.3, IE on Windows XP, and with Java 6, none of which support SNI.

The SNI TLS handshake extension allows a web hosting provider to cut costs by hosting multiple unrelated sites at a single IP address; without receiving the extension from the client, the server doesn’t know which certificate to return.

Fortunately for me, these platforms are fading in importance and I have the luxury of ignoring them. Or so I thought. I later tried to set up WebDAV support on this server so I could use Windows Explorer to manage its files and I found the SNI extension was not getting sent by the SvcHost process:

This bug was supposedly fixed in Windows 8.1, but my results here show otherwise; the problem was fixed in Windows 10 and Microsoft is looking at bringing the fix downlevel.

Extra Certificates

The configuration contains one other minor problem – it sends one certificate more than necessary in the certificate chain sent when the client connects:

The “Contains anchor” notice means that the server sent to the client the root Certificate Authority certificate:

This is an small waste of precious bandwidth, because either the client already has this certificate in its Trusted Root store, or the connection will fail anyway (because a client isn’t going to start trusting the root just because the server sent it). Note: There are some obscure cases (related to Extended Validation EV certificates) where sending a root may be useful to help a client recognize the certificate should get the “green bar” EV UI treatment, but those doesn’t apply here.

I’m excited to see that deployment of HTTPS is getting easier with each passing month, and I’m very much looking forward to the launch of the Let’s Encrypt project (certificates free of hassle and cost) later this year.

-Eric Lawrence

Standard
security

Testing HTTPS In Native APPs

Over on Twitter, Paul asks how to verify that a native application is using TLS.

For a PC, it’s pretty simple, just run Fiddler and watch the traffic. If you see any HTTP requests (other than those labeled “Tunnel to”, indicating a HTTP tunnel used for HTTPS traffic) from the Process of interest, that traffic is insecure and could be intercepted.

Macs and Mobile Devices

For Mac, iOS, Android, Windows Phone, Windows RT or other devices, the first step is to install Fiddler on a Windows or Linux PC (or Virtual Machine) and configure its proxy to point at the Fiddler instance (e.g. that machine’s IP address, port 8888). For now, don’t add the Fiddler root certificate to the device. Launch the application in question and see whether you see insecure HTTP requests. If not, then look to see whether you see any HTTPS requests. If you see only Tunnel to requests but no HTTPS requests, then the app is using HTTPS securely and isn’t willing to accept just any old certificate (like some insecure apps), only a trusted certificate will be accepted. (If you don’t see any traffic at all, try the default browser to make sure you’ve set up the proxy settings properly).

Using Fiddler’s TextView inspector at the top-right of the debugger, you can examine the CONNECT request (“Tunnel to”) Fiddler captured to see which TLS version the client offered, as well as the list of ciphers and extensions the client supports.

If you’d like to see the plaintext of the HTTPS requests, then install the Fiddler root certificate on the device. If you can now see the decrypted requests, the device has a reasonable HTTPS configuration where HTTPS traffic must be signed by a trusted root certificate.

Certificate Pinning

However, if after trusting the root certificate, you can see HTTPS traffic from the device’s primary browser but not the application in question (you still only see only Tunnel to requests) that implies that the app is using Certificate Pinning, whereby only specific certificates (or certificates that have a specific ancestor certificate in their chain) are accepted. To debug the HTTPS traffic from such an application, you’ll need to jailbreak the device and use a tool like the iOS SSL Kill Switch to thunk the HTTPS APIs to allow any certificate. Certificate Pinning is a good security technique, but it can make your application unusable in certain environments.

The one exception to this heuristic for detecting certificate pinning logic is Chrome on iOS; that app ignores the iOS trusted root store due to limitations in the platform APIs. Update: In Chrome 48, Chrome for iOS stopped using its own network stack and began using the WkWebView component, which means it uses the iOS native network stack and HTML renderer.

Configuration Quality

Beyond the scenarios described above, you should test your browsers’ and servers’ TLS support using the great tools at SSLLabs.com.

You can more exhaustively test a client (by installing a local agent) using this Linux application, and you can read about why validation of HTTPS certificates in non-browser software is considered “the most dangerous code in the world.”

-Eric

Standard