<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [bc-gnso] Hackers exploit chink in Web's armor
- To: <lynn@xxxxxxxxxxxxxxxxxxxxxxxxxx>
- Subject: RE: [bc-gnso] Hackers exploit chink in Web's armor
- From: "Chris Chaplow" <chris@xxxxxxxxxxxxx>
- Date: Fri, 25 Mar 2011 19:57:44 +0100
Lynn,
Correct.
Here in a tourist region of Spain there are many apartment for rent websites or
other small business websites which only have mobile phone numbers as the
contact.
Increasingly consumers are finding services not up to standard and in some case
non existent.
When they start to seek redress they find that there is no way to contact the
business. Only a mobile phone which is not answered and an email is not
answered.
Local law (www.lssi.es) which is an application of an EU directive demands
full contact details (name, address, tel, etc) to be published on websites.
This is often ignored so Whois is a very useful starting point for any
consumer complaints.
best
Chris Chaplow
Managing Director
Andalucia Web Solutions
Avenida del Carmen 9
Ed. Puertosol, Puerto Deportivo
1ª Planta, Oficina 30
Estepona, 29680
Malaga, Spain
Tel: + (34) 952 897 865
Fax: + (34) 952 897 874
E-mail: <mailto:chris@xxxxxxxxxxxxxxx> chris@xxxxxxxxxxxxxxx
Web: <http://www.andaluciaws.com/> www.andaluciaws.com
De: owner-bc-gnso@xxxxxxxxx [mailto:owner-bc-gnso@xxxxxxxxx] En nombre de
lynn@xxxxxxxxxxxxxxxxxxxxxxxxxx
Enviado el: viernes, 25 de marzo de 2011 1:23
Para: Phil Corwin
CC: bc-gnso@xxxxxxxxx
Asunto: RE: [bc-gnso] Hackers exploit chink in Web's armor
Thanks Phil!
This is helpful in discussions about consumer uses of Whois data. One view is
that Whois data, if accurate and reliable, could provide validation of who
"owns" a website. Another view is that websites who use SSL encryption have
been "validated" and consumers can see the little lock icon on the URL space.
This article gives a good explanation on why consumers cannot rely on the SSL
icon as proof that ownership of a domain name and associated website have been
verified. And it emphasizes the need for consumer trust in the accuracy and
ease of availability of Whois data.
Lynn
-------- Original Message --------
Subject: [bc-gnso] Hackers exploit chink in Web's armor
From: Phil Corwin <psc@xxxxxxxxxxx>
Date: Thu, March 24, 2011 6:12 pm
To: "bc-gnso@xxxxxxxxx" <bc-gnso@xxxxxxxxx>
I'm not sure if there is a role for ICANN in addressing this, but it certainly
appears to be a major Internet/e-commerce security issue ---
http://news.cnet.com/8301-31921_3-20046588-281.html?tag=nl.e703
March 24, 2011 4:00 AM PDT
Hackers exploit chink in Web's armor
by <http://www.cnet.com/profile/declan00/> Declan McCullagh and
<http://www.cnet.com/profile/elinormills/> Elinor Mills
<http://www.cnet.com/profile/elinormills/>
A long-known but little-discussed vulnerability in the modern Internet's design
was highlighted yesterday by a
<http://news.cnet.com/8301-31921_3-20046340-281.html> report that hackers
traced to Iran spoofed the encryption procedures used to secure connections to
Google, Yahoo, Microsoft, and other major Web sites.
This design, pioneered by Netscape in the early and mid-1990s, allows the
creation of encrypted channels to Web sites, an important security feature
typically identified by a closed lock icon in a browser. The system relies on
third parties to issue so-called certificates that prove that a Web site is
legitimate when making an "https://" connection.
The problem, however, is that the list of certificate issuers has ballooned
over the years to approximately 650 organizations, which may not always follow
the strictest security procedures. And each one has a copy of the Web's master
keys.
<http://i.i.com.com/cnwk.1d/i/tim/2011/03/23/ComodoIran.png> Compromise
related to fraudulent digital certificates is traced to IP addresses in Iran,
Comodo says.
Compromise related to fraudulent digital certificates is traced to IP addresses
in Iran, Comodo says.
(Credit: <http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html> Comodo)
"There is this problem that exists today where there are a very large number of
certificate authorities that are trusted by everyone and everything," says
<https://www.eff.org/about/staff/peter-eckersley> Peter Eckersley, senior staff
technologist at the <http://www.eff.org/> Electronic Frontier Foundation who
has compiled a list of them.
This has resulted in a bizarre situation in which companies like Etisalat, a
wireless carrier in the United Arab Emirates that
<http://news.bbc.co.uk/2/hi/technology/8161190.stm> implanted spyware on
customers' BlackBerry devices, possess the master keys that can be used to
impersonate any Web site on the Internet, even the U.S. Treasury,
BankofAmerica.com, and Google.com. So do more than 100 German universities, the
U.S. Department of Homeland Security, and random organizations like the Gemini
Observatory, which operates a pair of 8.1-meter diameter telescopes in Hawaii
and Chile.
It's a situation that nobody would have anticipated nearly two decades ago when
the cryptographic protection known as SSL (Secure Sockets Layer) began to be
embedded into Web browsers. At the time, the focus was on securing the
connections, not on securing the certificate authorities themselves--or
limiting their numbers.
"It was the '90s," says security researcher <http://dankaminsky.com/> Dan
Kaminsky, who <http://news.cnet.com/8301-10789_3-9985618-57.html> discovered a
serious Domain Name System flaw in 2008. "We didn't realize how this system
would grow." Today, there are now about 1,500 master keys, or signing
certificates, trusted by Internet Explorer and
<http://www.cnet.com/firefox-3/> Firefox.
The vulnerability of today's authentication infrastructure came to light after
Comodo, a Jersey City, N.J.-based firm that issues SSL certificates, alerted
Web browser makers that an unnamed European partner had its systems
compromised. The attack originated from an Iranian Internet Protocol address,
according to Comodo Chief Executive Melih Abdulhayoglu, who told CNET that the
skill and sophistication suggested a government was behind the intrusion.
Spoofing those Web sites would allow the Iranian government to use what's known
as a man-in-the-middle attack to impersonate the legitimate sites and grab
passwords, read e-mail messages, and monitor any other activities its citizens
performed, even if Web browsers show that the connections were securely
protected with SSL encryption.
If Comodo is correct about the attack originating from Iran, it wouldn't be the
first government in the region to have taken similar steps. Late last year, the
Tunisian government
<http://www.theatlantic.com/technology/archive/2011/01/the-inside-story-of-how-facebook-responded-to-tunisian-hacks/70044/>
undertook an ambitious scheme to steal an entire country's worth of Gmail,
Yahoo, and Facebook passwords. It used malicious JavaScript code to siphon off
unencrypted log-in credentials, which allowed government agents to infiltrate
or delete protest-related discussions.
Comodo's revelation throws into sharp relief the list of flaws inherent in the
current system. There is no automated process to revoke fraudulent
certificates. There is no public list of certificates that companies like
Comodo have issued, or even which of its resellers or partners have been given
a duplicate set of the master keys. There are no mechanisms to prevent
fraudulent certificates for Yahoo Mail or Gmail from being issued by
compromised companies, or repressive regimes bent on surveillance; Tunisia even
has its own <http://www.certification.tn/index.php?id=4> certificate-issuing
government agency.
"These organizations act as cornerstones of security and trust on the Internet,
but it seems like they're not doing basic due diligence that other
organizations are expect to do, like the banks," says Mike Zusman, managing
consultant at Web app security firm <http://intrepidusgroup.com/> Intrepidus
Group <http://intrepidusgroup.com/> . "I'm not sure what we need to do but I
think it's time we start addressing the issue of trust and issues of
certificate authorities potentially not living up to standards that they should
be."
Over the last few years, a handful of papers and demonstrations at hacker
conferences have focused more attention on the topic. But the Comodo intrusion,
which appears to be the first public evidence of an actual attack on the way
the Web handles authentication, could be a catalyst for rethinking the way to
handle security.
Two years ago, for instance, Zusman
<http://intrepidusgroup.com/insight/2009/01/nobody-is-perfect/> was able to get
a certificate from Thawte, a VeriSign subsidiary, for "login.live.com" just
based on an e-mail address he created on the Hotmail domain. Even though it was
revoked, it still worked in a Web browser during a demonstration at the Black
Hat conference in Las Vegas. Comodo, too, has previously been shown to have
<https://blog.startcom.org/?p=145> lax security standards among its resellers
as far back as December 2008.
"Remember, the only reason Iran has to go to the lengths they've gone to to get
certificates is because they don't have a (certificate issuer) of their own...
most countries can just generate their own," says Moxie Marlinspike, chief
technology officer of mobile app developer <http://www.whispersys.com/>
Whisper Systems, who has discovered
<http://news.cnet.com/8301-27080_3-10299459-245.html> serious problems with Web
authentication before. One problem, he says, is that companies that issue
certificates have a strong economic incentive to make it as easy as possible to
obtain them.
Another worrisome aspect is that browser makers don't always have a good way to
revoke fraudulent certificates. A
<https://bugzilla.mozilla.org/show_bug.cgi?id=642395> discussion thread at
Mozilla.org, makers of the Firefox browser, shows that after being alerted by
Comodo, they had no process to revoke the faux certificates. Mozilla developers
ended up having to write new code and test a patch, which took a few days and,
even after its release, meant that only users who downloaded new versions of
Firefox benefit.
Google's Chrome, on the other hand, uses a
<http://googlechromereleases.blogspot.com/2011/03/stable-and-beta-channel-updates_17.html>
transparent update system for desktop versions but not necessarily mobile
ones. Microsoft
<http://www.microsoft.com/technet/security/advisory/2524375.mspx> said
yesterday that "an update is available for all supported versions of Windows to
help address this issue."
<http://www.cl.cam.ac.uk/~rja14/> Ross Anderson, professor of security
engineering at the University of Cambridge's computer laboratory, offered an
anecdote in this paper ( <http://spw.stca.herts.ac.uk/2.pdf> PDF): "I asked a
panelist from the Mozilla Foundation why, when I updated Firefox the previous
day, it had put back a certificate I'd previously deleted, from an organisation
associated with the Turkish military and intelligence services. The Firefox
spokesman said that I couldn't remove certificates--I had to leave them in but
edit them to remove their capabilities - while an outraged Turkish delegate
claimed that the body in question was merely a 'research organisation.'"
Jacob Appelbaum, a Tor Project developer who is a subject of a
<http://news.cnet.com/8301-31921_3-20042277-281.html> legal spat with the
Justice Department over his
<http://news.cnet.com/8301-1009_3-20010866-83.html> work with WikiLeaks, says
Mozilla should have warned of the vulnerability immediately and shipped Firefox
4 with a way to detect and revoke bad certificates turned on by default. (The
technique is called
<http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol> Online
Certificate Status Protocol, or OSCP).
"Mozilla's not taking their responsibility to the Internet seriously," said
Appelbaum, who wrote an
<https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion>
independent analysis of the situation. "A Web browser isn't a toy. It's being
used as a tool to overthrow governments...At the end of the day, they did not
put their users first."
Some long-term technical fixes have been proposed, with names like
<http://www.ietf.org/id/draft-ietf-dane-protocol-06.txt> DANE,
<http://tools.ietf.org/html/draft-hoffman-server-has-tls-04> HASTLS,
<http://tools.ietf.org/html/draft-hallambaker-donotissue-03> CAA (Comodo's
Philip Hallam-Baker is a co-author), and <http://web.monkeysphere.info/>
Monkeysphere. The technology known as
<http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions> Domain
Name System Security Extensions, or DNSSEC, can help. The Electronic Frontier
Foundation's Eckersley, who runs the groups <https://www.eff.org/observatory>
SSL Observatory <https://www.eff.org/observatory> that tracks SSL
certificates, hints that he'll soon offer another proposal about how to
reinforce the Web's cryptographic architecture.
"We do in fact need a way not to trust everyone," Eckersley says. "We have
1,500 master certificates for the Web running around. That's 1,500 places that
could be hacked and all of a sudden you have to scramble to dream up a
solution."
Read more: <http://news.cnet.com/8301-31921_3-20046588-281.html#ixzz1HYctsBUi>
http://news.cnet.com/8301-31921_3-20046588-281.html#ixzz1HYctsBUi
Philip S. Corwin, Founding Principal
Virtualaw LLC
1155 F Street, NW
Suite 1050
Washington, DC 20004
202-559-8597/Direct
202-559-8750/Fax
202-255-6172/cell
"Luck is the residue of design" -- Branch Rickey
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|