HTTPS Only Works If You Use It

It should be obvious, but everyone seems to be making the same mistake.

HTTPS only works if you use it. Everywhere.

If you don’t use HTTPS everywhere, a bad guy can intercept an insecure request and prevent the user from reaching your secure site. HSTS is a good start to mitigating the threat of accidentally using an insecure link, but it only helps if you have an HSTS policy set for every domain you will be using.

There’s a big collection of failures to use HTTPS here, but the following are ongoing problems that I’ve been complaining about for a long time now…

IE’s “Domain Suggestions” feature can prioritize insecure suggestions over secure suggestions:

image

Many major companies (including OS vendors, investment firms, etc) offer HTTPS links in their email… Except they’re not really HTTPS; they’re HTTP links to a “click counter” that is meant to redirect to the secure link. These redirects can be intercepted:

image

Microsoft OneDrive’s Sharing experience generates secure links by default:

image

…but the link is made insecure if you click the “Shorten link” button:

image

The IE Team still hasn’t changed the default Bing search provider to use HTTPS:

image

Surprisingly, both the Google and Yahoo providers offered are secure, and the Bing provider is secure in Firefox and Chrome. Only IE+Bing is insecure.

The list, sadly, goes on and on.

One of the more esoteric problems I’ve seen is on a site that generally does security quite well: Twitter.

Consider what happens if a user posts a tweet: “I invest with wealthfront.com.” Now I, as a normal human, didn’t spell out https:// in front of that link and Twitter sees it as http://wealthfront.com. This, in itself, might be okay, because WealthFront.com sends a 24 month HSTS policy with the preload attribute, meaning that many browsers will automatically upgrade any http:// reference to https://. That’s great.

Except.

Twitter has some interesting logic in their site. They use a redirector (t.co) to rewrite all hyperlinks, presumably so they can track clicks and block spam or dangerous URLs. When you paste a link into Twitter, it looks to see if the link is to a HTTP target or to a HTTPS target. If it’s to a HTTP target, they use http://t.co and if it’s to a HTTPS target, they use https://t.co.

And here we find the problem. My innocent wealthfront.com reference, which should have been protected by HSTS, has been made insecure because the Twitter folks decided not to use HTTPS everywhere.

image

Update: They fixed this, now all t.co links are HTTPS.

 

 

If you think you’re smart enough not to use HTTPS everywhere, you’re probably wrong.

-Eric

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

Photoshop and Save For Web

Adobe recently announced that “Save for Web” in Photoshop is a “legacy feature” which won’t be improved. I decided to have a look at Adobe Photoshop CC (2015.0.0 Release 20150529.r88 x64) to see the impact of its many different “save” commands on the resulting file size.

First, I created a trivial 20×20 image and drew a red dot in the middle of it.

Next, I performed the naïve File > Save As > PNG operation. The output is a 16,723 byte PNG file, 97% of which is Adobe metadata:

image

If I instead use File > Export > Quick Export as PNG, the result is a 571 byte PNG that can be shrunk by 35 bytes to 536 using the Zopfli compressor:

image

If I instead click File > Export > Export As > PNG, the default size is 608 bytes:

image

If I untick the “Transparency” checkbox:

image

…the file grows to 662 bytes. Interestingly, however, when I retick that same box, the file now shrinks down to 571 bytes. A quick investigation shows that unticking and reticking the box silently changes the PNG from a 48 color palette to a RGB/A image, which is smaller in the case of this small image.

If I use the new File > Generate Assets checkbox and name my layer “reddot.png” the automatically-saved PNG file in the PSD’s subfolder is the 608 byte version.

If I choose File > Export > Save for Web (Legacy) and choose to save a PNG-24 file:

image

… Photoshop reassures me that I’ve made good choices:

image

… But it’s lying. The information at the bottom left doesn’t account for the 935 bytes of useless metadata embedded in the image:

image

I need to change the Metadata dropdown to None:

image

…to get Adobe to omit most of the metadata, although it still wastes 37 bytes of your file advertising Adobe’s product. If you now distill the file, you can save those 37 bytes and pick up a 29 byte improvement in compression for a final file size of 411 bytes.image

So, as you can see, Adobe Photoshop can save this simple 477 byte image in sizes ranging from 477 bytes to a whopping 16723 bytes. The Adobe overhead isn’t “fixed”—it can be much larger: a 207K PNG file on Adobe’s website has 132K of metadata in it, while a 49.1K PNG file on Microsoft’s website contains 48.9K of Adobe metadata.

Lessons Learned:

  1. Learn how to use your tools.
  2. Expect your tools to lie to you.
  3. Use an optimizers.

-Eric

Content Blocking: Unintended Consequences

Our company uses a web firewall device called IronPort to attempt to block unwanted network traffic; it blocks access to known phish and malware domains, and, more annoyingly, domains thought to be related to gaming or “questionable” topics (e.g. politics). Whatever.

Today the IT department pushed a new rule set which blocks some requests to domains like s.tagsrvcs.com. Instead of the normal response, you instead get back a HTTP/403 blocking page of type text/html:

image

That’s fine, I guess (bye-bye trackers).

Except.

Many of the websites I visit (Wired, WashingtonPost, VanityFair, etc) now hang Internet Explorer:

image

Huh!?! How could blocking a tracker cause the page to hang?

Windbg gives us a great big clue:

image

Ah ha! The XSS Filter’s regular expression engine is hanging. But why does it hang if the target content is blocked?!?

Because when the target content isn’t blocked, the server returns a HTTP/200 with a zero byte body, and thus nothing that needs to be scanned for an XSS attack.

When the IronPort device blocks a response, it returns a HTTP/403 with the body HTML shown in the first screenshot. Now IE’s XSS filter must run to check to see whether any of the content from the request was reflected into the blocking page. Still, the blocking page response is pretty simple… Hmm… let’s look at the request.

image

Oh. Yeah, I can see why turning that into a regular expression might take a bit longer than the developers of the XSS Filter might’ve planned for.

So, a few lessons:

  1. Don’t underestimate the collateral damage of blocking content.
  2. If there’s absolutely no chance of a reflection, send an X-XSS-Protection: 0 response header.
  3. As a web developer, choose your third-party dependencies with care. Any of them could break you.
  4. When talking to pointy-haired bosses, webdevs, and designers, refer to HTTPS as “HiFi” to help make it clear that TLS isn’t just some techno mumbo-jumbo– it’s necessary to help ensure the fidelity of the user’s experience.

-Eric

On Chromebooks

I spent the summer of 1994 working minimum wage (a princely $4.25/hour), testing electronics, saving all of my pay to buy a beast of a computer. That September, I entered my sophomore year of high school and plunked down my saved ~$3000 to become the proud owner of my first Windows PC, a Comtrade Pentium 90 with 8 megabytes of RAM, a 730mb hard disk, and a quad-speed CD drive. My parents threw in a few hundred dollars to get me an upgrade to a 17” monitor (snicker… 15.7” visible). I split my time between DOS and Windows for Workgroups 3.11.

Suffice it to say, I’ve been a Windows user for a long time.

In 1999, I started as an intern on the team that became the SharePoint team, and in 2001 I joined Microsoft full-time to work on Microsoft Office, and later Internet Explorer.

Since 2012, I’ve dabbled with Macs and Linux VMs, but spent nearly all of my time on Windows.

That’s starting to change.

Why?

Confession: I love Chromebooks.

In January of 2013, I bought my first Chromebook, the $249 11.6” Samsung Chromebook. It was a underpowered little machine with a decent keyboard, a good battery, and not much else. But the long battery life meant it was almost always ready to go, and the tiny form factor made it an easy choice when I wanted portability but a better keyboard than the tablet.

Within a few months, my wife took over the machine; it was perfect for her scenarios: it booted quickly, rarely ran out of juice, and didn’t bother her with incessant demands that she install updates and reboot, a constant hassle with her Lenovo x200. Updates on the Chromebook are incredibly painless (just click an icon every few weeks) and make both Mac OS and Windows look primitive by comparison.

In March of 2014, I sent my parents a $160 ASUS Chromebox to replace their old Windows XP computer. The new box is about a twentieth of the size and probably four times as fast, but the real reason I sent it was that I was tired of doing remote tech support for browser-borne malware, and I was increasingly terrified of letting my parents do online banking from Windows.

In October of 2014, we upgraded my wife to the $329 Toshiba Chromebook2; it has a much faster CPU than the old Samsung, a dramatically nicer screen, and a respectable battery. It’s a bit heavier and bulkier than the Samsung, but it’s still much more pleasant than the Lenovo. The Samsung Chromebook became a hand-me-down to our two year old son (who loves pounding the keyboard) but alas, the screen was recently broken… not by the boy, but by our cat, who knocked it off a table. Still, for a $249 machine, we definitely got our money’s worth.

My favorite Chromebook is the Pixel. I had a 2013 model which was a beautiful machine with a fatal flaw—an inefficient CPU and a smallish battery that meant it wouldn’t last for five hours on a charge. As much as I wanted to love the Pixel, it let me down too many times; I’d pick it up and it’d be dead. The 2015 Chromebook Pixel solves this problem—it gets much longer battery life (10 hours or more), can live on standby for a very long time, charges rapidly over USB-C, and has a faster CPU. Build quality is generally very good (awesome touch screen, strong hinge, good keyboard). The only worrying issue is that I recently noticed that when the fan comes on (pretty rare) there’s a bit of an audible whine if the base isn’t horizontally level—a problem which may or may not be unique to mine, as I haven’t found anyone else with the next Pixel yet. Update: a friend reports his 2015 Pixel doesn’t have this problem.

I have the $1300 “LS” edition which has an i7, 64gb SSD and 16GB of memory but I’d recommend the $1000 regular edition (i5, 32gb SSD, 8gb RAM) to almost everyone, as there are more useful ways to spend the $300 price difference. (I bought the higher-end model with the idea that I’d eventually put Crouton on mine and run Linux beside ChromeOS… but thus far I’m too afraid to “break” it.)

I currently have a wide range of other devices to choose from (2015 XPS13, 2013 Mac Air, Lenovo T420s, Retina IPad 3, Nexus 7) but I find myself picking up the Pixel more often than not—it’s just a fundamentally pleasant machine for doing things on the web. I’ve also started redeeming the “free HD version on Google Play” codes that come with the HBO shows I’ve bought on DVD and Blu-ray and the Pixel is a great device for watching these as well, although the beta branch of Chrome OS seems to have a number of minor annoyances in the Google Play app.

My 2015 XPS13 which is an awesome form factor (light and fast) but it is currently running Windows 10 which is not ready. Prior to upgrading to Windows 10, the XPS13’s real problems were the awkwardness of the Metro UI paired with the hassle of constant Windows Updates. Another key consideration is that you can’t get (performance destroying) antivirus for a Chromebook, and most IT departments don’t know how to screw them up. Previously this beneficial ignorance was an advantage for Macs as well, but our IT department at least has started “enhancing” Macs and making them awful too.

Despite its many benefits, the Pixel isn’t a perfect machine and it’s probably not for everyone. Apps are sadly sparse, and web-based replacements aren’t getting new features as fast as I’d hope. There have been a few promising developments recently, like Skype making its way to Chromebook. I’m not a gamer, but Chromebooks are very limited in this department– while many browser-based games will work great, those based on Java don’t, and none of the major PC games available for Windows (and increasingly, for Mac) will run on Chromebooks.

The biggest disappointment so far is in printing—it’s not a super-common scenario for us, but we do a ton of online shopping and need to print a return label a few times per month. At home, we have a Brother DCP 7065DN printer and you basically can’t print to it from Chromebooks without expensive workarounds like the Lantronix xPrintServer Cloud Print. It’s goofy that I have to buy a little box to run a print server just so ChromeOS can print, while presumably the exact same print daemon could be run directly on the ChromeOS machine. While frustrating, this limitation will probably continue to fade in importance as new printers come with the Google Cloud Print code built in; for instance, the slightly newer Brother DCP L2520DW supports Cloud Print, and it’d be cheaper to buy that than the xPrintServer box.

Unlike most of my PCs, I feel like my Chromebook works for me, rather than the other way around.

-Eric

Anecdotal Ephemera

This post is a basically random list of things that have happened over the years; it will grow over time.

My freshman year of college, we had three bins in the halls of our dorm—“Trash”, “Recycle” and “Styrofoam”. I diligently sorted everything for disposal and fumed that my dorm mates were constantly throwing out their Styrofoam cafeteria containers in the trash, or throwing trash into the Styrofoam bin. I often ended up pulling trash out of the Styrofoam bin, or pulling Styrofoam containers from the Trash bin, dumping their contents, and putting them in the Styrofoam bin where they belonged.

At the end of the year, I was procrastinating while cleaning up my room for moving out and I leafed through the fifty page student handbook for the first time. A small note in the middle mentioned “Styrofoam recycling was not cost-effective and the program was canceled [five years ago]. Please use Styrofoam bins to dispose of normal trash.”

Over the last week of 2001, I was driving cross country to Seattle and ran out of clean t-shirts. I stopped at Target and bought the cheapest clearance shirt they had, a University of Iowa Athletics “Hawkeyes” t-shirt; it was $5.

Over the intervening 16 years, I’ve received more comments on this shirt than anything else I own. Oftentimes, it takes me a moment to realize that the guy across the street shouting “Go Hawks!” is talking to me.

Over a decade ago, I read Jay Leno’s memoir Leading with My Chin. Two anecdotes stood out.

The first was that, even as a kid, Leno was really into cars. So when his parents bought a new car, they let him pick the engine. So that’s how the family ended up with a station wagon equipped with a V8 Police Pursuit Package.

The second was that Leno once went to D.C. to buy a motorcycle from an old collector; the old guy only wanted to deal in cash, so Leno had ten grand or something in hundreds. He’s waiting in his hotel before going to meet the guy when he gets a call. The president (Clinton, I think) heard he was in town and wonders if he’d like to come over and meet at the White House. So Leno is about to go when he realizes that he’s got all this cash and he really doesn’t want to leave it behind. So he straps it to his body and goes over to meet the President in the West Wing. Naturally, when he’s getting screened for entry, the metal detectors go off and the Secret Service pats him down. They unbutton his shirt, see thousands of dollars in cash taped to his body, and before he can sputter out an explanation they tell him to “Go right in, Mr. Leno.”

Optimize PNGs using PngDistill

Unfortunately, many PNG image generators opt for minimum compression time, failing to achieve maximum compression. Even worse, the most popular PNG generation tools often include huge amounts of unnecessary metadata that can bloat images by thousands of percent!

Fiddler now includes PngDistill, a simple tool that removes unnecessary metadata chunks and recompresses PNG image data streams using the Zopfli compression engine. Zopfli-based recompression often shaves 10% or more from the size of PNG files. You can access the PngDistill tool from the context menu of Fiddler’s ImageView inspector:

Automation

While it is well-integrated into Fiddler, PngDistill, which is installed to C:\program files (x86)\Fiddler2\Tools folder, only requires PngDistill.exe (a .NET application) and zopfli.exe to run; you can use these tools without using Fiddler.

To run PngDistill against an entire local folder of images, you can do so from the command prompt:

   for /f "delims=|" %f in ('dir /b *.png') do PngDistill "%f" replace

This script runs PngDistill on every image in the current folder, replacing any image for which the distillation process saved bytes. You can then update the images on your server with the optimized images.

Running PngDistill.exe without any arguments will show the usage instructions:

image

Notes

  • The “Minify-then-compress” Best Practice applies to PNGs. While large fields of empty pixels compress really well, the browser must decompress those fields back into memory. So, if you’re building a sprite image with all of your site’s icons, don’t leave a huge empty area in it.
  • More advanced optimizations for PNG files are available using filters, color depth reduction, etc. PngDistill does not undertake these optimizations as its goal is to be 100% safe for automation, with no possibility of a user-visible change in the pixels of the image.
  • PngDistill partially supports .ICO files. Icon files may contain embedded PNGs; when run on a .ICO, PngDistill will extract the PNGs and save them externally; you will need to rebuild the .ICO file with the new PNG file(s).

-Eric

Meaningless Legalese

The folks @Wired would like to remind you that viewing their website in any browser violates of their terms-of-use.

wired tou

All web browsers cache content, by-design. And I’m pretty sure that “reading” is one just one of many ways that the material might be “otherwise used.”

For an otherwise forward-looking publication, seeing this garbage on the homepage is a depressing failure.

-E