December 2003 - cypherpunks-legacy

WHERE did this come from?
by rivaud＠rain.org 17 Dec '03

17 Dec '03

Attatched to this is, (I hope), the header text from a unsolicited e-mail message I received. The return address does not work. WHY? How can I inform the sender that I hope to never receive there material again? I tried "reply-all" through Eudora, but my reply got bounced back to me as undeliverable. I have removed the content of the original message. I don't know why it was sent to me, but it contained material that I found offensive. Any help, or words of wisdom and enlightenment would be appreciated. Information would be nice too. Thanks. -------------header should be below here-------------- i hope...--------

6 6

WWW Proxy Server Vulnerabilities
by brianm＠cs.bu.edu 17 Dec '03

17 Dec '03

Regarding WWW SSL middle-man attacks, John L. Bass writes: : Ok, several people have asked: : : client -> filter Client sends packet with K(c) : filter -> Server filter forwards packet with K(f) : filter <- Server Server sends encrypts with K(f) : client <- filter filter re-encrypts with K(c) : : hacking a DMS server is one way, spoofing a DNS reply to named is easier, : simply packaging the filter into a router/bridge close to the server : is more effective ... even if hacking the incoming phoneline/T1 line : to the server and inserting a very transparent bridge AKA a phone tap. : Consider the following attack: Many organizations, especially ones with low bandwidth localnet-to-internet connections and those with firewalls, have implemented `proxy-servers' to retrieve documents from the outside world and cache them for fast future localnet access. ALL WEB TRAFFIC FROM THE LOCALNET TO THE INTERNET GOES THROUGH THESE PROXY SERVERS, transparently to the client and web servers after the client has been configured to do so. If one of these servers were to be compromised, an attacker could easily implement the the middle-man scheme described above. Note that proxy servers are fairly common (especially since firewalls require them), so the apparatus already exists for the middle-man attack outside of modifying DNS servers and routers. The irony of the situation is that it is the most secure organizations who have implemented firewalls that are the most vulnerable to the middle-man attack. Brian Mancuso Boston University Computer Science Dept. PGP DF FA C0 EF 51 B0 23 54 Tel: 617.352.6552 Net: brianm(a)cs.bu.edu KFP 5C 8D E0 50 C6 39 C6 0F

2 1

MITM attacks, the day after ...
by jbass＠dmsd.com 17 Dec '03

17 Dec '03

I suppose C2 got as many "do you know how hard it is" complaints as I have, or more. But dispite that, several people broke keys. There seem at this point to be two messenger or man in the middle attacks on SSL that have enough merit to explore further. #1 Attack client binaries to suppress certificate validation, and accept ones forged by the filter/MITM. The binary attack could occur during down load from NetScape (a good ISP level attack) or after the fact with a virus. The client binary would be normally functioning with servers other than the attacking MITM filter. #2 Present client with the filters valid certificate and hope that in the rare case the user looks, that they will not question it, or even know what a valid one from the real server is. Since detection is possible in both of these, attack only a few percent of the traffic until the heat is on, then lay dormant or move to a different site. Suggested to me this morning was taking a harder look proxy servers. John

2 1

Re: Europe
by Mats Bergstrom 17 Dec '03

17 Dec '03

Perry M. wrote: > I was wondering if the Europeans had an equivalent of EPIC or EFF > lobbying against crypto restrictions there, given the disturbing news > a week or so ago. Europe, in this regard, is still mostly every country on it's own. Lobbying in Brussels is not for mortals, and decisions are in closed chambers anyway (the Commission; inter-governmental level). Sweden: The authorities have not yet said anything at all about where they stand in the GAK controversy. Probably very few have heard about it. A national IT-Commission was formed by the former government a year and a half ago, then they lost the elections a year ago and the new IT-Commission (yes, very partisan) has just settled down. The only thing that has come up on a public (television) level is demands from the police of access to decoded GSM traffic, which I believe is under implementation now (the obstacle has mainly been who is going to pay for the software updates of the GSM nodes). Sweden has rather strict rules for wiretapping (at least officially) and their is no public pressure for any change in this. On the local networks (the swnet.* newsgroups and Fidonet meetings) there is some discussion of crypto vs computer networking but only in obscure niches. If/when GAK will be proposed this might hopefylly change. I think the basic difference USA vs Sweden in this regard is a time delay of some years. We have lots of Internet nodes per capita (more than in the US, they say) but the net is still largly run by engineers (if only that could last!) and net awareness is rare above the age of 30 (i.e. among those who have a say). The European Council document (posted here in full by Dave Banisar) is certainly worrying. Of course, I've tried to spread it on the Swedish speaking networks For information on Swedish net cencorship there is a 'mini-CAF' at: http://www.dtek.chalmers.se/~d1dd/censorship/ PS Perry, what was your impression of the Swedes you met at the IETF meeting in Stockholm last July? I guess they were so happy about the new 34 Mbit/s connection to the New World that they forgot about the rest? Mats ********************************************************* For a searchable list of products in the Swedish national monopoly liquor-shops, see: http://lupus.physchem.kth.se/systemet.html

2 1

DNS Security ( was Re: NetScape's dependence upon RSA down...)
by Donald E. Eastlake 3rd 17 Dec '03

17 Dec '03

DNS security is an important point. People not aware of efforts in this area may want to check out draft-ietf-dnssec-secext-05.txt which has more or less passed working group last call and is being considered by th Security Area Directory / IESG. Reference code is also available (see message pasted at end below). Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee(a)cybercash.com 318 Acton Street +1 508-371-7148(fax) dee(a)world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) ================================ Date: Mon, 11 Sep 1995 10:24:28 -0400 From: James M Galvin <galvin(a)TIS.COM> To: dns-security(a)TIS.COM Subject: ANNOUNCEMENT: TIS/DNSSEC Version 1.2 alpha A new version of TIS/DNSSEC is now available. This version is distinguished from the previous version as follows. in sync with bind Beta26 uses RSAREF For information on how to acquire TIS/DNSSEC retrieve the file /pub/DNSSEC/README on the host ftp.tis.com via anonymous FTP. If you have any questions or problems please send a note to tisdnssec-support(a)tis.com. Enjoy, Jim

2 1

Re: WHERE did this [NOISE] come from?
by Alan Olsen 17 Dec '03

17 Dec '03

At 10:38 PM 9/30/95 GMT, you wrote: >Attatched to this is, (I hope), the header text from a unsolicited e-mail >message I received. The return address does not work. WHY? How can I >inform the sender that I hope to never receive there material again? > >I tried "reply-all" through Eudora, but my reply got bounced back to me >as undeliverable. > >I have removed the content of the original message. I don't know why it >was sent to me, but it contained material that I found offensive. > >Any help, or words of wisdom and enlightenment would be appreciated. >Information would be nice too. Well, at the bottom of the post, it listed contact info at: >National Alliance can also be reached at: > >WORLD WIDE WEB: http://www.natvan.com (if unavailable, try our ftp site) >FTP SITE: ftp.netcom.com, path /pub/NA/NA (I find it funny that they go through the trouble of forging an e-mail address yet they give ftp and web sites at the end of the page.) Hopefully that bit of targeting information will be of some use... | Visualize whirled keys | alano(a)teleport.com | |"It's only half a keyserver. I had to split the | Disclaimer: | |other half with the government man." - Black Art | Ignore the man | | -- PGP 2.6.2 key available on request -- | behind the keyboard.| | http://www.teleport.com/~alano | <fnord> |

1 0

SecureDrive News - Win95, non-USA ftp sites
by edgar＠highnrg.sbay.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I have received the following information about running SecureDrive 1.4 with Win95, thanks to Ed Stone, This is what I sent to a person who asked how to use secdrive on win95...... >>>>>>>>>>>>>>>>>>>>>inserted text follows Try this: in your autoexec.bat file enter this, using your path to secdrive: C:\your-path-to-secdrive\SECTSR C:\your-path-to-secdrive\LOGIN your-encrypted-disk-letter: /S C:\your-path-to-secdrive\login your-encrypted-disk-letter: During normal win95 startup, you will be asked to enter your passphrase. Now when 95 come up, the tsr is running, your passphrase has been entered, and everything operates as if the disk is not encrypted. EXCEPT.... the tsr you have loaded (sectsr) makes windows load real-mode drivers for the disk, instead of protected mode drivers. This will make disk access somewhat slower, but not a big deal. When you startup win95 and you don't need to use secdrive, just hit enter when the boot process asks for your passphrase, and it will behave as if you entered a "wrong passphrase" and that drive will not be visible to win95, and protected mode drivers will load... Hope this helps. In particular that the normal drivers will load even with sectsr resident if the correct passphrase isn't entered is new and valuable information. I have also just learned that SecureDrive 1.4 is now available on some non-USA (and so not export-controlled) ftp sites, ftp://utopia.hacktic.nl/pub/disk/secdr14.zip ftp://ftp.ox.ac.uk/pub/crypto/misc/secdr14.zip I have verified that the hacktic file is an exact copy of the zip I released in the USA. Edgar W. Swank <edgar(a)HighNRG.sbay.org> SecureDrive Co-author -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMG2BIt4nNf3ah8DHAQH49AP/YzmRhOLk+JdPx3emgWxv7vcX/2e7KR/Y WK0p1hiPUAHDsG3ZEd3fD+DZyILxq0oJcQSsrdtsAFiSnw955i/g+XsGFVT8UGku YzTXB4LXnJE4IqA2qd8aUKU9xk9S57xN1p+xrLlEK2jJrFMg+h9cPMp1a0lwivvP Ff2lF1+lthI= =DYRV -----END PGP SIGNATURE----- --- edgar(a)HighNRG.sbay.org Keep Freestyle Alive!

1 0

Quantum Crypto: Anecdote
by W. Kinney 17 Dec '03

17 Dec '03

Given the regularity with which fears of factoring by quantum compters comes up around here, I thought I'd share a brief story: At a party last night, I ran into a couple of acquantances, and was delighted to learn that they are working on the current NIST quantum computing project, making quantum gates out of atomic traps similar to those used by Cornell and Weiman to get a Bose condensate with Rubidium (crypto relevance comes from odd places, eh?) Anyway, I talked them up a bit, and so far they've managed to construct a working "or" gate. The long-term project is to construct a quantum computer capable of factoring 15, which they expect to take at least several years. I mentioned crypto and they literally laughed at me. The word from the trenches is "don't worry about it for a very long time." -- Will

2 1

Re: NetScape's dependence upon RSA down for the count!
by William.Soley＠Eng.Sun.COM 17 Dec '03

17 Dec '03

On Sun, Oct 1 1995, Simon Spero wrote: > On Sat, 30 Sep 1995, Don Stephenson wrote: > > > I don't think binding hostnames to certificates helps much because > > both hostnames and IP addresses can be spoofed and DNS servers can be > > subverted. The important thing is the binding to the "service" name or > > In this particular case, hostnames do help, because they are information > imbedded in the url used to access the server. By verifying the hostname > in the certificate with the hostname in the url, you can state with a > high degree of confidence that the object retrieved is precisely the > desired object covered by this url. > Hostnames help only a little. Often the host name belongs to the ISP that is providing the server resources. For example when I ordered sushi last night from WOW, the URL was "https://www.ird.net/[...]wow[...]", but the certificate was issued to "www.sunnyside.com" (as displayed by the File->DocumentInformation menu item in Netscape): Version: 00 Serial Number: 02:72:00:00:3C Issuer: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority Subject: C=US, ST=California, L=Palo Alto, O=Sunnyside Computing, Inc., OU=Internet Services, CN=www.sunnyside.com PROBLEMS: (1) The certificate *was* issued with a host name in the CN field, but it did not match the host name in the URL and my browser did not care to warn me of this discrepency (I had to manually request to see the certificate and check it myself -- not a likely precaution for Joe Sixpack). (2) Even if the certificate did match the URL (and my browser did check it) I still have no way to know that "Sunnyside Computing" or "sunnyside.com" or "ird.net" is actually the authentic/official ISP for WOW and not an imposter or MITM. (3) Netscape is making the problem worse (yes, worse) in the next release by allowing the user to specify their own list of trusted CAs. (I will elaborate on this unpopular view below.) NON-PROBLEMS: (1) SSL did its job. It is only a session layer. It assured the application that a secure session was established with the entity named in the certificate. (2) The sushi was very good. :-) DISCUSSION: Re: problem 2, it would be better to have the certificate issued with the subject ... O=Waiters on Wheels ... CN=www.ird.net ... so that the browser can automatically check it against the URL and the user can be assured that (assuming suitable CA policy) ird.net is an authentic/official ISP for WOW. I think the browser should check the CN and hostname in the URL and display a popup warning if they do not match, and (optionally but by default) display a popup whenever a new session is started with a different certificate -- and of course show the certificate. This is not perfect, of course, its just better. Re: problem 3, about how allowing the user to specify their own list of trusted CAs is bad. All it takes is for any web page to put up text like ... "Dear Joe Sixpack, in order to assure your privacy while viewing these naughty pictures you must add the following certificate to your such-and-such file ..." and Joe Sixpack will be happy to do it. Even Mary Moderately-Savy might be tricked in to doing it on the false assumption that it would only affect security for the naughty pictures site (that she may not care about), and not affect security for her stock-broker. This false assumption might be based on the fact that the (legitimate) stock-broker uses a different CA. -Bill

3 2

N$ SSL vs M$ PCT
by rah＠shipwright.com 17 Dec '03

17 Dec '03

--- begin forwarded text From: "John Hemming CEO MarketNet" <JohnHemming(a)mkn.co.uk> Date: Sun, 01 Oct 1995 20:36:31 PM PDT To: www-buyinfo(a)allegra.att.com Mime-Version: 1.0 Subject: N$ SSL vs M$ PCT Having found that Micro$oft have produced a standards document about their alternative to SSL I was interested in comparing it to that written by Net$cape. The big question in my view is why did they produce a new proposal is it: a) Because they have found major flaws in the SSL protocol and wish to correct these (note the protocol not the implementation) or is it b) Because M$ want to "own" the Internet Security Software market and take the initiative off N$ who, notwithstanding their problems with implementation, have produced a working system. My personal view is that b) is the case. Comparison I have compared SSL V3 <draft-hickman-netscape-sl-01.txt> (available at www.netscape.com) PCT http://www.microsoft.com/windows/ie/pct.htm <draft-microsoft-PCT-91.txt> Both have status of Internet Draft. I have implemented SSL V2 in a browser (ftp://193.119.26.70/mktnet/pub/horse.zip) and a server (https://alpha.mkn.co.uk/) I have not implemented and do not intend implementing PCT Both SSL V3 and PCT now involve a vast number of different alternatives for Ciphers most of these alternatives do not help in any practical sense and I have not compared the lists. PCT allows for supporting SSL as well by using a bit in the SSL version number to indicate PCT. This means that servers can support both protocols. Clients cannot as the first message is sent by the client and there is no provision for SSL/PCT negotiation. Both PCT and SSL start with an initial session (GET or POST in wwwland) which establishes a master key and allow continuations of that key in later sessions. M$ use the following arguments in support of PCT: 1. it is simpler. PCT uses longer messages with more fields in them. It cuts out the final SERVER-FINISHED and CLIENT-FINISHED messages. It puts some of the data in SSL into other records. I quite like the verification in the CLIENT-FINISHED message which means that bad implementatations crash out at that point rather than putting rubbish into the higher level protocol. However, I consider that in essence there is no real difference. I, therefore, disagree with M$. 2. Message authentication uses different keys to the encryption keys. How this helps, apart from making implementation harder, I cannot quite fathom. We should not be using this secure channel protocol for proper message authentication only. The MAC (Message Authentication Code) is not what I would use for authentication from a legal and contractual background. I prefer Digitally Signed Instructions. 3. They say there is a security hole in SSL's client authentication. When the initial session establishing a session key uses (for example) 40 bit encryption. It does mean that subsequent sessions are also essentially just as insecure. This is the case for PCT and SSL. However, client authentication in SSL uses a digital signature using the client's private key. To get hold of this requires something more than simply being man in the middle. I think M$ are well out of order on this one. 4. They introduce a verify prelude field to make sure that the cipher type and other negotiations have not been tampered with. I suppose this is a fair if disingenuous point. If a "man in the middle" is tampering with your negotiations to make sure that you use a low level of encryption so that it can be cracked then your implementations should not be using such crippleware and cypherpunks will have cracked it ages ago. There is a point that should be made that servers and clients should really indicate the encryption cipher being used. Both my client and server do. So in essence M$ make 4 arguments. Two are IMHO wrong. One is irrelevant from a commercial perspective and the other one does not matter. In the end N$'s version is working. M$ are probably coding like mad. The final formula to determine the result may be if (M$>N$) SSL+=PCT; where M$ and N$ are measured in US Dollars. (MarketN£t is a UK company independent of both M$ and N$ although N$ were helpful in debugging the interoperability of my early essays into SSL for which I am grateful.) --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0