Encryption and security - an overview
I would really have loved a debate / educational description from the guru's / opportunity to learn something myself about silc over ssh vs. the "secure " setting in yahoo vs. outlook vs. pine security
maybe some opinions about the "I don't get viruses because I'm opensource" vs. uSoft vs. apple -
And my answer:
OK. Here goes. You asked for it.
I'm unfamiliar with "silc", so I won't talk about it.
- - -
Encryption comes in two forms: symmetric and asymmetric.
Symmetric encryption is anything where the same key is used to encrypt and to decrypt. As a really trivial example, an encryption scheme where you add one to every byte in the file. In this "add" algorithm, 1 is the key. It is symmetric, because you can subtract that same key from an encrypted message to get the original back.
Of course, a simple "add" encryption scheme is pretty useless and is easily broken. But many more complicated schemes (like DES) are also symmetric. Although the decryption algorithm may be different, the decryption key will still be symmetric.
Symmetric encryption can be very secure, but it has one big loophole. Both the sender and the receiver need to have the same key. Which means they have to trust each other. If you send me a file encrypted with a symmetric algorithm, you have to give me your key as well. If a third-party gets your key, he can intercept your document in transit, decrypt it, modify it, re-encrypt it, and send on the result. I have no way of knowing that the file was tampered with.
Asymmetric encryption solves this problem. With asymmetric encryption, the key you need to decrypt a message is different from the one you used to encrypt it. To be properly secure, it should not be possible to derive one key from the other (or at least not without a LOT of work.)
Most modern encryption systems use (at least partly) a thing called public key encryption. This is a variation on asymmetric where the key pairs are interchangeable. That is, if I have a pair of keys (A and B), I can encrypt with either one, and the result can be decrypted by the other. When you generate a pair of keys, you give one (the public key) out to the world and you keep the other (the private key) to yourself and never give it out to anyone.
Now, suppose you send out a document encrypted with your private key. Anybody in the world can read it (because you've made your public key available for the taking), but because they have to use your public key to decrypt it, they know that you were the originator of the message. If someone else tried to forge the message in your name, your public key wouldn't work on it. If a third party decrypts your document and alters it, he can't re-encrypt it, because he doesn't have your private key.
Similarly, suppose I send out a document and I encrypt it with your public key. Only your private key will be able to decrypt it. So I know that only you can read the message. But anybody could have sent it to you (since everybody can get your public key.)
Ideally, you'd want to get the benefits of both. So I can encrypt the message first with my private key, and then again with your public key. Now, only you can read it, and you know that only I could have generated it.
Public key encryption is computationally expensive, so it generally isn't used for encrypting actual documents. Instead, it will be used as a part of a key-exchange algorithm. A symmetric key will be randomly generated, used for one session only, and will then be discarded. Public key encryption is used for one side of the connection to give the key to the other side, so that third parties can't intercept it.
- - -
ssh is primarily meant to be used as a replacement for telnet (and related utilities like rlogin, rsh and rexec). The reason for this is that the telnet protocol (and rlogin/rsh/rexec) have minimal security. They do not encrypt their connection.
This means that anybody sharing a network with you, the remote host, or any network in between, can see everything you're doing. It's trivially easy to get a PC to intercept all the packets that flow through an Ethernet network, and it's often not too difficult for an administrator to do this on other kinds of networks.
Someone snooping on a telnet/rlogin/rsh/rexec session can easily mirror your session. He can see everything you type (including passwords) and everything you see/download.
This doesn't often happen, because most internet service providers are trustworthy. But there are still cases where people on corporate and campus LANs have stolen sensitive data this way.
This also happens over wireless networks, like those found at trade shows and internet cafe's. WEP (Wired Equivalency Privacy) provides some degree of security, but WEP can be cracked by a good hacker, and it won't stop someone who knows the encryption key (like anyone that has paid for time on the wireless LAN.) Future developments in the areas of Wireless Protected Access (WPA) will be more secure, but they still may not be able to protect you from someone that has legitimate access to the LAN.
ssh solves this problem by encrypting everything. It also provides some optional features that will only allow people with pre-assigned security credentials access. So someone snooping your packets will get complete garbage.
Although I regularly use telnet/rlogin/rsh/rexec for local traffic (between two computers at home or two computers at work) I try to avoid using it over the internet.
Also as a part of the ssh distribution is "sftp" which is an encrypted version of the FTP protocol. FTP suffers from the same problem as telnet - passwords are sent without encryption, so a third party could intercent them.
- - -
The "secure" setting in Yahoo's login page isn't really much in the way of security.
As I'm sure you're aware, you can encrypt web connections, as long as the server supports it. Encrypted URLs usually beign with "https:". (The "s" stands for "secure".) The HTTPS protocol can use a wide variety of different encryption standards, some more secure than others.
Most web browsers will let you know when the page is secured. Typically with a padlock icon or other appropriate icon in some corner of the browser window. You can usually click on this to view the page's security information (including the kind of encryption, the certificate providing the encryption keys, and the identity of the authority that generated the certificate.)
Any kind of encryption will keep third parties from snooping your packets. Encryption protocols with more bits in the key will be harder for third parties to crack, although anything can be cracked by someone determined enough.
You still have to decide whether the server on the other end can be trusted, of course. This is where the certificate and certificate authority comes in. A site's certificate identifies the owner of the site (usually including name and address contact information.) The certificate's data includes some encryption/authentication data to keep a third party from tampering with it. Part of that information involves a certificate from a certificate-agency. This means that that agency is vouching for the content of the certificate.
The idea here is that a rogue web site may try to impersonate a real one. For instance, an identity theft ring may create a server that looks like Citibank's server. Citibank will, of course, have a certificate that identifies them, but the rogue site will probably also have a certificate. So that alone isn't enough to make things secure.
The certificate authority takes care of that. Citibank's real certificate will be signed by an authority (Citibank uses Verisign, if you're curious). When you choose to view the certificate, you will see that it is signed by Verisign. Your web browser can use Verisign's well-known public-key (built-in to most browsers, and available for download from others) to validate that the certificate is, in fact, genuine.
If the rogue site tries to use the same certificate, it won't match the server and your web browser should alert you. If they try to alter the certificate, it will no longer validate against Verisign's public key - only Verisign can issue certificates that their public key can decode.
Yahoo's secure login is the same as the regular login, except that it goes through their secure server. This means that someone snooping your packets won't be able to get your password. Whether this is important or not will depend on if you trust your LAN, your ISP, Yahoo's ISP, and Yahoo's LAN.
Of course, you still have to decide whether to trust Yahoo or not. No protocol will help you here. But HTTPS will let you be certain that the remote server really is Yahoo, and that no third party will intercept your login data.
- - -
When people talk about Outlook's security, they are usually talking about something else. The problem there is how it handles attachments.
People attach all kinds of files to all kinds of mail messages all the time. If I e-mail you a picture of somebody, it gets sent as an attachment. If I e-mail you a Word file I want you to read, it gets sent as an attachment. And if I e-mail you a program, it gets sent as an attachment. If I send you an HTML-formatted mail message with an image or background music or something, attachments will be used there as well.
All mail programs (well, all except the oldest and simplest ones) can deal with attachments. Either they make you save the attachment, or they may launch an external program for viewing it, or they may launch a plugin to view it, or they may be able to view it directly.
Outlook's problem comes from the way it launches attachments. There have been many bugs (most have been fixed by now, I believe) that will cause Outlook to automatically execute a program or a script that is sent in an e-mail attachment (usually with the message malformed in such a way as to trigger the bug.)
Once this happens, the program is running on your computer like any other program. As such, it can do anything. Worms (which are effectively virussses that spread to other computers on their own) often exploit this. They will e-mail themselves to others in a way that takes advantage of these kinds of bugs, so that the receiver will end up auto-launching the program, causing the worm to spread further.
The reason so many people hate Outlook is that these kinds of auto-launch bugs are extremely rare (and sometimes unheard of) in other mail programs, but Outlook has had tons of them over the years.
But the worms have been getting trickier. As Microsoft has fixed the various bugs that can cause executable attachments to auto-launch, the people developing the worms have gotten sneakier. Usually, they take advatage of human gullibility.
For instance, the worm may include (in the mail message's text) a message telling you that the attachment is a critical system patch from Microsoft, or an updater to some popular program, or a program needed to prevent your bank account from closing, or other similar gimick. The user who trusts this message and runs the program gets infected with the virus/worm, and it spreads further on.
Antivirus programs routinely check e-mail for virusses and worms these days, so this works less often than it used to. So the virusses now often pack themselves into zip files for e-mailing. The idea is that virus scanners may avoid scanning a zip file. The message will direct the user to unpack the zip and run the contents - at which point the virus gets launched.
But virus scanners now scan the contents of zip files.
Which is where this new "Beagle/Bagle" virus comes in. Zip files support built-in encryption. This way, only an authorized user can see the contents of the file. Obviously, if the zip file can't be opened, then a virus scanner can't scan the contents.
So the Beagle/Bagle virus sticks itself into an encrypted zip file. In the e-mail it sends itself through, it tells the recipient what the decryption key is. If someone is gullible enough to expand the zip, enter the decryption key, and run the contents, the virus will run.
- - -
In addition to these kinds of virusses, some popular tools that have macro languages (like the parts of Microsoft Office) can also be vectors for spreading virusses. A macro in a Word/Excel/PowerPoint document can spread to other documents and can even e-mail itself elsewhere.
Fortunately, today's virus scanners are smart enough to scan the contents of office documents. It's also easy to disable all macro capability in MS Office, which is usually a good idea, since very few people actually use them.
- - -
To be on the safe side, many people simply refuse to look at any attachments whatsoever. And with web-mail services and AOL (and possibly a few others) this is easy - you don't even have to download the attachment from your server if you want to delete it without opening it.
But IMO, this is overkill. And it's not an option for many people.
For instance, I often send and receive pictures with my friends and relatives. I also send and receive Microsoft Office documents all the time as a part of my job.
Fortunately, it is easy to spot executable attachments with most mail programs. Look for a MIME type like application/octet-stream (a generic binary file, usually used for program files), or application/vbs (Visual Basic Script), etc. And look for file extensions like .exe, .vbs, .com, .bat, .pif, etc. If you have Windows configured to hide extensions (the factory default setting), change that configuration so you can see them.
As a second line of defense, get a good virus scanner (most people I know use either NAI/McAfee or Symantec/Norton) and keep it up to date. Updates come out frequently - sometimes more than once per day. Antivirus packages all include an auto-update facility where they will periodically download updates from the publisher's web site. Home editions of these program require you to buy annual subscriptions to keep getting updates, while corporate editions typically do not.
- - -
In addition to virusses, there are a few other potential security risks to e-mail that some programs make you vulnerable to.
For instance, HTML e-mail. HTML is useful and cool. It lets you send mail with nice formatting, colors, fonts, images, etc. You can also include links to remote sites, and have remote references to objects on web servers (like images, sounds, etc.)
The problem is that this can create a security problem. For instance, suppose I send you an e-mail with a reference to an image on my web server. You open the mail, and your mail program fetches the image from my sever. You see the image and all's well.
Now suppose I'm a spammer and do the same thing. You think "no big deal" and just delete the spam. But I own the web server. Suppose I send out a million spams, and that image-reference has a slightly different name in each one. I keep a list of which e-mail addresses got which image-references. I can look at my web server's log file and find out which of those image-references were used to download images, match them against my list, and bingo! I now know which people actually read the spam (as opposed to those that deleted it without opening, or those that never received it.) Since I know somebody's reading spam at that address, I'm going to start sending him lots more.
Some mail programs and web sites (like Mozilla and Yahoo) now provide options to block all remote-image references that appear in mail. This keeps the spammers from knowing that you've read their spam.
Finally, e-mail may contain data for popular plugins, like Shockwave Flash files. Most plugins are reasonably safe, but some are not. And some of the safe ones can open up network connections, which can alert a spammer that the spam has been read. Again, good mail clients let you disable plugins from e-mail.
Of course, you do not want to have your mail client set to generate return receipts, even if you receive mail that asks for them. Again, this will alert spammers that someone's reading the spam.
And NEVER send mail to a spammer's "unsubscribe" address. If you do, you'll give him concrete proof that someone at your address is reading the spam, and you'll get even more.
- - -
WRT pine, I can't help here. I haven't used pine in a very long time, and I didn't bother to learn much about it back then.
Microsoft has put some of this into the newest version of Outlook, but existing copies leave a lot to be desired in this department.
- - -
In the "I don't get virusses" department, it's true. Some people don't get them. But if anyone says that they can't get them, they're just lying.
A savvy Windows user can almost always eliminate virusses. You can use a mail client with good security in its design. You can install a virus scanner set to scan all files and have it auto-update on a daily basis. You can turn off unused network services. You can use an intrusion detection package (like ZoneAlarm) and you can use a firewall on your network.
But even with all this, it is possible to get a virus. Everybody's human and it is always possible that someone may trick you into running an infected program.
There have even been cases where a software publisher has been infected, and the virus spread through CDs bought in stores. I, personally, have been infected by a virus that came in through Microsoft's "Windows Update" server. But if you stay alert and make sure your virus scanner is always running, you can reduce your risk to a minimum and minimize the damage when something hits.
People using other operating systems can afford to be a bit more cavalier. There is a certain amount of "security through obscurity". People don't bother making virusses for Linux, MacOS, OS/2, BeOS and other low-popularity operating systems. Not because it's impossible, but because such a virus won't spread very far. If I infect every Mac that exists, I only get 3-5% of the computers in the world. If I infect 10% of the Windows machines, that's 9.5% of the world. If I infect every OS/2 system that exists, I probably get only a fraction of a percent of the total amount of computers.
In other words, writing virusses for Windows gives the greatest bang for your buck.
10-15 years ago, when most computers on the internet were university mainframes, you found a lot more UNIX-based worms. But now the quantity of UNIX boxes on the internet are dwarfed by the number of Windows PCs attached to DSL lines and cable modems. And these PCs are every bit as connected as those university mainframes used to be.
It is definitely possible to write a virus that targets MacOS, Linux, or anything else. And even though these virusses may require administrator access to do real damage, I'm sure that lots of users could be conned into typing in their admin passwords, just like Beagle/Bagle got lots of people to manually decrypt a zip file in order to run the virus. And I'm sure lots of Mac/Linux home users run logged in as root or administrator accounts (just like most Windows NT/2000/XP users do their work from administrator accounts.)
If Linux or MacOS or anything else should someday become really popular, and not just niche products, I have no doubt that we'll start seeing lots of virusses that target these platforms. These operating systems may have security features that make it harder for virusses to auto-install, but as long as we have gullible users that do whatever random e-mails tell them to do, virusses will remain a fact of life.
And, of course, this is ignoring virusses that are scripts carried in documents (like MS Office documents). These can execute on Macs, just like on Windows, since the Mac version of Office uses a compatible scripting language.
- - -
I hope this answers your questions. My hands are tired now!
MacOS Panther - first impressions
I haven't really had time to put it through it's paces yet, but here's what I've learned so far.
The first thing I noticed is that the system is much faster than 10.2. The system boots up much quicker, applications seem to launch faster, and the GUI in general seems a bit snappier.
Unlike many people, I actually like the brush-metal appearance of the system.
Nearly all of my applications continued working fine after the upgrade. The big exception is Emacs - which I had to re-compile. The apps that I used so far without problem are: AOL Instant Messenger, Mozilla (both versions 1.5 and 1.6), AppleWorks, and FileMaker Pro. There are a lot more apps that I use regularly, but haven't gotten around to running them since the upgrade, but oveall, I get the impression that most programs should run fine.
One program that I must explicitly test is Retrospect. I currently use version 5.0 to make my backups. But 5.1 is the oldest version that Dantz has officially tested and certified with Panther. I plan on upgrading to version 6 when it ships next month, but until then, I hope I will be able to continue to make backups of my system. Given the low-level that Retrospect interfaces with MacOS, I won't just assume compatibility the way I would for other apps.
Update: Since I first wrote this article, I have had a chance to run Retrospect 5.0. It works just fine in Panther with my tape drive (A FireWire Exabyte VXA-1 drive.)
Expose' is way-cool. I didn't use it much, except to test it out, but it definitely works as advertised. I did notice, unfortunately, that you can not assign the F14, F15 and F16 keys as hotkeys for it.
The old "Key Caps" program is now integrated into the international settings. You can configure the language menu so that there's a keyboard map choice. This is much more convenient than launching Key Caps from the Utilities folder. One change I'd suggest, however, is that they provide the option to make the keyboard diagram bigger. On my 1920x1440 display, the keys are really too small to read comfortably.
I also noticed that they added many new keyboard maps. The two that I found of particular interest are a Unicode-based extended US-English map - which changes the keys for the accented characters (typed by holding down "option" while pressing other keys.) - and a "Hebrew-QWERTY" layout (where letters mostly appear over the keys whose English letters are pronounced similarly.) The normal Hebrew layout has the keys positioned the way they have been positioned on Hebrew typewriters - which is different.
The Font Book looks like a really interesting program. I barely scratched the surface of playing with it, however, so I really can't review it here.
Finally, the X11 server has been improved. There's a new terminal type defined, xterm-color, which allows color-using console apps to work as expected. xterm-color also works in the non-X11 Terminal windows. They also added a preference which lets you decide whether CMD-key sequences that the X11 menu bar uses should be handled by the X11 menu bar or be passed to the application (where they are seen as meta-key sequences.) This is very much appreciated, since a lot of X11 apps use the Meta key for different things.
I don't know what the folks at Apple were smoking when they designed sidebar for the new Finder. Although the general design is fine, they seem to have completely abandoned all concept of internal consistency.
When you double-click on a folder, a new window opens up with that folder. If you hold down option when doing this, the old folder will close behind you. This is the way MacOS has worked from the very beginning, and folders in Panther still behave this way. Icons in the Finder toolbar of 10.2 behave similarly (but using a single-click instead of a double-click.
But icons in the sidebar behave differently. When you click on one of them, the content of the current window is replaced with the target's contents. But the window itself is not resized or repositioned. You need to hold option down in order to make a new window open up from one of these icons. And there doesn't appear to be any way to make it open a new window and close the parent window (which is the behavior I really like - I got into the habit of option-clicking toolbar icons with 10.2.)
There is no need for this kind of inconsistency. They could just as easily have made these icons behave as the 10.2 toolbar icons behaved. If somebody really likes this new behavior, they could provide an option to have it go either way. I'm sure I'll quickly get into the habit of pressing option whenever I click on one of these icons, but I shouldn't have to change my habits over something as minor as this.
They also did away with the internet system preference pane. This is the pane where you configure your default mail and web application. Some of it's features (like the iDisk tab) have been moved into other preference panes, but the mail/web application preferences have been deleted. Now, in order to pick a default mail application, you need to launch the bundled Mail application and pick the default application from its Preferences page. Similarly, to change the default web browser, you need to launch Safari and pick the default application from its Preferences page.
This is a terrible design. The system setting that I use to decide whether my web browser is Safari, Mozilla, IE or something else should not be made as a part of any particular web browser. What if I should decide to delete Safari because I find I don't use it? All of a sudden, I can no longer change this setting. Ditto for mail (and I have occasionally considered deleting Mail, since I don't use it and probably never will.) There is really no excuse for this kind of behavior.
Apple's voice synthesis is still in the system, but it's quality has degraded yet again. When OS X first came out, the voices became choppy comapred to their performance on MacOS versions 7 through 9. Now, the basic character of the voices have changed. Certain words are pronounced differently from before. For example, I have my AOL Instant Messenger client speak the phrase "Jim has signed on" and "Jim has signed off" when my friend Jim signs on and off. This always sounded OK in 10.2. Now, however, the words "Jim" and "signed" are drawn out slightly more than they should be, and the pacing has changed, making the voice sound like it is a character in a sci-fi movie suffering from radiation posioning. All of the non-comic voices (Fred, Victoria, etc.) seem to suffer from this. Changing the speed of the voice doesn't help much.
The first time I used the System Preferences program after a new installation, it crashed. All I did was change my desktop wallpaper (and browse through the available images.) This only happened once, and I have since downloaded the updater to upgrade to 10.3.2, so I may not see it again. But it's definitely not a good sign when something like this happens.
Fast user switching works as advertised, but with a few differences:
- It's slower than advertised. If you switch to a user that's not logged in, it takes a significant amount of time to make the switch. Even when the user is logged in, there is a noticeable delay. My computer is a dual 1GHz G4 system with a GeForce 4MX video card. There shouldn't be this kind of delay on this hardware. Now I know why Apple always runs their demos on G5 systems.
- If the two users you're switching between have their desktops set for different resolutions, you don't get the rotating-cube effect. Instead, the screen fades to black and the new screen fades in. I can understand this, however - you are changing screen resolutions, which is something you really can't do in the middle of an animation and have it continue to look good.
- When you log off from a user, you go back to the normal login screen, with the still-logged-in users marked as such. This is OK, but I would prefer the option to automatically jump back to another still-logged-in user, especially if there is only one other logged in at the time.
- I don't think there is a way to log a user off without first switching to that user. It would be nice if I could remain at my user's desktop and quickly logout another user's desktop.
The Displays menu no longer shows all of my monitor's resolutions. My monitor has never been able to properly report all of its resolutions to MacOS - in 10.2, if I tell the Displays preference pane to only show supported resolutions, all but 800x600 become unavailable - but all of the major resolutions were still available from the menu bar icon. Now, the menu bar icon only shows 800x600 - meaning I have to go to the Displays preference pane in order to pick something else.
And while I'm talking about resolutions, the Panther installer reset every one of my user accounts (I have 6 right now) back to 800x600 resolution. This is probably related to the above issue with auto-detection, but it's still annoying.
I've also found that the resolution used for the login screen is the resolution of whatever user logged-out last. This is just silly. I would prefer that this remain consistent. Either hard-code one, or use the resolution of the root (or administrator) account, or provide a system preference. But not this.