Wandering Thoughts archives


My view on vi and vim (and nvi et al)

I have a confession: for all that I use it fairly often, I am a fairly basic user of vi. As such, I have a pretty unsophisticated view of what vi is; if I type 'vi' and something starts up that behaves like vi and is not too freakishly super-intelligent, I call it vi and don't think more about it, regardless of the name of the actual implementation. Unless I actively think about it, I'm only vaguely aware that there are at least two reimplementations of vi (vim and nvi), each with their own distinct additions to the original vi. I'm not generally conscious of any differences, and I'm certainly not sophisticated enough to notice any incompatibilities with 'classic vi' (which is still found on operating systems like Solaris 10).

Calling everything 'vi' is a bit sloppy of me, and no doubt confuses some people (and may irritate others). But it really is how I think about this; for my purposes, the advanced features of vim and nvi and so on are pretty much irrelevant, because all I ever use is a subset of basic vi.

(This is much the same way that I call /bin/sh 'the Bourne shell', regardless of which implementation it actually is, and I expect that all competent implementations will behave similarly enough that I can not care. If you force me to care, I will deduct points.)

Well, this isn't quite true. It turns out that there are two features of modern vi reimplementations that I really miss: multi-level undo and the ability to backspace back to a previous line. While I won't go much out of my way to get a version of vi that has them installed on a random machine (for instance, I certainly won't compile my own version), I will switch to using a version of vi that has those features if it's already there. But I still don't really pay attention to what version it is, and I still call all of them 'vi', despite this being technically incorrect.

(I actually don't know if anything but vim supports those two features.)

If I used vi intensively, this ignorance would be reasonably foolish; I could probably significantly improve things like editing code by learning the more advanced features of the vi family. But my vi usage is reasonably casual; I have other editors for more involved text editing, and most of my vi skills have basically been acquired through osmosis and other peculiar means.

(I believe that I learned a reasonable chunk of vi by going through the old BSD vi tutorial but in another editor, which sort of robbed the embedded editing exercises of their teaching power. Still, a reasonable amount of that has stuck with me, so it wasn't a total failure.)

unix/ViAndVimAndMe written at 23:13:06; Add Comment

Server problems caused by 'transparent' self-signed SSL certificates

One of the issues with allowing self-signed SSL certificates to be automatically used for transparent encryption over https URLs is the problems that they cause for server-side applications.

Right now, a server-side program that care can more or less assume that a SSL-encrypted connection means either that it is securely talking to the real end user's machine or that the end user has been actively compromised (which it can't do anything about). It may thus use things like 'you can only talk to this service over https' as a reasonable security precaution, one that means something.

If you allow self-signed SSL certificates to be used transparently for encryption in https URLs, you enable relatively trivial man in the middle attacks. This negates all of the security properties of SSL connections. Because the browser knows what level of security the certificate it accepted had, browsers can recognize this and lie to things like Javascript so that nothing thinks it's getting more security than it actually is.

However, the web server does not know and cannot know this information, since it has no way of finding out if it is talking to the real end machine or to a man in the middle. As such, server side applications can no longer assume that a https URL and a SSL connection means actual security; it might be secure and it might not be, and they can't tell the difference. This leaves them with no way to require something approximating actual security from clients, and it breaks current applications (to the extent that they assume that SSL means security).

(Server side applications cannot do things like feed Javascript to the client browser to see if it is really connecting directly to them, because the man in the middle can rewrite that Javascript on the fly.)

(In theory the one way out of this is to require everything to have client side certificates. However, I do not believe that this is any more practical than trying to make all server side applications instantly give up any 'SSL means security' beliefs that they may have.)

web/SelfSignedServerProblems written at 03:15:45; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.