[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docstandards-interop-tech] Doc standards interop agenda
Folks, attached is a DocBook section sample that can be used in the
scenario. The sample was graciously provided by Michael Urban. One question: what version of DocBook should we be validating with in our examples? This one is pointing to DocBook 4.4, though 4.5 is the latest... Best regards, --Scott Michael Priestley wrote:
--
![]() |
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE section SYSTEM "http://www.docbook.org/xml/4.4/docbookx.dtd" [ <!ENTITY smtp "SMTP"> <!ENTITY unix "UNIX"> <!ENTITY pop "POP"> <!ENTITY imap "IMAP"> <!ENTITY pgp "PGP"> <!ENTITY ssl "SSL"> ]> <!-- Sample graciously provided by Michael Urban --> <section> <title>Security and Privacy</title> <para> The subject of <quote>security</quote> as it applies to mail is really two subjects. On one hand, electronic mail can be used to spread malicious computer viruses or other programs intended to create unauthorized access or damage to a computer system or network. On the other hand, it is not very difficult for an unauthorized individual to <quote role="figurative" >wire-tap</quote> unencrypted mail as it moves around the Internet, compromising the privacy of those who are exchanging mail. It is important to remember at all times that Internet electronic mail (and, by extension, mail internal to organizations that are connected to the Internet) is <emphasis>inherently unreliable</emphasis> with respect to both security and privacy. </para> <para> In computer terminology, a <firstterm>Trojan Horse</firstterm> is a program or script that is secretly sent along via some apparently harmless carrier, and carries out some nefarious act when it reaches the system. While our interest here is in Trojan Horses carried with electronic mail messages, other possibilities include CD-ROMs containing software of uncertain origin, programs downloaded from the World Wide Web, and so on, all of which should be considered suspect sources. When a Trojan Horse has the capability of reproducing itself, either on multiple files on a single computer, or from one computer to another, it is termed a <firstterm>virus</firstterm><footnote> <para> Not all viruses are Trojan Horses, but they are most commonly disseminated through that mechanism. Some programs, termed <firstterm>worms</firstterm>, propagate themselves around a network by exploiting known security flaws. The distinction in terminology is sometimes a fine one, and a single program may have Trojan Horse, virus and worm elements. </para> </footnote> and becomes a much more public nuisance. </para> <para> Trojan Horses are common in Internet mail because <emphasis>it is extremely easy to forge Internet messages.</emphasis> Recall the &smtp; dialog in XREF. The only way the &smtp; server (and, ultimately, the recipient) has of knowing who the sender of a message is is on the basis of what it is told in this dialog, or in the message headers. It is not hard for a programmer to construct an &smtp; client that lies about this. Thus, it is easy to send someone a message that appears to be from a <quote role="figurative" >trusted</quote> individual containing a Trojan Horse. </para> <blockquote role="scenario"> <para> Evil Chris sends out a forged message to Leslie, appearing to be from Leslie's system administrator. <quote>Here is a new update to Microsoft Word. Please execute the enclosed installer.</quote> When the attached program file is executed, it starts up a program on the computer that relays a transcript of every key Leslie types on that computer (including passwords to other machines on the local network) back to Chris. </para> </blockquote> <para> In this scenario, the Trojan Horse is used in its classical<footnote> <para>Beware of geeks bearing gifts!</para> </footnote> sense: to set up a program that will be used to <quote role="figurative">open the gates</quote> to a system protected by passwords. However, the Trojan Horse could not do its work until Leslie executed the enclosed executable. This is important to remember: a text message by itself cannot affect the system to which it is delivered<footnote> <para> OK, OK, a huge text message can affect free disk space, but … </para> </footnote>. There has to be some executable portion — an actual executable program or script, malicious macros that are executed when an enclosure is opened by Microsoft <productname>Word</productname>, a dangerous Java application, or the like. A cautious user will disable any feature that allows automatic execution or installation of mail enclosures, and will be particularly cautious about opening mail enclosures using powerful programs like Microsoft <productname>Word</productname> or <productname>Excel</productname>, or a &unix; shell — programs that can perform arbitrary actions dictated by their input data, often without the user's knowledge. By contrast, opening a JPEG image enclosure specifically using a program that does nothing but display JPEG images is safe, demonstrating an advantage of relatively small applications with specific functionality over large do-everything packages like <productname>Word</productname>. In general, remembering that mail can be forged, execute <emphasis>extreme</emphasis> care when opening mail attachments; on Microsoft operating systems, having an anti-Virus program installed and up to date may prevent damage in case a Trojan Horse is opened by mistake. </para> <para> Another dangerous form of mail is <quote role="figurative">phishing</quote> schemes, in which mail is forged to look like it comes from a widely-used online business, asking the user to click on a link and connect to a site to verify their credit card or password information. Unfortunately, the link goes to a site whose general appearance mimics the legitimate business. Again, regard unsolicited email with suspicion, and unsolicited mail concerning passwords or other secret information doubly so. </para> <para> It is also not difficult for a reasonably skilled programmer to <quote role="figurative" >wire-tap</quote>' electronic mail (or any other unencrypted Internet communication). &smtp;, &pop;, or &imap; conversations are inherently insecure, and one should always assume that an eavesdropper may be intercepting the communication. Accordingly, you should <emphasis>never</emphasis> send confidential or critical information (such as passwords) through electronic mail without using some form of encryption. Similarly, &pop; and &imap; communications begin with a user password are normally transmitted in the clear (i.e., not encrypted in any way) and so is subject to similar wiretapping. If possible, one's &pop; or &imap; password should not be the same as one's other passwords (if someone gets the password, they will only have access to mail, not to other computers). </para> <para> Encryption technologies can address both privacy and security concerns. There are a number of encryption tools that can be used to secure the contents of mail; the most popular may be the <ulink url="http://www.pgp.com">&pgp;</ulink> (Pretty Good Privacy) encryption system and/or the closely related and compatible implementation, <ulink url="http://www.gnupg.org"> <acronym>GPG</acronym> </ulink> (GNU Privacy Guard). These systems use a public-key encryption system to allow cooperating users to encode mail securely, and also allows one to use a <firstterm>digital signature</firstterm> so that a recipient can certify that a message (and its enclosures) actually came from the individual that it claims to be from. Because both sender and receiver must agree to use encryption systems of this type, they are less widely used than one might hope. However, most modern mail clients now make it fairly easy to use &pgp; if the user wishes to do so. For further reading on this topic, including instructions for setting up encrypted mail, see <ulink url="blah">the document on &pgp; </ulink>. </para> <para> Many &pop;/&imap; and &smtp; servers utilize the widely-used Secure Socket Layer (&ssl;) system to encrypt their respective sessions as well. This will secure the user password for &pop; or &imap; against wire-tap penetration. An &ssl; server starts by sending the client a <firstterm>certificate</firstterm> by which the client can verify the server is really the machine it claims to be (typically through a third-party certificate authority like VeriSign), and a public encryption key that is used (through a process of private key generation and exchange beyond the scope of this paper) to securely encrypt protocols like &pop; and &imap;. Most recent mail client programs can be configured to use &ssl; to encrypt at least &pop; or &imap;; some can encrypt &smtp; as well. However, since this is not necessarily the only &smtp; session that will carry the message, the message contents may still be intercepted unencrypted at another point in its journey to its destination. </para> </section>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]