ch30.htm

来自「Maximum Security (First Edition) 网络安全 英文」· HTM 代码 · 共 1,283 行 · 第 1/5 页

<DL>
	<DD>Current versions of Netscape Navigator use random information to generate session
	encryption keys of either 40 or 128 bits in length. The random information is found
	through a variety of functions that look into a user's machine for information about
	how many processes are running, process ID numbers, the current time in microseconds,
	etc. The current vulnerability exists because the size of random input is less than
	the size of the subsequent keys. This means that instead of searching through all
	the 2^128 possible keys by brute force, a potential intruder only has to search through
	a significantly smaller key space by brute force. This is substantially easier problem
	to solve because it takes much less compute time and means 40-bit or 128-bit key
	strength is substantially reduced.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>&quot;Potential Vulnerability
	in Netscape Products&quot; can be found on the Web at <A HREF="http://www.netscape.com/newsref/std/random_seed_security.html"><TT>http://www.netscape.com/newsref/std/random_seed_security.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>As Netscape was quick to point out, there has never been a known instance of any
Net surfer's financial information being stolen in such a manner. Nor have there
been any recorded instances of such information being intercepted over the Internet.
At the day's end, the technique employed was complex and not one that would be commonly
known to criminals. However, the episode threw many products into a suspicious light,
and again, Internet security was reduced to a hope rather than a reality.</P>
<P>Information now suggests that peripheral components used in implementation of
SSL may even be flawed. Specifically, MD5 is now under suspicion. On May 2, 1996,
a member of the German Information Security Agency issued a report titled &quot;Cryptanalysis
of MD5 Compress.&quot; In it, the author demonstrates a weakness inherent in MD5.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>&quot;Cryptanalysis of
	MD5 Compress&quot; by Dr. Hans Dobbertin can by found at <A HREF="http://www.cs.ucsd.edu/users/bsy/dobbertin.ps"><TT>http://www.cs.ucsd.edu/users/bsy/dobbertin.ps</TT></A>.<BR>
	
<HR>
</P>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Some forces in encryption
	suggest that MD5 be phased out. To learn more about these matters, check out the
	Secure Sockets Layer Discussion List. In this mailing list, members discuss the various
	security characteristics of SSL. You can subscribe to that list by sending a mail
	message to <A HREF="mailto:[e-mail]"><TT>[e-mail]</TT></A>.
	The mail message should be empty, and the Subject line should include the word <TT>SUBSCRIBE</TT>.
	The material discussed in the Secure Sockets Layer Discussion List is quite technical.
	If you are new to the subject matter, it would be wise to obtain the FAQ (<A HREF="http://www.consensus.com/ security/ssl-talk-sec01.html"><TT>http://www.consensus.com/
	security/ssl-talk-sec01.html</TT></A><TT>)</TT>. 
<HR>


</BLOCKQUOTE>

<P>Today, a stronger version of SSL is selling like wildfire. To date, there have
been no successful attempts to crack these newer implementations; they have a much
stronger random-generation routine. Dozens of third-party products now support SSL,
including most of the browser clients commercially available (and a good number of
servers).


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>An interesting comparison
	of third-party products that support SSL is available at <A HREF="http://webcompare.iworld.com/compare/security.shtml"><TT>http://webcompare.iworld.com/compare/security.shtml</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P><B>S-HTTP</B> <I>S-HTTP</I> (Secure Hypertext Transfer Protocol) differs from
SSL in several ways. First, Netscape's SSL is a published implementation; therefore,
there is a wide range of information available about it. In contrast, S-HTTP is an
often-discussed but seldom-seen protocol.</P>
<P>The main body of information about S-HTTP is in the &quot;Internet Draft&quot;
authored by E. Rescorla and A. Schiffman of Enterprise Integration Technologies (Eit.com).
Immediately on examining that document, you can see that S-HTTP is implemented in
an entirely different manner from SSL. For a start, S-HTTP works at the application
level of TCP/IP communications, whereas SSL works at the data-transport level.</P>
<P>As you learned in Chapter 6, &quot;A Brief Primer on TC/IP,&quot; these levels
represent different phases of the TCP/IP stack implementation. Application-level
exchanges are those available to (and viewable by) the operator. Well-known application-level
protocols include FTP, Telnet, HTTP, and so on.</P>
<P>A company called Terisa Systems (<TT>www.terisa.com</TT>) licenses several development
toolkits that incorporate S-HTTP into applications. These toolkits come with pre-fabbed
libraries and a crypto engine from RSA.</P>
<P>S-HTTP's main feature (and one that is very attractive) is that it does not require
users to engage in a public key exchange. Remember how I wrote about Microsoft's
implementation of SSL, which required that you obtain a certificate? This means you
have to identify yourself to a third party. In contrast, according to Rescorla and
Schiffman:

<DL>
	<DD>S-HTTP does not require client-side public key certificates (or public keys),
	supporting symmetric session key operation modes. This is significant because it
	means that spontaneous private transactions can occur without requiring individual
	users to have an established public key.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>You can find &quot;The
	Secure HyperText Transfer Protocol&quot; by E. Rescorla and A. Schiffman on the Web
	at <A HREF="http://www.eit.com/creations/s-http/draft-ietf-wts-shttp-00.txt"><TT>http://www.eit.com/creations/s-http/draft-ietf-wts-shttp-00.txt</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>In my view, this seems more acceptable and less Orwellian. There should never
be an instance where an individual MUST identify himself or herself simply to make
a purchase or cruise a page, just as one should not have to identify oneself at a
bookstore or a supermarket in the &quot;real&quot; world. One has to question the
motivation of corporations such as Microsoft that insist on certificates and public
key schemes. Why are they so concerned that we identify ourselves? I would view any
such scheme with extreme suspicion. In fact, I would personally lobby against such
schemes before they become acceptable Internet standards. Many other efforts in electronic
commerce are aimed toward complete anonymity of the client and consumer. These efforts
seem to be working out nicely, without need for such rigid identification schemes.</P>
<P>Moreover, the S-HTTP may be a more realistic choice. Even if public key exchange
systems were desirable (as opposed to anonymous transactions), the number of Internet
users with a public key is small. New users in particular are more likely targets
for online commercial transactions, and the majority of these individuals do not
even know that public key systems exist. If a public key is required to complete
a transaction using a secure protocol, many millions of people will be unable to
trade. It seems highly unrealistic that vendors will suggest methods of educating
(or prodding) consumers into obtaining a public key.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>Although S-HTTP does not require
	public key exchange-style authentication, it supports such authentication. It also
	supports Kerberos authentication, which is an additional benefit. 
<HR>


</BLOCKQUOTE>

<P>S-HTTP also supports message authentication and integrity in much the same fashion
as SSL. As noted in &quot;The Secure HyperText Transfer Protocol&quot;:

<DL>
	<DD>Secure HTTP provides a means to verify message integrity and sender authenticity
	for a HTTP message via the computation of a Message Authentication Code (MAC), computed
	as a keyed hash over the document using a shared secret--which could potentially
	have been arranged in a number of ways, e.g.: manual arrangement or Kerberos. This
	technique requires neither the use of public key cryptography nor encryption.
</DL>

<P>To date, not enough public information about S-HTTP is available for me to formulate
a truly educated advisory. However, it seems clear that the designers integrated
some of the best elements of SSL while allowing for maximum privacy of client users.
Also, I am aware of no instance in which S-HTTP has been cracked, but this may be
because the cracking communities have not taken as lively an interest in S-HTTP as
they have Netscape. No one can say for certain.
<H4><FONT COLOR="#000077"><B>HTML in General</B></FONT></H4>
<P>The problems with Web security that stem from HTML are mainly those that involve
the traffic of data. In other words, the main concern is whether information can
be intercepted over the Internet. Because commerce on the Internet is becoming more
common, these issues will continue to be a matter of public concern.</P>
<P>As it currently stands, very few sites actually use secure HTML technology. When
was the last time you landed on a page that used this technology? (You can recognize
such pages because the little key in the left corner of Netscape Navigator is solid
as opposed to broken.) This, of course, depends partly on what sites you visit on
the WWW. If you spend your time exclusively at sites that engage in commerce, you
are likely to see more of this activity. However, even sampling 100 commerce sites,
the number of those using secure HTTP technology is small.
<H2><FONT COLOR="#000077"><B>Java and JavaScript</B></FONT></H2>
<P>Java and JavaScript are two entirely different things, but they are often confused
by nonprogrammers as being one and the same. Here's an explanation of each:

<UL>
	<LI>JavaScript is a scripting language created at Netscape Communications Corporation.
	It is designed for use inside the Netscape Navigator environment (and other supported
	browsers). It is not a compiled language, it does not use class libraries, and it
	is generally nested within HTML. In other words, you can generally see JavaScript
	source by examining the source code of an HTML document. The exception to this is
	when the JavaScript routine is contained within a file and the HTML points to that
	source. Standalone applications cannot be developed with JavaScript, but very complex
	programs can be constructed that will run within the Netscape Navigator environment
	(and other supported browsers).<BR>
	<BR>
	
	<LI>Java, developed by Sun Microsystems, is a real, full-fledged, object-oriented,
	platform-independent, interpreted language. Java code requires a Java interpreter
	to be present on the target machine and its code is not nested. Java can be used
	to generate completely standalone programs. Java is very similar in construct to
	C++.
</UL>

<P>JavaScript is far more easily learned by a non-programmer; it can be learned by
almost anyone. Moreover, because Netscape Navigator and supported browsers already
contain an interpreter, JavaScript functions can be seen by a much wider range of
users. Java, in contrast, is to some degree dependent on class files and therefore
has a greater overhead. Also, Java applications require a real Java runtime environment,
a feature that many Netizens do not currently possess (users of Lynx, for example).
Finally, Java applets take infinitely more memory to run than do JavaScript functions;
although, to be fair, badly written JavaScript functions can recursively soak up
memory each time the originating page is reloaded. This can sometimes lead to a crash
of the browser, even if the programmer had no malicious intent.</P>
<P>Of these two languages, Java is far more powerful. In fact, Java is just as powerful
as its distant cousin, C++. Whole applications have been written in Java. HotJava,
the famous browser from Sun Microsystems, is one example. Because Java is more powerful,
it is also more dangerous from a security standpoint.
<H3><FONT COLOR="#000077"><B>Java</B></FONT></H3>
<P>When Java was released, it ran through the Internet like a shockwave. Programmers
were enthralled by the prospect of a platform-independent language, and with good
reason. Developing cross-platform applications is a complex process that requires
a lot of expense. For example, after writing a program in C++ for the Microsoft Windows
environment, a programmer faces a formidable task in porting that application to
UNIX.</P>
<P>Special tools have been developed for this process, but the cost of such engines
is often staggering, especially for the small outfit. Many of these products cost
more than $5,000 for a single user license. Moreover, no matter what conversion vendors
may claim about their products, the porting process is never perfect. How can it
be? In anything more than a trivial application, the inherent differences between
X and Windows 95, for example, are substantial indeed. Quite frequently, further
human hacking must be done to make a smooth transition to the targeted platform.</P>
<P>With these factors in mind, Java was a wonderful step forward in the development
of cross- platform applications. Even more importantly, Java was designed (perhaps
not initially, but ultimately) with components specifically for development of platform-independent
applications for use on the Internet. From this, we can deduce the following: Java
was a revolutionary step in Internet-based development (particularly that type of
development that incorporates multimedia and living, breathing applications with
animation, sound, and graphics). It is unfortunate that Java had such serious security
flaws.</P>
<P>I'd like to explain the process of how Java became such a terrific security issue
on the Internet. This may help you understand the concept of how security holes in
one language can affect the entire Net community.</P>
<P>Certain types of languages and encryption routines are composed of libraries and
functions that can be incorporated into other applications. This is a common scenario,
well known to anyone who uses C or C++ as a programming language. These libraries
consist of files of plain text that contain code that defines particular procedures,
constant variables, and other elements that are necessary to perform the desired
operation (encryption, for example). To include these libraries and functions within
his or her program, the programmer inserts them into the program at compile time.
This is generally done with an <TT>#include</TT> statement, as in</P>
<PRE><FONT COLOR="#0066FF">#include &lt;stdio.h&gt;
</FONT></PRE>
<P>After these routines have been included into a program, the programmer may call