Wandering Thoughts archives

The browser security dilemma

So Pete Zaitcev ran into the failure mode of modern browsers being strict about security, which is that the browser locks you out of something that you need to access. The only thing I'm much surprised about is that it happened to Pete Zaitcev before it happened to me. On the one hand, this is really frustrating when it happens to you; on the other hand, the browsers are caught on the horns of a real security dilemma here.

To simplify, there are two sorts of browser users; let us call them sysadmins and ordinary people. Sysadmins both know what they're doing and deal with broken cryptography things on a not infrequent basis, such as device management websites that only support terribly outdated cryptography (say SSLv3 only), or have only weak certificates or keys (512 bytes only, yes really), or their certificate has long since expired and are for the wrong name anyways. As a result, sysadmins both want ways to override TLS failures and can (in theory) be trusted to use them safely. By contrast, ordinary people both don't normally encounter broken cryptography and don't really know enough to handle it safely if they do.

In an ideal world, a browser would be able to tell which sort of person you were and give you an appropriate interface. In this less than ideal world, what browser vendors have discovered is that if you expose a 'sysadmin' interface in basically any way, ordinary people will eventually wind up using it for TLS failures that they definitely should not override. It doesn't matter how well you hide it; sooner or later someone will find it and write it up on the Internet and search engines will index it and people will search for it and navigate the ten steps necessary to enable it (and ignore your scary warnings in the process). If we have learned anything, we've learned that people are extremely motivated to get to their websites and are willing to jump through all sorts of hoops to do so. Even when this is a terrible idea.

Since ordinary people vastly outnumber sysadmins, browsers are increasingly opting to throw sysadmins under the bus (ie, completely not supporting our need to override these checks some of the time). At the moment, some major browsers are less strict than others, but I suspect that this will pass and sooner or later Chrome too will give me and Pete Zaitcev no option here. Maybe we'll still be able to rely on more obscure things (on Linux) like Konqueror, at least if they're functional enough to handle the device management websites and IPMIs and so on that I need to deal with.

(Failing that, there may come a day where I keep around an ancient copy of Firefox to handle such sites, in just the same way that I keep around an ancient copy of Java to deal with various Java based 'KVM over IP' IPMI things. Don't worry, my ancient Java isn't wired up as an applet and only works in a non-default browser setup in the first place.)

It's time for me to upgrade my filtering HTTP proxy

I've been using a filtering HTTP proxy for a very long time now in order to filter out various sorts of things I didn't want from my browsing experience (most prominently cookies). I probably haven't been doing this for quite as long as filtering proxies have been available, but I now suspect that it's actually close, because it turns out that the filtering proxy I use was last updated in 1998. Increasingly, this long stasis in my filtering proxy is kind of a problem that I should deal with.

I haven't stuck with Junkbuster because I think it's some paragon of perfection here. Instead I've stuck with it because it still works without problems and, more importantly, I have a moderate collection of non-default filtering rules that I would have to copy over to any new filtering tool that I adopted (probably Privoxy, which I'm actually already using for filtering stuff related to syndication feed reading). But even though it still works, using Junkbuster is not without problems. Really, there are two big ones.

First, Junkbuster is HTTP/1.0 only, which means that all of my interactions with HTTP websites are constrained down to that. In practice this probably just costs me some amount of latency and speed. I'm not going to say that this is unimportant, but I can't say I've really noticed it. Still, I'd kind of like to have HTTP/1.1 available, if only to be nicer to websites out there by reusing the same connection instead of opening new one after new one.

More importantly (and more relevantly), Junkbuster is very definitely IPv4 only. This means that all of my regular HTTP browsing is IPv4 only, since it all goes through Junkbuster. Even if a site offers IPv6, I'll ignore that. As a result I don't actually use IPv6 all that much even when I have it available, and as a result of that I don't necessarily notice if my IPv6 connectivity breaks for some reason. I would like to change this, which definitely means a new proxy.

A mitigating factor is that all of this is irrelevant for HTTPS connections. Those are not proxied through anything for the obvious reasons, which means that they get HTTP/1.1 (or HTTP/2) and IPv6 support (and also that I have to rely purely on the protections of my browser addons). Over time I expect more and more browsing I do to be HTTPS browsing, but I also don't expect HTTP browsing to go away any time soon; there are still quite a lot of sites that are HTTP-based and they're probably going to stay that way for, oh, the next decade or more.

(As is traditional, I'm writing this entry partly to motivate myself into actually doing this at some point. Since nothing is really broken today, the work required is not entirely attractive; it's basically a bunch of work for very little or no visible improvement. Although probably I can simplify or eliminate a bunch of my current filtering rules; it's not as if I pay them much attention, so a bunch are likely to be long obsolete.)

An Apache trick: using directories to create redirections

Suppose, not entirely hypothetically, that you're using Apache ProxyPass directives as a reverse proxy to map /someurl/ on your website to another web server. You generally have to redirect the URL with the trailing slash, but of course you would like a request for a plain '/someurl' to also work right instead of just getting a 404 status response. Here, 'work right' means that you'll generate a redirection from '/someurl' to '/someurl/'.

It's certainly possible to do this with one of the various Apache directives for explicit redirections (I'd use RedirectMatch). But often there's an easier way: use a real filesystem directory. If somedir is a directory in the Apache document root and you send a request for '/somedir', Apache's default behavior is to send exactly the redirection we want. And Apache doesn't care if the '/somedir/' URL is being diverted somewhere other than the filesystem (via ProxyPass or other directives); it will still send that redirection regardless.

So we can just do 'mkdir /docroot/someurl' and everything will work. The directory contents don't matter; I tend to put a README file there with a note about how the directory is just there for the redirection and actual contents in it will be ignored.

(This redirection trick happens automatically if you're using .htaccess files in a directory to control, say, internal redirections. However there are various reasons for not using .htaccess files, including centralizing your configuration in one easily visible place instead of spraying it all over the filesystem in a bunch of nominally invisible files.)

Back when I wrote my entry on ProxyPass, I theorized about using this trick. I can now say that we've actually done this in our configuration and it works fine.

(This trick is a very old one, of course; I'm sure people have been doing it in Apache for ages. I just feel like writing it down explicitly for various reasons.)

A weird little Firefox glitch with cut and paste

Yesterday I wrote about Chrome's cut and paste, so to be fair today is about my long standing little irritation with Firefox's cut and paste. Firefox doesn't have Chrome's problem; I can cut and paste from xterm to it without issues. It's going the other way that there's a little issue under what I've now determined are some odd and very limited circumstances.

The simplest way to discuss this is to show you the minimal HTML to reproduce this issue. Here it is:

<html> <body>
<div>word1
  word2</div>
</body> </html>

If you put this in a .html file, point Firefox at the file, double click on 'word2', and try to paste it somewhere, you will discover that Firefox has put a space in front of it (at least on X). If you take out the whitespace before 'word2' in the HTML source, the space in the paste goes away. No matter how many spaces are before 'word2', you only get one in the pasted version; however, if you put a real hard tab before word2, you get a tab instead of a space.

(You can add additional ' wordN' lines, and they'll get spaces before the wordN when pasted. Having only word2 is just the minimal version.)

You might wonder how I noticed such a weird thing. The answer is that this structure is present on Wandering Thoughts entry pages, such as the one for this entry. If you look up at the breadcrumbs at the top (and at the HTML source), the name of the page is structured like this. As it happens, I do a lot of selecting the filenames of existing entries when I'm writing new entries (many of my entries refer back to other entries), so I hit this all the time.

(Ironically I would not have hit this issue if I didn't care about making the HTML generated by DWiki look neat. The breadcrumbs are autogenerated, so there's no particular reason to indent them in the HTML; it just makes the HTML look better.)

This entry is also an illustration of the use of writing entries at all. Firefox has been doing this for years and years, and for those years and years I just assumed it was something known because I never bothered to narrow down exactly when it happened. Writing this entry made me systematically investigate the issue and even narrow down a minimal reproduction so I can file a Firefox bug report. I might even get a fixed version someday.

PS: If you use Firefox on Windows or Mac, I'd be interested to know if this cut and paste issue happens on them or if it's X-specific.

My annoyance with Chrome's cut and paste support under X

In the past I've vaguely alluded to having problems getting xterm and Chrome to play nicely together for selecting text in xterm and pasting it into Chrome (eg here). At the time I couldn't clearly reproduce my problems, so I wrote it off as due to fallible memory. Well, my memory may be fallible but I also wasn't wrong about Chrome not playing nice with xterm's normal selections. It definitely happens and it's one of the real irritations with using Chrome for me.

Certainly, sometimes I can select text in xterm and paste it into a HTML form field in Chrome with the middle mouse button. But not always. I'm not sure if it most frequently happens with the fields involved in login forms, or if that's just my most common use of moving text from xterm to Chrome. Of course, being unable to paste a complex random password is very irritating. As a result, I basically always resort to my way of making xterm do real Copy and Paste; this is longer, but so far it's always worked.

(Instead of 'select, move mouse over, paste with middle mouse button', it is now 'select, hit Ctrl-Shift-C, move mouse over, use right mouse button to bring up Chrome field menu, select Paste'. I could save a bit of time by remembering that Ctrl-V is paste in Chrome, but it doesn't yet quite seem worth doing that.)

Now that I look this seems to be a known issue, based on Chromium bug #68886. That's been open since 2011, so I doubt things are going to change any time soon. I guess maybe I should memorize Ctrl-V.

(I know, this sounds petty. But sometimes it's the little things that really get under my skin and rob me of confidence in a program. If I don't understand when and why Chrome is not accepting text I'm trying to paste in from xterm, what other unpleasant things are lurking in its behavior that I just haven't stumbled into yet because I don't (yet) use it enough?)