lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 11 Feb 2005 16:44:55 -0600
From: Neil W Rickert <rickert+bt@...niu.edu>
To: bugtraq@...urityfocus.com
Cc: Scott Gifford <sgifford@...pectclass.com>
Subject: Re: International Domain Name [IDN] support in modern browsers allows attackers to spoof domain name URLs + SSL certs.


Scott Gifford <sgifford@...pectclass.com> wrote on Feb 11, 2005:

>Maybe I'm naive, but shouldn't a trustworthy root CA not sign
>certificates for domain names which are obviously meant to be
>deceptive?

Signing the certificate earns income for the CA and its shareholders,
and serves the customer who requested that the certificate be
signed.  If a CA were to set very high standards and check very
carefully, then it would price itself out of the market.

As a user of a browser I am not a customer of the CA, and it isn't
evident why the CA should be under any obligation to me.  They surely
are under an obligation to their shareholders and their customers.

>            Isn't this the entire reason for browsers coming with a
>small list of CAs which are deemed trustworthy?

Perhaps I am too cynical.  But I always thought they were there to
advance the business interests of the CAs.

>If the holders of widely-trusted root certificates can't be trusted to
>avoid even the most rudimentary deceptions, many of the protections of
>SSL have only very limited value.

The protections have only very limited value.  They are perhaps
adequate to make MITM attacks unlikely, but they are not capable of
dealing with the kind of deception being discussed here.

>Perhaps some more care on the part of browser packagers in deciding
>which CAs have their certificates included by default is the solution.

This would not help much.  The existing PKI based system is based on
an unnatural network of presumed trust.

A better system would allow a certificate to have many co-signers,
much as PGP keys can be co-signed by many others.  In such a system,
my credit card company could act as CA.  I am a customer of my credit
card company, so this would build on natural trust relations.
Moreover, my credit card company could act as guarantor for any
purchases I make at web sites where they have signed the site
certificate (presuming that I use their credit card).  This would
provide a substantial financial incentive for the credit card
company, acting as CA, to be wary of possible deceptive practices.

 -NWR




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ