Who's afraid of Mallory Wolf?

Anne & Lynn Wheeler lynn at garlic.com
Mon Mar 24 12:10:53 EST 2003


At 11:10 PM 3/23/2003 -0500, Ian Grigg wrote:
>Who's afraid of Mallory Wolf?

slight observations ... i've heard of no cases of credit card number 
intercepted on the internet "in flight" (requiring crypto) ... and no known 
cases of MITM attack (requiring certificates)

However there have been some cases of impersonation ... being directed to a 
counterfeit web-site. I know of no cases of that being done with DNS cache 
poisoning ... which is also what certificates are targeted at ... both MITM 
and other impersonations of various kind. the ones i'm aware of is that the 
person clicks on some URL and goes to that site .... which is a counterfeit 
website. This isn't caught by SSL ... since it just compares the domain 
name in the URL against the domain name in the certificate presented by the 
server. Since the subterfuge happens well before any DNS cache is involved 
... the SSL check of matching domain names doesn't catch anything. There 
have also been various impersonation involving frames and other screen 
painting techniques.

There have been cache poisonings (ip-address take over) ... there have been 
also incidents in the press of domain name hijacking ... sending updates to 
domain name infrastructure convincing them that somebody else is the new 
domain name owner. getting a new certificate as the new domain name owner 
is also a way of subverting the SSL check of matching domain names.
http://www.garlic.com/~lynn/aepay4.htm#dnsinteg1
http://www.garlic.com/~lynn/aepay4.htm#dnsinteg2
people registering public keys at the same time they register domain names 
was one of the suggested countermeasures to domain name hijacking.

There was another press thing last week regarding DNS attacks. The issue 
raised by the DNS attack last fall and the latest warning is that these 
have the potential to bring the internet to a halt.
http://www.computerworld.com/securitytopics/security/story/0,10801,79576,00. 
html

so there is some effort regarding dns integrity because of its critical 
importance for just having internet function at all.

past dns attack refs:
http://www.garlic.com/~lynn/2003.html#49
also
http://www.computerworld.com/securitytopics/security/cybercrime/story/0,1080 
1,75564,00.html
http://www.zdnetindia.com/news/commentary/stories/73781.html
http://www.zdnetindia.com/print.html?iElementId=73777

from a cost of business standpoint ... i've suggested why not use the 
existing DNS infrastructure to distribute server public keys in the same 
way they distribute ip-address (they are pieces of information bound to the 
domain name, a function of the domain name infrastructure).... and are 
capable of distributing other things ... like administrative & technical 
contacts .... although that is getting restricted ... some bleed over from pkix
http://www.garlic.com/~lynn/aadsm13.htm#38 The case against directories
http://www.garlic.com/~lynn/aadsm14.htm#0 The case against directories

they could be naked public keys ... which would also be subject to DNS 
cache poisoning ...  or they could be "signed" public keys .... doesn't 
need all the baggage of x509 certs ... can just be really simple signed 
public key.

Slightly related to the above posting about long ago and far away .... when 
looking at allowing people (20 plus years ago) on business trips to use 
portable terminals/PCs to dial in and access the internal network/email 
.... a vulnerability assesement found that one of the highest problem areas 
was hotel PBXs. as a result a special 2400 baud encrypting modem was 
created.  encrypting modem anecdote from the time:
http://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk 
(was: IBM Mainframe at home)

... these weren't in any related to the link encrypters from the previous 
reference (aka supposedly over half of the link encrypters in the world 
were installed on the internal network).

in any case, there was a big concern about numerous kinds of evesdropping 
... requiring encryption for information hiding. however, the current 
internet credit card scenario seems to be that it is so much easier to 
harvest a whole merchant file with tens or hundreds of thousands of numbers 
... than trying to get them one or two at a time off some internet connection.

note that the x9.59 approach has always been to remove the credit card 
numbers as a point of attack (form of shared-secret) by requiring all 
transactions to be authenticated. as a result, just knowing the number 
isn't sufficient for fraud (countermeasure against all account number 
harvesting .... regardless of the technique and whether insider or outsider 
attack):
http://www.garlic.com/~lynn/index.html#x959
the low-hanging fruit theory is that if merchant sites were armored then 
there could be more interest in evesdropping-based harvesting ... (leading 
to more demand for internet encryption). However. armoring merchant sites 
is difficult since 1) there are potentially millions, 2) human mistake is 
frequent/common vulnerability, 3) still leaves insiders as threat.

other parts of security proportional to risk thread:
http://www.garlic.com/~lynn/2002d.html#8 Security Proportional to Risk 
(was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk 
(was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk 
(was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#24 Security Proportional to Risk 
(was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#25 Security Proportional to Risk 
(was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#28 Security Proportional to Risk 
(was: IBM Mainframe at home)
--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
  


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com



More information about the cryptography mailing list