(A Javascript-enabled browser is required to email me.)

TBTF for 1995-10-18: Open Market's security pages; Spam and friends

Keith Dawson (dawson dot tbtf at gmail dot com)
Wed, 18 Oct 1995 23:10:40 -0400

On or before Oct. 5, Open Market put up a suite of pages about Web security
at <http://www.openmarket.com/knowledge/security-watch/index.html>. (Open
Market makes a secure server that competes with Netscape's.) They've provided
a script that senses what browser software you're using and returns informa-
tion on all known security problems reported against that browser -- see
<http://www.openmarket.com/knowledge/security-watch/stest.cgi>. There is
also a good summary of most of the security problems in the news recently,

While these pages represent a free service to the community in the best Net
tradition, they come off as just a bit self-serving; it turns out that no
Open Market products have any known security weaknesses. The company is far
too gentlemanly (and too Net-savvy) to point this out, but one does tend to
notice that all the security concerns profiled involve Open Market's rival,
Netscape. That Netscape has come under all this scrutiny is not a fact of
Open Market's devising, of course. It has to do with market share and with
the visibility engendered by Netscape's astounding IPO.

The following security story is not covered on Open Market's pages. Their
software would be every bit as vulnerable to this sort of attack as Net-

The two grad students who found the weakness in 40-bit Netscape encryption,
joined by one of their fellows and a professor, on Monday (10/9) published
an article calling to wide attention the dirty little secret of NFS -- the
Network File System in widespread use in client/server environments. NFS's
lack of end-to-end validation renders any on-the-wire encryption moot.

> We believe that the current focus on secure session-layer protocols and
> sufficient randomness have obscured more fundamental flaws in end-to-end
> security. In particular, secure end-to-end transactions require two parts:
> a secure protocol to communicate over untrusted channels, and trusted
> code at both endpoints. The latter problem has received less attention,
> but destroys security regardless of the quality of the protocols or of
> the random numbers.

The article is signed by Eric Brewer <brewer at cs dot berkeley dot edu> (he's the
professor), Paul Gauthier <gauthier at cs dot berkeley dot edu>, Ian Goldberg
<iang at cs dot berkeley dot edu>, and David Wagner <daw@cs dot berkeley.edu> (the latter
two are the 40-bit boys).

The New York Times picked up the story on Wendesday 10/11. You can read the
original at <http://http.cs.berkeley.edu/~gauthier/endpoint-security.html>;
this URL also points to the text of the NYT article.

What the Berkeley Four did was to "sniff" packets on a network and, using IP
spoofing, patch on the fly the binary code of an application in the process
of being downloaded to a client to execute. One of the tricks they played was
to patch the part of the Netscape client that generates random keys, substi-
tuting their own code to produce instead a known and constant key.

Some observations about this exercise. First, it's been known for years that
such a vulnerability is inherent in NFS, but nobody had bothered to write the
code to demonstrate it. Second, the techniques used go far beyond the abili-
ties of the average hacker. Third, the feat required complete and "promiscuous"
access to all the facilities of the LAN. In a real-world security situation,
such a LAN would be written off at the outset as irretrievably compromised.

So we need end-to-end security. A company called Atalla, owned by Tandem, has
had long experience in the design of bank ATMs. On Oct. 2 they introduced
Websafe, an end-to-end, hardware-based security processor that attaches as
a peripheral device to Web servers. (For details see the WEBster article at
<http://www.tgc.com/websec/69021.html>.) It may be that we will need a hard-
ware assist to achieve the sort of security now enjoyed by bank transactions;
but I haven't given up hope yet for a software solution.
Threads Email spam and antispam tactics
See also TBTF for
2000-07-20, 1999-07-19, 1998-11-17, 07-27, 03-30, 02-09, 01-12, 1997-11-24, 10-20, 09-29, 09-22, more...

Speaking of Spam --

Previous numbers of TBTF have explored the not-so-tasty
subject of Spam, the practice of splattering an unwanted and inappropriate
message across thousands of Usenet newsgroups or mailing-list recipients. Often
the message is a commercial one, but it need not be.

Bill Marrs has alerted TBTF to an anti-Spam page, the Blacklist of Inter-
net Advertisers <http://math-www.uni-paderborn.de/~axel/BL/blacklist.html>,
maintained by Axel Boldt. The Blacklist gives chapter and verse on commer-
cial Spam offenders. Here is Axel broadening the junk-food horizen beyond
dull old Spam:

> Although we don't have a dedicated Velveeta home page yet, there's at
> least a cheese page at <http://corsa.ucr.edu/~formy/cheese.html>. On
> the Internet, Velveeta means the excessive crossposting of an article
> to many unrelated newsgroups.
> Spam is much worse than Velveeta (try it!). Recently, more and more
> mixtures of the two appeared: many copies of an article, each of which
> crossposted to a large number of newsgroups. Some call this "jello".

Siliconia update --

The Siliconia page is up at <http://www.tbtf.com/siliconia.html>.
Already readers have expanded the list -- welcome to Silicon Gulch -- and
pushed the date of the first Siliconium sighting back to 1985. Join in,
don't miss this opportunity to write a piece of Net history. Anyone want
to contribute Siliconia artwork?


>>WEBster -- send mail without text to 4free@webster.tgc.com .

TBTF alerts you twice a week to bellwethers in computer and communications
technology, with special attention to commerce on the Internet. See the
archive at <http://www.tbtf.com/>. To subscribe send the
message "subscribe" to tbtf-request@world.std.com.
Keith Dawson dawson dot tbtf at gmail dot com dawson@atria.com
Layer of ash separates morning and evening milk.


Copyright © 1994-2022 by Keith Dawson. Commercial use prohibited. May be excerpted, mailed, posted, or linked for non-commercial purposes.