More Firefox 3 SSL Junk
Lately I've noticed a flood of Firefox 3-related posts regarding the new SSL error handling on Planet GNOME. It's a little funny, as I was writing about this myself a little under two months ago.
Chris Blizzard posts in favor of the new arrangement, and points to an interesting post by Johnathan Nightingale explaining Mozilla's position. Yes, agreed, Jonathan's post is a good read, but the salient point is that the new UI is just awful from an average non-technical user's perspective.
The extra clicks and somewhat abnormal flow (e.g. the need to click a button in the dialog to fetch the certificate) make it harder for the user to understand how to successfully add the exception. You might say that some false positives (i.e., users who fail to access a site that they really actually do want to access) is better than a user succumbing to a MITM attack, but I'm not sure I'd agree.
Equally importantly, the error messages make no distinction between the potential severity of the various SSL errors. For example, I'd say a self-signed cert on a site that you've never visited before is fairly low-risk. But a self-signed cert on a site that used to have a trusted cert would be a huge red flag. Domain mismatches and expired certs would fall somewhere in between. It's hard for the average user to make an informed decision on risk/severity if they were to encounter both of these situations because the error messages and dialogs look exactly the same.
Addressing Johnathan's main point about self-signed certs and level of security: as a highly technical/advanced user, I personally can say that, in the vast majority of instances where I encounter a self-signed cert, I really do just care about the encryption, and I don't particularly care about the identity verification of the site that a trusted cert could offer. Now, Firefox probably shouldn't use me as an example as a target user that needs protection, but that's a data point nonetheless. I don't care for things like: Bugzilla installations, my blog, accounts at sites like identi.ca, Twitter, Slashdot (they don't offer SSL at present, but if they did...), etc.
Pretty much the only time I do care are for financial institutions. And guess what? They've already decided that SSL as used for identity verification is useless! Most of them (I can only think of one that I use that hasn't) have already implemented a "security image" system wherein I pick a random image that gets shown to me every time I log in. If a site claiming to be the site I want shows me an image I don't recognise, I'll know that the site is a fraud. Is it perfect? Probably not. But it's orders of magnitude better then what SSL error dialogs offer.
And I guess that's really it: as much as I hate the phrase, I really think that the SSL error dialogs are "a solution in search of a problem." In the cases where I care about site spoofing, the sites themselves have already implemented a better solution. In the cases where I don't care, well... I don't care.
Microblogging
I’ve had a Twitter account for a while, though I never really made much use of it. I recently signed up for an Identi.ca account as well. I was pointed to this video which tries to show how Identi.ca isn’t just another Twitter. My understanding is Identi.ca is mainly an interop and OSS play, which certainly appeals to me. Identi.ca also lets you use your OpenID to log in and set up an account, which is cool (despite OpenID’s inherent phishing problems that its designers have chosen to ignore).
But, as we all know, the value of such a tool mainly lies in network effects. So, who has an Identi.ca or Twitter account? Feel free to subscribe to my feed or drop me a note so I can find you.
Since I don’t write (publicly) in this blog so much anymore, perhaps microblogging will be my next public “thing.”
Microblogging
I've had a Twitter account for a while, though I never really made much use of it. I recently signed up for an Identi.ca account as well. I was pointed to this video which tries to show how Identi.ca isn't just another Twitter. My understanding is Identi.ca is mainly an interop and OSS play, which certainly appeals to me. Identi.ca also lets you use your OpenID to log in and set up an account, which is cool (despite OpenID's inherent phishing problems that its designers have chosen to ignore).
But, as we all know, the value of such a tool mainly lies in network effects. So, who has an Identi.ca or Twitter account? Feel free to subscribe to my feed or drop me a note so I can find you.
Since I don't write (publicly) in this blog so much anymore, perhaps microblogging will be my next public "thing."
My Birthday is Awesome
The 4th of July is the opposite of other holidays like Christmas or Halloween where there's a lot expected of you. You're expected to buy presents, or you're expected to have a snazzy costume. The 4th of July only asks that you show up and get totally relaxed. It's an [sic] big eating holiday, but unlike Thanksgiving, the most complicated cooking involved is placing a burger onto the grill and then taking it off the grill.
(from SIMYP)
Social Fallacies
I ran across this list of Geek Social Fallacies yesterday. It's a pretty old list; I'm surprised this is the first time I've seen it. It's pretty interesting, and, I'd wager, pretty accurate. I've seen these everywhere to varying degrees in the OSS world. Personally I tend to suffer a lot from #3 (though I usually recognise this one and realise that most, if not all, of my friends aren't like me in this regard, so this tends to not be that bad at all), and quite a lot of #5 (when I'm on the receiving end of a lack of an invitation, it can hit me pretty hard).
I see a lot of #1 among OSS contributors. Many OSS people seem to believe that everyone's opinion has equal value, or at least should be considered with equal weight. I often see "poisonous people" who just like to rant, or don't understand a particular community. Sometimes they're actively malicious, and sometimes they're genuinely trying to help, but don't understand what's going on to actually be useful. Often these people will never get it, and in these cases I greatly advocate cutting them off and kicking them out. Unfortunately, a lot of people see this as rude, or anti-community, or some bullshit like that. Sorry, but the real world just doesn't work that way: some people just don't, and can't, belong.
As for #4, it's often a shame. I'm fully aware that I have different groups of friends for a reason, and that in most cases, my different friends wouldn't really get along. Not that they'd be actively hostile, just that they wouldn't find much in common and would probably be bored with each other during extended interaction. It's pretty rare that I introduce friends and they actually hit it off.
2 is actually pretty rare in my experience. Personally, I tend to believe that my close friends do accept me as I am, and actually because of that, they're the ones most likely to criticise me when I'm acting like a dick. And I (usually) welcome that.
Anyhow... pretty interesting.
Getting help with Xubuntu
Even though I’d very much like to say the opposite, most people will probably need help with Xubuntu at some point. Luckily, it is quite easy to find help – you just need to know where to look.
First of all, you need to determine what kind of problem you are having.
Getting started
If you are new to Xubuntu, you will want to read the excellent Xubuntu documentation, that is also shipped with Xubuntu (in version 8.04 it is located under /usr/share/xubuntu-docs/index.html). It should be your first stop when trying to figure out how to connect to the internet, how to install applications, and similar basic tasks. All this thanks to the huge, voluntary efforts of the Xubuntu Documentation Team (you can also help out with the Xubuntu documentation yourself!).
Of course, if you want to perform slightly more advanced tasks, such as setting up periodical backups on Xubuntu, the internet is your friend. There are a lot of great resources on the internet that can help you with anything from installing Xubuntu on the Eee PC to browsing Windows network shares with Thunar. However, be sure to double-check which version of Xubuntu the guide is written for. For example, the post on browsing Windows network shares I just linked to is, at the time of writing, a little outdated and contains unnecessary steps.
It is also safest to look for articles written specifically targeting Xubuntu – tutorials aiming at Ubuntu users will often work as well, articles targeting just “Linux” are less likely to result in success.
When you can’t find the answer
If you’ve spent time roaming the dark alleys of the internet, spit through every last bit of Xubuntu’s official documentation, but still don’t have an answer, there are a number of support options.
One requirement for all these options is that you specify as much information as possible. This includes, but needn’t be limited to, the fact that you’re running/wanting to run Xubuntu, which version of Xubuntu you’re running, what you’re problem is, what the expected result is, and perhaps how proficient you are with Xubuntu. This allows other people to help you in the best possible way.
The xubuntu-users mailinglist is, well, a mailinglist for Xubuntu users. All messages sent to a certain email address (xubuntu-users@lists.ubuntu.com in the case of xubuntu-users) will be delivered to everybody who has subscribed to that mailinglist. Thus, if you need help with Xubuntu, you can subscribe to that mailinglist, send an email to that address explaining your problem, and perhaps the next time you check your email, the answer is waiting for you.
You might not have the patience to wait for people to respond, however. If that is the case, fear no more, as IRC comes to the rescue! IRC is a way of being able to communicate in real time with other people – in other words, a chatbox. First you need an application to talk IRC – Xchat, DarkIRC, whatever, it shouldn’t really matter. Using your IRC client, you need to connect to a network – FreeNode (on irc.freenode.net) in this case. Once you’re connected to the network, you need to join the appropriate chatroom (how old-school is that?) – the Xubuntu support room (or channel in IRC lingo) is #xubuntu. You can join by typing /join #xubuntu.
Once you’re in – ask away! Be sure to be polite, not to spam the channel, and realize that, if nobody answers, probably nobody knows. Don’t ask the same question over and over again.
It is no secret, however, that the Xubuntu community is not quite the size of the Ubuntu community. Luckily, many people in the Ubuntu community can also help you with your Xubuntu problems if nobody in the Xubuntu community can. The place to get help from the Ubuntu community is the Ubuntu forums. With a very large amount of active members, your question is very likely to find an answer here.
Another place to get help is at Launchpad answers, which is part of Launchpad, a project management website where Ubuntu is managed. Here, you’ll be more likely to find developers, who are most likely to be able to help you.
When there is no answer
Even with this vast range of support options, some problems are just errors in the software – so called bugs. These can be reported at bugs.ubuntu.com, where a developer can look at it and, if you’re lucky, provide a fix for you and other users to enjoy.
Conclusion
Of course, there will still be times when no answer can be found. However, after having read this article, you’ll hopefully be able to better find help yourself. And of course, if you cannot find help, feel free to ask me – I may not be able to provide an answer, but I might be able to give you some pointers.
Advogato?
Some time ago I registered an Advogato account, but never really did anything with it. I was just poking around, and it seems there isn't much I can do with the site without being certified by some unknown number of people first. So, if you believe that I'm actually me, and have an Advogato account, gimme some kind of certification.
Future of Foresight Linux – Xfce Edition
There haven't been much updates on Xfce Edition for a while, becauseI was busy with re{decorating,novating} my apartment, planning my upcoming wedding, my job and so on.
Here are some News, I have changed Plans for Xfce Edition a little bit. So read on.
When I had a look at the plans for Xfce 4.6, I realized, that Xfce 4.6 might be closer than I thought (there will probably be delay, as it is software (think of gnu/hurd or dnf)). Anyways here is the new plan. It's pretty simple: "Concentrate on 4.6. Go with the Milestones and have a final shortly after Xfce 4.6 is released".
Some development will take place on xfce.rpath.org, to not break all the Xfce 4.4 things wie already have on foresight.rpath.org. There is a mailinglist too. Helping hands are welcome.
HTTPS is broken and Firefox 3 makes it worse
[Note: this is mainly a long rant. If you're just curious about my possible solutions, scroll to the last few paragraphs.]
I've been using the Firefox 3 betas (and now release candidates) for quite a few months now, and overall, I think it's a great improvement over Firefox 2. My main issues in the past with FF2 have always been with performance and memory usage, and FF3 seems to go very far in addressing both of these (though there's always still room to improve).
However, there's one thing I just can't get over: the SSL error pages. Before I describe FF3's added annoyance here, let me start by saying one thing: the HTTPS model is broken and much less useful than it could be.
Why?
Because the HTTPS/SSL model tries to simultaneously combine two things: encryption and authentication. When you visit a HTTPS site, you get an end-to-end encrypted connection between your web browser and the web server, obviously. But you also get something else, in theory: assurance that the web server on the other end is actually owned and operated by who it says it is. This is done through a hierarchical certificate signing scheme, wherein the browser knows a few "trusted" root certificate authorities (CAs), and any web server SSL certificate that wants to be considered "trusted" (as far as the browser is concerned) needs to ultimately be signed by one of those root CAs. (In practice, this doesn't mean each and every web server SSL cert needs to be signed by a root CA, just that every trusted SSL cert needs to be signed by another signing certificate that was signed by a root CA, or by another signing cert that is signed by a root CA somewhere in its ancestry.)
So where's the flaw? Getting your SSL cert signed by a trusted cert authority costs money. This is fine for banks, but not so fine for some random guy who just wants secure communications with his home server, or webmail, or just a small self-funded website where an encrypted connection makes sense. A semi-solution is self-signed certificates. You can create your own SSL certificate, and your web server will use it, and people who connect to your web server on the HTTPS port will get encryption. But, as far as the browser is concerned, your cert isn't signed by anyone on its trusted list.
So, the website visitor is usually presented with a confusing dialog box warning that the website they're visiting shouldn't be trusted. Visitors who understand all this stuff just roll their eyes, click the "allow" button and go on with their day. People who don't really understand all this, but just want to visit the site, blindly click "allow" and go on with their day. Some panicky users may freak out, click "cancel," and not visit the site.
The people in the middle there are the ones in danger. Blindly accepting dialog boxes just to get them out of the way can get you in trouble if the dialog box is actually warning you of something important. In the context of visiting Gentoo's HTTPS bug tracker website, the warning actually is unimportant: Gentoo is just using a self-signed cert to avoid paying for a "real" cert, and just wants HTTPS for the encryption, not for the authentication. However, in the context of Bank of America's online banking service (just to pick one), the warning is very important: it likely means that someone has intercepted your communications and is trying to masquerade as BoA's server so they can steal your bank account credentials. Or it could also mean you typed the URL incorrectly, and someone malicious has registered the typo-hostname in the hopes of snaring someone with careless fingers.
So there's a problem, definitely. The Firefox 3 developers have chosen to attack this problem by attempting to push people into the panicky-user camp, though they misguidedly believe that they're actually getting users to try to read the messages and make an "informed" decision (despite the fact that they haven't given -- and really can't give -- enough information to inform most users). The new SSL error pages in Firefox 3 put up a scary, confusing, uninformative message right inside the browser window. The message, at first glance, looks reminiscent of one of the several "connection error" messages, so the first reaction is to look up at the address bar to see if you typed the address correctly, and then wonder why the site is down. Then you go and read the error message. Basically, it says a lot of confusing things -- including a semi-raw error enumeration code that is sure to confuse the user even more -- with a very short explanation of the real problem: "The certificate is not trusted because it is self signed." What are the chances that the average user will know what this means? Slim to none.
Then there's some text about adding an exception, and instead of a button, a URL link (in a small font) that you can click to add an exception. Well, sorta. Clicking the link merely modifies the error page to display another semi-scary message, and then shows two buttons: one with a stupid caption: "Get me out of here!" (don't get me started on this one), and the other saying "Add Exception..." Ok, fine, so I click "Add Exception..." Now I get a dialog box, and my eyes automatically seek the bottom of the box, assuming the "confirm" button will be there, waiting for me to click. But it's not. It's there, but it's disabled. Huh? So I look up higher, and I see that only two buttons can be clicked: a "Cancel" button (well, duh, obviously that's not it), and a "Get Certificate" button. Ok, well, I guess I'll try that one. Now the text in the middle of the box changes to tell me "Certificate is not trusted, because it hasn't been verified by a recognized authority." What? I know what all this stuff means, and I have to read it twice to get it. Your average user doesn't stand a chance. Finally, though, the "confirm" button is active, and they've helpfully (wow, they actually did something remotely helpful here!) pre-checked the "Permanently store this exception" check box for me.
So, in total, I have to make four clicks, plus read a bunch of confusing terminology, to get to a website with a self-signed SSL certificate.
This sucks. The UI is absolutely terrible, and the average web user is going to have no idea what's going on. According to the Firefox developers, one of the goals of these new error pages is to cut down on "dialog box whack-a-mole" where users just blindly click to get the dialog out of the way. I fail to see how this is going to help. Some users will now get even more confused, and not visit the site. For the extremely rare case where a malicious site is masquerading as the site they actually want, this is good. But for the much more common case of an innocent site that just wants SSL for the encryption, this is bad. And for most of the users in the "blindly dismiss" bunch, they'll just get used to blindly dismissing this new page+dialog in record time.
What's the real solution? Ideally: scrap the current system. There's no reason why connection encryption needs to be so tightly coupled with authentication/identification. Design a new system, possibly with a new protocol scheme. One scheme should be used for "strong" security, where both the identity of the site and cryptographic strength of the connection are checked. The other scheme will just check the encryption. Users will need to be educated that you never try to connect to your banking site using the less-secure scheme. Sure, user education is always a problem, but it's a problem we still face with the current non-solutions in place.
Of course, in the real world, we can't just scrap a protocol that has been in use for over a decade, and expect everyone (web servers, web browsers, the cert-signing industry) to change overnight -- or at all.
So I'd advocate dropping all the panic about self-signed certs and, in addition, handling HTTPS sites by keeping more state about them in the browser. For starters, at the simplest level, let's stop putting up scary messages when we hit a self-signed site. We're already coloring the address bar differently for HTTPS sites; why not have a different (slightly scary?) color for HTTPS sites that use self-signed certs? There could even be an easily-disableable bubble popup (that doesn't take focus!) that points out the "problem" and is clickable for more information. Or something like that. At minimum, if you visit your bank site all the time and don't see this warning and color change, you'll think twice the time you do.
But to make this stronger, the browser can keep state about the HTTPS sites we've visited. Odds are, the first time you visit your banking site, it'll probably be all correct and proper. So the browser notes the cert's fingerprint, and the fact that it's signed by a "trusted" authority, and checks it every time you visit the site. If the cert changes, and is now self-signed, the browser can raise a larger red flag: "Hey, this site that you visit all the time that usually has a trusted cert? Well, the cert is now self-signed and this might be someone trying to trick you."
What about "phishing" attempts that use common misspellings? Well, if the browser knows that I've visited https://bankofamerica.com/ in the past, and it had a valid, trusted cert, and now I've visited https://bankofamarica.com/, and it not only has a self-signed cert, but has remarkably similar spelling to another site I visit that has a trusted cert, the browser can raise another big red flag. Finding similar spellings is nothing new: there are algorithms to do this that are old and very well-established.
How about phishing attempts that hide the true website URL by using an inline username/password string that looks familiar to the user? Well, we already cover this: Firefox pops up a dialog asking if you really want to connect to the site, presenting the real hostname, and showing the username passed in the URL. So, this new scheme doesn't harm this case's solution.
End rant.
WordPress 2.5.1 hates mod_security, sorta
I upgraded to Wordpress 2.5.1 a few weeks ago. Overall, it seems pretty nice.
Friday, everything was fine. Saturday, I tried to make a post, but when I clicked the "Publish" button, I got a blank webpage. Suck.
So I spent a couple hours (ugh) tracking the problem down today, and finally discovered this in the Apache error log:
[Sun May 25 14:41:59 2008] [error] [client 24.130.18.75] mod_security: Access denied with code 503. Unknown error [severity "EMERGENCY"] [hostname "spuriousinterrupt.org"] [uri "/journal/wp-admin/admin-ajax.php"]
Not a particularly useful error message. Fortunately, my web host (Dreamhost) allows me to disable mod_security on a per-domain basis, so I tried that, and voila, everything works fine. Presumably my web host upgraded mod_security, or changed its configuration, sometime between Friday and Saturday which broke things, as I didn't change anything with Wordpress or my website.
So, if Wordpress breaks for you at some point, be sure to check your mod_security configuration, or temporarily disable it entirely to see if that's the problem.
Hopefully Dreamhost can help me find a better solution than disabling it entirely...