diff --git a/LDP/howto/docbook/HOWTO-INDEX/adminSect.sgml b/LDP/howto/docbook/HOWTO-INDEX/adminSect.sgml index df7727f0..f8d123d5 100644 --- a/LDP/howto/docbook/HOWTO-INDEX/adminSect.sgml +++ b/LDP/howto/docbook/HOWTO-INDEX/adminSect.sgml @@ -410,7 +410,7 @@ partition images to and from a TFTP server. Linux-Complete-Backup-and-Recovery-HOWTO, Linux Complete Backup and Recovery HOWTO -Updated: September 2002. +Updated: February 2003. A step-by-step tutorial on how to back up a Linux computer so as to be able to make a bare metal recovery, and how to make that bare metal recovery. Includes some related scripts. @@ -472,7 +472,7 @@ Discusses methods to recover from Linux system failures. Linux-Complete-Backup-and-Recovery-HOWTO, Linux Complete Backup and Recovery HOWTO -Updated: September 2002. +Updated: February 2003. A step-by-step tutorial on how to back up a Linux computer so as to be able to make a bare metal recovery, and how to make that bare metal recovery. Includes some related scripts. diff --git a/LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml b/LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml index 0bf21e13..a13dcb7f 100644 --- a/LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml +++ b/LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml @@ -1547,7 +1547,7 @@ Describes Linmodem (winmodem hardware) support under Linux. Linux-Complete-Backup-and-Recovery-HOWTO, Linux Complete Backup and Recovery HOWTO -Updated: September 2002. +Updated: February 2003. A step-by-step tutorial on how to back up a Linux computer so as to be able to make a bare metal recovery, and how to make that bare metal recovery. Includes some related scripts. @@ -2524,7 +2524,7 @@ SCSI-Generic-HOWTO for more current information. Secure-Programs-HOWTO, Secure Programming for Linux and Unix HOWTO -Updated: December 2002. +Updated: February 2003. Provides a set of design and implementation guidelines for writing secure programs for Linux and Unix systems. @@ -2876,6 +2876,18 @@ operation and administration of Adaptive Server Anywhere databases. + + + +Tamil-Linux-HOWTO, +Tamil Linux HOWTO + +Updated: February 2003. +Helps you to set up a working Tamil Linux environment. It describes +setting up fonts, keyboard drivers, editing and printing +Tamil/bilingual documents, and working with the X Window system. + + diff --git a/LDP/howto/docbook/HOWTO-INDEX/miniChap.sgml b/LDP/howto/docbook/HOWTO-INDEX/miniChap.sgml index 6a40bf57..d01cf938 100644 --- a/LDP/howto/docbook/HOWTO-INDEX/miniChap.sgml +++ b/LDP/howto/docbook/HOWTO-INDEX/miniChap.sgml @@ -1475,6 +1475,18 @@ Directions for squeezing your Linux installation into the least possible space. Particularly aimed at notebook users. + + + +Secure-CVS-Pserver, +Secure CVS Pserver Mini-HOWTO + + +Updated: February 2003. +Will help you set up a more secure CVS Pserver for +anonymous CVS access. + + diff --git a/LDP/howto/docbook/HOWTO-INDEX/otherLangSect.sgml b/LDP/howto/docbook/HOWTO-INDEX/otherLangSect.sgml index 0365ccea..591a6735 100644 --- a/LDP/howto/docbook/HOWTO-INDEX/otherLangSect.sgml +++ b/LDP/howto/docbook/HOWTO-INDEX/otherLangSect.sgml @@ -252,6 +252,18 @@ software with Spanish support or how to get in touch with the Linux community in Spain (written in Spanish). + + + +Tamil-Linux-HOWTO, +Tamil Linux HOWTO + +Updated: February 2003. +Helps you to set up a working Tamil Linux environment. It describes +setting up fonts, keyboard drivers, editing and printing +Tamil/bilingual documents, and working with the X Window system. + + diff --git a/LDP/howto/docbook/HOWTO-INDEX/programmSect.sgml b/LDP/howto/docbook/HOWTO-INDEX/programmSect.sgml index 56ffd3a5..13e61081 100644 --- a/LDP/howto/docbook/HOWTO-INDEX/programmSect.sgml +++ b/LDP/howto/docbook/HOWTO-INDEX/programmSect.sgml @@ -489,7 +489,7 @@ operating systems with XML-RPC support. Secure-Programs-HOWTO, Secure Programming for Linux and Unix HOWTO -Updated: December 2002. +Updated: February 2003. Provides a set of design and implementation guidelines for writing secure programs for Linux and Unix systems. @@ -622,6 +622,18 @@ Covers basic installation and usage of RCS, the GNU Revision Control System, under Linux. + + + +Secure-CVS-Pserver, +Secure CVS Pserver Mini-HOWTO + + +Updated: February 2003. +Will help you set up a more secure CVS Pserver for +anonymous CVS access. + + diff --git a/LDP/howto/docbook/Secure-Programs-HOWTO/ChangeLog b/LDP/howto/docbook/Secure-Programs-HOWTO/ChangeLog index abcf20a3..93c41fbb 100644 --- a/LDP/howto/docbook/Secure-Programs-HOWTO/ChangeLog +++ b/LDP/howto/docbook/Secure-Programs-HOWTO/ChangeLog @@ -1,3 +1,43 @@ +2002-02-02 David A. Wheeler + * Noted Shamir and Tromir's paper on Factoring Large Numbers with + the TWIRL device (a draft paper at this time) - the paper basically + suggests that 1024-bit RSA isn't secure either. + +2002-01-23 David A. Wheeler + * Clarified that HttpOnly on cookies is a useful secondary defense, + but don't count on it as primary. I wrote it that way before, + but recent papers on "breaks" because some people thought + HttpOnly was sufficient as a primary defense made me decide + to state this even more clearly. + +2002-01-16 David A. Wheeler + * Expanded the discussion on crypto protocols, + in part based on some suggestions from + Pawel Krawczyk (kravietz, at echelon ,dot pl). + +2002-01-16 David A. Wheeler + * Referenced Quixote's interesting approach to XSS. + * Mentioned RMAC. + * Expanded the Tcl section significantly. + Thanks to Wojciech Kocjan (wojciech, at kocjan dot org), + who asked me to update the Tcl section and gave me some + wrong/right examples of Tcl use that helped clarify the discussion, + as well as noting that Tcl 8.0 implements other data types + internally and is really more robust than older versions. + +2002-01-15 David A. Wheeler + * Clarified that you should not use "nobody" for your own + programs (unless you're writing a webserver) - instead, use the + same IDEA of creating pseudousers and groups to isolate + programs from each other. Thanks to Martijn Vernooij + tinus, at, win (dot) tue (dot) nl for asking me about this. + +2002-12-31 David A. Wheeler + * Added note about Ada's Inspection_Point. The idea of mentioning + Inspection_Point was suggested by Florian Weimer + (Weimer, at, CERT dot Uni-Stuttgart, dot DE) - thanks! - + but the text as usual is my own. + 2002-12-30 David A. Wheeler * Version 3.005. Adds major new text on handling tmp files where there are tmp cleaners running (true on most real systems), diff --git a/LDP/howto/docbook/Secure-Programs-HOWTO/Secure-Programs-HOWTO.sgml b/LDP/howto/docbook/Secure-Programs-HOWTO/Secure-Programs-HOWTO.sgml index 44cdc855..c0d934f3 100644 --- a/LDP/howto/docbook/Secure-Programs-HOWTO/Secure-Programs-HOWTO.sgml +++ b/LDP/howto/docbook/Secure-Programs-HOWTO/Secure-Programs-HOWTO.sgml @@ -1,7 +1,7 @@ 1999 2000 2001 2002 + 2003 David A. Wheeler -This book is Copyright (C) 1999-2002 David A. Wheeler. +This book is Copyright (C) 1999-2003 David A. Wheeler. Permission is granted to copy, distribute and/or modify this book under the terms of the GNU Free Documentation License (GFDL), Version 1.1 or any later version published by the Free Software Foundation; @@ -168,8 +169,11 @@ guidelines for writing secure programs for Linux and Unix systems. Such programs include application programs used as viewers of remote data, web applications (including CGI scripts), network servers, and setuid/setgid programs. -Specific guidelines for C, C++, Java, Perl, PHP, Python, TCL, +Specific guidelines for C, C++, Java, Perl, PHP, Python, Tcl, and Ada95 are included. +For a current version of the book, see + +http://www.dwheeler.com/secure-programs @@ -200,7 +204,7 @@ and Ada95 are included. Perl PHP Python - TCL + Tcl Ada Ada95 @@ -237,7 +241,7 @@ These guidelines were developed as a survey of (along with additional observations by the author), reorganized into a set of larger principles. This book includes specific guidance for a number of languages, -including C, C++, Java, Perl, PHP, Python, TCL, and Ada95. +including C, C++, Java, Perl, PHP, Python, Tcl, and Ada95. @@ -1044,8 +1048,12 @@ http://www.dwheeler.com/secure-programs. View of Various Experts -Here are a few quotes from people who have examined the topic. -Bruce Schneier argues that smart engineers should ``demand +First, let's exampine what security experts have to say. + + + +Bruce Schneier is a well-known expert on computer security and cryptography. +He argues that smart engineers should ``demand open source code for anything related to security'' [Schneier 1999], and he also discusses some of the preconditions which must be met to make open source software secure. @@ -1076,7 +1084,12 @@ to spot and fix, ``Not only because more people can look at it, but, more importantly, because the model forces people to write more clear code, and to adhere to standards. This in turn facilitates security review'' [Rijmen 2000]. -Elias Levy (Aleph1) discusses some of the problems in making open source + + + +Elias Levy (Aleph1) is the former moderator of one of the most +popular security discussion groups - Bugtraq. +He discusses some of the problems in making open source software secure in his article "Is Open Source Really More Secure than Closed?". @@ -1090,6 +1103,49 @@ than its closed source counterpart. But make no mistake, simply being open source is no guarantee of security. + + + +Whitfield Diffie is the +co-inventor of public-key cryptography (the basis of all Internet security) +and chief security officer and senior staff engineer at Sun Microsystems. +In his 2003 article + +Risky business: Keeping security a secret, +he argues that proprietary vendor's claims that their software +is more secure because it's secret is nonsense. +He identifies and then counters two main claims made by proprietary vendors: +(1) that release of code benefits attackers more than anyone else because +a lot of hostile eyes can also look at open-source code, and +that (2) a few expert eyes are better than several random ones. +He first notes that while giving programmers access to a piece of software +doesn't guarantee they will study it carefully, +there is a group of programmers who can be expected to care deeply: +Those who either use the software personally or work for an +enterprise that depends on it. +"In fact, auditing the programs on which an enterprise depends for +its own security is a natural function of the enterprise's own +information-security organization." +He then counters the second argument, noting that +"As for the notion that open source's usefulness to opponents +outweighs the advantages to users, that argument flies in +the face of one of the most important principles in security: +A secret that cannot be readily changed should be regarded as a vulnerability." +He closes noting that +
+ +"It's simply unrealistic to depend on secrecy for security in +computer software. +You may be able to keep the exact workings of the program out of general +circulation, but can you prevent the code from being +reverse-engineered by serious opponents? Probably not." + +
+ + + + + John Viega's article "The Myth of Open Source Security" also discusses issues, and summarizes things this way: @@ -1103,8 +1159,12 @@ for and fix security holes -- can also lull people into a false sense of security. -Michael H. Warfield's "Musings on open source security" is much -more positive about the impact of open source software on security. + + + +Michael H. Warfield's "Musings on open source security" is +very positive about the impact of open source software on security. +In contrast, Fred Schneider doesn't believe that open source helps security, saying ``there is no reason to believe that the many eyes inspecting (open) source code would be successful in identifying bugs that allow @@ -1146,6 +1206,7 @@ metrics that can reflect security delivered to the customer.'' + Scott A. Hissam and Daniel Plakosh's @@ -1167,6 +1228,9 @@ and attackers correctly surmised that a similar problem might be still be in Windows (and it was). Unless OSS/FS programs are forbidden, this kind of learning is difficult to prevent. +Therefore, the existance of an OSS/FS program can reveal the vulnerabilities +of both the OSS/FS and proprietary program performing the same function - +but at in this example, the OSS/FS program was fixed first. @@ -3563,7 +3627,7 @@ harder to understand; hopefully the text in this section will help you Note that, in some circumstances, software cannot be used unless it has undergone a CC evaluation by an accredited laboratory. This includes certain kinds of uses in the U.S. Department of Defense -(as specified by NSTISP Number 11, which requires that before some +(as specified by NSTISSP Number 11, which requires that before some products can be used they must be evaluated or enter evaluation), and in the future such a requirement may also include some kinds of uses for software in the U.S. federal government. @@ -7568,9 +7632,10 @@ his or her protection goals. -A good overview of various desing principles for security is available in - -Peter Neumann's CHATS Principles +A good overview of various design principles for security is available in +Peter Neumann's + +Principled Assuredly Trustworthy Composable Architectures. @@ -10131,6 +10216,14 @@ Mozilla/Netscape to implement this soon too. You should set HttpOnly on for any cookie you send, unless you have scripts that need the cookie, to counter certain kinds of cross-site scripting (XSS) attacks. +However, the HttpOnly flag can be circumvented in a variety of ways, +so using as your primary defense is inappropriate. +Instead, it's a helpful secondary defense that may help save you in +case your application is written incorrectly. + @@ -10287,14 +10380,14 @@ to remove just those characters: -Encoding +Encoding (Quoting) An alternative to removing the special characters is to encode them so that they don't have any special meaning. This has several advantages over filtering the characters, in particular, it prevents data loss. If the data is "mangled" by the process from the user's point of view, -at least with encoding it's possible to reconstruct the +at least when the data is encoded it's possible to reconstruct the data that was originally sent. @@ -10312,10 +10405,40 @@ As noted above, although in theory '>' doesn't need to be quoted, because some browsers act on it (and fill in a '<') it needs to be quoted. There's a minor complexity with the double-quote character, because '&quot;' only needs to be -used inside attributes, and some old browsers don't properly render it. +used inside attributes, and some extremely old browsers don't +properly render it. If you can handle the additional complexity, you can try to encode '"' only when you need to, but it's easier to simply encode it and ask users to upgrade their browsers. +Few users will use such ancient browsers, and the double-quote character +encoding has been a standard for a long time. + + + +Scripting languages may consider implementing specialized auto-quoting types, +the interesting approach developed in the web application framework +Quixote. +Quixote includes a "template" feature which allows easy mixing of HTML text +and Python code; text generated by a template is passed back to the web browser +as an HTML document. +As of version 0.6, Quixote has two kinds of text (instead of a single +kind as most such languages). +Anything which appears in a literal, quoted string is of type "htmltext," +and it is assumed to be exactly as the programmer wanted it to be +(this is reasoble, since the programmer wrote it). +Anything which takes the form of an ordinary Python string, however, +is automatically quoted as the template is executed. +As a result, text from a database or other external source is +automatically quoted, and cannot be used for a cross-site scripting attack. +Thus, Quixote implements a safe default - +programmers no longer need to worry about quoting every bit of text +that passes through the application (bugs involving too much quoting +are less likely to be a security problem, and will be obvious in testing). +Quixote uses an open source software license, but because of its +venue identification it is probably GPL-incompatible, and is used by +organizations such as the +Linux Weekly News. + @@ -10389,6 +10512,7 @@ the codes to UTF-8, and then encode it. See for more about validating URIs. + @@ -12185,12 +12309,17 @@ use correctly). In Ada95, the Unbounded_String type is often more flexible than the String type because it is automatically resized as necessary. -However, don't store especially sensitive values such as passwords +However, don't store especially sensitive secret values such as passwords or secret keys in an Unbounded_String, since core dumps and page areas might still hold them later. Instead, use the String type for this data, lock it into memory while it's used, and overwrite the data as soon as possible with some constant value such as (others => ' '). +Use the Ada pragma Inspection_Point on the object holding the secret +after erasing the memory. +That way, you can be certain that +the object containing the secret will really be erased +(and that the the overwriting won't be optimized away). @@ -12209,10 +12338,10 @@ various supports for full formal proof of the code if desired. See the SPARK website for more information. To my knowledge, there are no OSS/FS SPARK tools. -SPARK doesn't permit use of the Unbounded_String type, but still, -if you're storing passwords and private keys you should lock them into memory -(if appropriate - SPARK is often used in environments where -paging does not occur) and overwrite them as soon as possible. +If you're storing passwords and private keys you should still +lock them into memory if appropriate +and overwrite them as soon as possible. +Note that SPARK is often used in environments where paging does not occur. @@ -12540,54 +12669,288 @@ Code obfuscation doesn't really hide the code from serious attackers. -TCL +Tcl Tcl stands for ``tool command language'' and is pronounced ``tickle.'' -TCL is divided into two parts: a language and a library. -The language is a simple text language, intended for issuing commands +Tcl is divided into two parts: a language and a library. +The language is a simple language, originally intended for issuing commands to interactive programs and including basic programming capabilities. The library can be embedded in application programs. +You can find more information about Tcl at sites such as the +Tcl.tk and the +Tcl WWW Info +web page and the comp.lang.tcl FAQ launch page at +http://www.tclfaq.wservice.com/tcl-faq. +My thanks go to Wojciech Kocjan for providing some of this detailed +information on using Tcl in secure applications. -You can find more information about TCL at sites such as the -TCL WWW Info -web page. -Probably of most interest are Safe-TCL (which creates a sandbox in TCL) -and Safe-TK (which implements a sandboxed portable GUI for Safe-TCL), as -well as the WebWiseTclTk Toolkit permits TCL packages to be automatically +For some security applications, especially interesting components of Tcl +are Safe-Tcl (which creates a sandbox in Tcl) +and Safe-TK (which implements a sandboxed portable GUI for Safe Tcl), as +well as the WebWiseTclTk Toolkit which permits Tcl packages to be automatically located and loaded from anywhere on the World Wide Web. You can find more about the latter from http://www.cbl.ncsu.edu/software/WebWiseTclTk. It's not clear to me how much code review this has received. -More useful information is available from the comp.lang.tcl FAQ launch -page at -http://www.tclfaq.wservice.com/tcl-faq. -However, it's worth noting that TCL's desire to be a small, ``simple'' -language results in a language that can be rather limiting; -see + + + +Tcl's original design goal to be a small, simple +language resulted in a language that was originally somewhat limiting +and slow. +For an example of the limiting weaknesses in the original language, see -Richard Stallman's ``Why You Should Not Use TCL''. -For example, TCL's notion that there is essentially -only one data type (string) can -make many programs harder to write (as well as making them slow). -Also, when I've written TCL programs -I've found that it's easy to accidentally create TCL programs where -malicious input strings can cause untoward and unexpected behavior. -For example, an attackers may be able to cause your TCL program -to do unexpected things by sending characters with special meaning to TCL -such as embedded spaces, double-quote, curly braces, -dollar signs, or brackets (or create input +Richard Stallman's ``Why You Should Not Use Tcl''. +For example, Tcl was originally designed to really support only +one data type (string). +Thankfully, these issues have been addressed over time. +In particular, version 8.0 added support for more data types +(integers are stored internally as integers, lists as lists and so on). +This improves its capabilities, and in particular improves its speed. + + + +As with essentially all scripting languages, +Tcl has an "eval" command that parses and executes arbitrary Tcl commands. +And like all such scripting languages, this eval command needs to be +used especially carefully, or an attacker could insert +characters in the input to cause malicious things to occur. +For example, an attackers may be able insert characters +with special meaning to Tcl +such as embedded whitespace (including space and newline), +double-quote, curly braces, square brackets, +dollar signs, backslash, semicolon, or pound sign (or create input to cause these characters to be created during processing). -Thus, I don't recommend TCL for writing programs which must +This also applies to any function that passes data to eval as well +(depending on how eval is called). + + + +Here is a small example that may make this concept clearer; +first, let's define a small function and then interactively invoke it +directly - note that these uses are fine: + + + + +However, continuing the example, let's see how "eval" +can be incorrectly and correctly called. +If you call eval in an incorrect (dangerous) way, it +allows attackers to misuse it. +However, by using commands like list or lrange to correctly +group the input, you can avoid this problem: + + + + +Using lrange is useful when concatenating arguments to a called +function, e.g., with more complex libraries using callbacks. +In Tcl, eval is often used to create a one-argument version of a function +that takes a variable number of arguments, and you need to be careful +when using it this way. +Here's another example (presuming that you've defined a "printf" function): + + + + + + +Fundamentally, when passing a command that will be eventually +evaluated, you must pass Tcl commands as a properly built list, +and not as a (possibly concatentated) string. +For example, the "after" command runs a Tcl command after a given +number of milliseconds; if the data in $param1 can be controlled by +an attacker, this Tcl code is dangerously wrong: + + + +This is wrong, because if an attacker can control the value of $param1, +the attacker can control the program. +For example, if the attacker can cause $param1 to have +'[exit]', then the program will exit. +Also, if $param1 would be '; exit', it would also exit. + + + +Thus, the proper alternative would be: + + + +Even better would be something like the following: + + + + + + +Here's another example showing what you shouldn't do, +pretending that $params is data controlled by possibly malicious user: + + + +will result in: + + + +But, when if the untrusted user sends data with an embedded newline, +like this: + + + +The result will be this (notice that the attacker's code was executed!): + + + +Wojciech Kocjan suggests that the +simplest solution in this case is to convert this to a list using +lrange, doing this: + + + +The result would be: + + + +Note that this solution presumes that the potentially malicious +text is concatenated to the end of the text; as with all languages, +make sure the attacker cannot control the format text. + + + +As a matter of style always use curly braces +when using if, while, for, expr, and any other command which +parses an argument using expr/eval/subst. +Doing this will avoid +a common error when using Tcl called unintended double substitution +(aka double substitution). +This is best explained by example; the following code is incorrect: + + + +The code is incorrect because the "![eof $file]" text will be evaluated +by the Tcl parser when the while command is executed the first time, +and not re-evaluated in every iteration as it should be. +Instead, do this: + + + +Note that both the condition, and the action to be performed, +are surrounded by curly braces. +Although there are cases where the braces are redundant, they never hurt, +and when you fail to include the curly braces where they're needed +(say, when making a minor change) subtle and hard-to-find +errors often result. + + + +More information on good Tcl style can be found in documents such as + +Ray Johnson's Tcl Style Guide. + + + +In the past, I have stated that +I don't recommend Tcl for writing programs which must mediate a security boundary. -If you do choose to do so, be especially careful to ensure that user -input cannot ``fool'' the program. -On the other hand, I know of no strong reason (other than -insufficient review) that TCL programs can't be used to implement mobile code. -There are certainly TCL advocates who will advocate more use than I do, -and TCL is one of the few languages with -a ready-made sandbox implementation. +Tcl seems to have improved since that time, so while I cannot guarantee +Tcl will work for your needs, I can't guarantee that any other language +will work for you either. +Again, my thanks to Wojciech Kocjan who provided some +of these suggestions on how to +write Tcl code for secure applications. @@ -13599,6 +13962,9 @@ immutable (they will not be overwritten until garbage-collected and then reused, possibly a far time in the future). Instead, in Java use char[] to store a password, so it can be immediately overwritten. +In Ada, use type String (an array of characters), +and not type Unbounded_String, to make sure +that you have control over the contents. @@ -13610,6 +13976,10 @@ to stores that are no longer used - this is often referred to as "dead store removal." Unfortunately, if the write is really to overwrite the value of a secret, this means that code that appears to be correct will be silently discareded. +Ada provides the pragma Inspection_Point; place this after the +code erasing the memory, and that way you can be certain that +the object containing the secret will really be erased +(and that the the overwriting won't be optimized away). @@ -13622,7 +13992,7 @@ the C/C++ compilers gcc version 3 or higher, SGI MIPSpro, and the Microsoft compilers eliminated simple inlined calls to memset intended to overwrite secrets. This is allowed by the C and C++ standards. -Other compilers (such as gcc less than version 3) preserved the inlined +Other C/C++ compilers (such as gcc less than version 3) preserved the inlined call to memset at all optimization levels, showing that the issue is compiler-specific. Simply declaring that the destination data is volatile doesn't @@ -13716,8 +14086,14 @@ A survey of legal issues is available at the ``Crypto Law Survey'' site, Often, your software should provide a way to reject ``too small'' keys, and let the user set what ``too small'' is. For RSA keys, 512 bits is too small for use. -Some believe that 1024 bits for RSA keys are not enough either, based -on recent work by Bernstein; you may want to +There is increasing evidence that +1024 bits for RSA keys is not enough either; +Bernstein has suggested techniques that simplify brute-forcing RSA, and +other work based on it +(such as Shamir and Tromer's "Factoring Large Numbers with the TWIRL device") +now suggests that 1024 bit keys can be broken in a year +by a $10 Million device. +You may want to make 2048 bits the minimum for RSA if you really want a secure system, and you should certainly do so if you plan to use those keys after 2015. For more about RSA specifically, see @@ -13732,30 +14108,136 @@ cryptographic algorithm issues, see Cryptographic Protocols -For protocols, try to use standard-conforming protocols -such as SSL (soon to be TLS), SSH, IPSec, GnuPG/PGP, and Kerberos. -Many of these overlap somewhat in functionality, but each has -a ``specialty'' niche. -SSL (soon to be TLS) is the primary method for protecting http (web) -transactions. -PGP-compatible protocols (implemented in PGP and GnuPG) are a primary -method for securing email end-to-end. +When you need a security protocol, try to use standard-conforming protocols +such as IPSec, SSL (soon to be TLS), SSH, S/MIME, OpenPGP/GnuPG/PGP, +and Kerberos. +Each has advantages and disadvantages; +many of them overlap somewhat in functionality, but each tends to be +used in different areas: + + + + +Internet Protocol Security (IPSec). +IPSec provides encryption and/or authentication at the IP packet level. +However, IPSec is often used in a way that +only guarantees authenticity of two +communicating hosts, not of the users. +As a practical matter, IPSec usually requires low-level support +from the operating system (which not all implement) and +an additional keyring server that must be configured. +Since IPSec can be used as a "tunnel" to secure packets belonging to +multiple users and multiple hosts, it is especially useful for +building a Virtual Private Network (VPN) and connecting a remote machine. +As of this time, it is much less often used to secure communication +from individual clients to servers. +The new version of the Internet Protocol, IPv6, comes with +IPSec ``built in,'' but IPSec also works with the more common IPv4 protocol. +Note that if you use IPSec, don't use the encryption mode without the +authentication, because the authentication also acts as +integrity protection. + + + + + +Secure Socket Layer (SSL) / TLS. +SSL/TLS works over TCP and tunnels other protocols using TCP, adding +encryption, authentication of the server, and optional authentication +of the client (but authenticating clients using SSL/TLS requires +that clients have configured X.509 client certificates, something +rarely done). +SSL version 3 is widely used; TLS is a later adjustment to SSL that +strengthens its security and improves its flexibility. +Currently there is a slow transition going on from SSLv3 to TLS, aided +because implementations can easily try to use TLS and then back off to SSLv3 +without user intervention. +Unfortunately, a few bad SSLv3 implementations cause problems with the +backoff, so you may need a preferences setting to allow users to skip +using TLS if necessary. +Don't use SSL version 2, it has some serious security weaknesses. + + +SSL/TLS is the primary method for protecting http (web) transactions. +Any time you use an "https://" URL, you're using SSL/TLS. +Other protocols that often use SSL/TLS include POP3 and IMAP. +SSL/TLS usually use a separate TCP/IP port +number from the unsecured port, which the IETF is a little unhappy about +(because it consumes twice as many ports; there are solutions to this). +SSL is relatively easy to use in programs, because +most library implementations allow programmers to use operations +similar to the operations on standard sockets like +SSL_connect(), SSL_write(), SSL_read(), etc. +A widely used OSS/FS implementation of SSL (as well as other capabilities) +is OpenSSL, available at +http://www.openssl.org. + + + + + +OpenPGP and S/MIME. +There are two competing, essentially incompatible standards for +securing email: OpenPGP and S/MIME. +OpenPHP is based on the PGP application; an OSS/FS implementation is +GNU Privacy Guard from +http://www.gnupg.org. +Currently, their certificates are often not interchangeable; +work is ongoing to repair this. + + + + + +SSH. +SSH is the primary method of securing ``remote terminals'' over an +internet, and it also includes methods for +tunelling X Windows sessions. +However, it's been extended to support single sign-on and +general secure tunelling for TCP streams, so it's often +used for securing other data streams too (such as CVS accesses). +The most popular implementation of SSH is OpenSSH +http://www.openssh.com, +which is OSS/FS. +Typical uses of SSH allows the client to authenticate that the +server is truly the server, and +then the user enters a password to authenticate the user +(the password is encrypted and sent to the other system for verification). +Current versions of SSH can store private keys, allowing users to not +enter the password each time. +To prevent man-in-the-middle attacks, SSH records keying information +about servers it talks to; that means that typical use of +SSH is vulnerable to a man-in-the-middle attack during the +very first connection, but it can detect problems afterwards. +In contrast, SSL generally uses a certificate authority, which eliminates +the first connection problem but requires special setup (and payment!) to +the certificate authority. + + + + + + +Kerberos. +Kerberos is a protocol for single sign-on and authenticating users +against a central authentication and key distribution server. Kerberos +works by giving authenticated users "tickets", granting them access to +various services on the network. +When clients then contact servers, the servers can verify the tickets. Kerberos is a primary method for securing and supporting authentication on a LAN, and for establishing shared secrets (thus, it needs to be used with other algorithms for the actual protection of communication). -SSH is the primary method of securing ``remote terminals'' over an -internet, e.g., telnet-like and X windows connections, though it's often -used for securing other data streams too (such as CVS accesses). -Note that there are two major versions of the SSH protocol, and there -are several choices for key types and so on; see its documentation -for more information. -OpenSSH is an open source implementation of SSH. -IPSec is the primary method for securing lower-level packets and -``all'' packets, so it's particularly useful for securing -virtual private networks and remote machines. -The new version of the Internet Protocol, IPv6, comes with -IPSec ``built in,'' but IPSec also works with the more common IPv4 protocol. +Note that to use Kerberos, both the client and server have to include +code to use it, and since not everyone has a Kerberos setup, this has +to be optional - complicating the use of Kerberos in some programs. +However, Kerberos is widely used. + + + + + + Many of these protocols allow you to select a number of different @@ -14026,6 +14508,44 @@ for most environments isn't necessary. + +Randomized Message Authentication Mode (RMAC) + + + +NIST has developed and proposed +a new mode for using cryptographic algorithms called + +Randomized Message Authentication Code (RMAC). +RMAC is intended for use as a message authentication code technique. + + + +Although there's a formal proof showing that RMAC is secure, the +proof depends on the highly questionable assumption that +the underlying cryptographic algorithm +meets the "ideal cipher model" - in particular, that the algorithm is +secure against a variety of specialized attacks, including related-key attacks. +Unfortunately, related-key attacks are poorly studied for many algorithms; +this is not the kind of property or attack that most people worry about +when analyzing with cryptographic algorithms. +It's known triple-DES doesn't have this properly, and it's unclear if +other widely-accepted algorithms like AES have this property +(it appears that AES is at least weaker against related key attacks than +usual attacks). + + + +The best advice right now is "don't use RMAC". +There are other ways to do message authentication, such as HMAC +combined with a cryptographic hash algorithm (e.g., HMAC-SHA1). +HMAC isn't the same thing (e.g., technically it doesn't include a +nonce, so you should rekey sooner), but the theoretical weaknesses +of HMAC are merely theoretical, while the problems in RMAC seem far +more important in the real world. + + + Other Cryptographic Issues @@ -14271,9 +14791,11 @@ This tool isn't really specific to security. SPIKE is a "fuzzer creation kit", i.e., it's a toolkit designed to create "random" tests to find security problems. +The SPIKE toolkit is particularly designed for protocol analysis by +simulating network protocol clients, and SPIKE proXy is a tool built on +SPIKE to test web applications. SPIKE includes a few pre-canned tests. -As of version 2.7 its documentation is weak (the author knows this -is a problem and plans to fix it). +SPIKE is licensed under the GPL. @@ -14594,6 +15116,20 @@ getting constantly subverted for years at a time. + +Follow best practices and common conventions when leading a +software development project. +If you are leading an open source software / free software project, +some useful guidelines can be found in + +Free Software Project Management HOWTO and + +Software Release Practice HOWTO; +you should also read + +The Cathedral and the Bazaar. + + Every once in a while, review security guidelines like this one. At least re-read the conclusions in ,