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]
Message-ID: <000801c514ce$448c21a0$0a01a8c0@anchorsign.com>
Date: Thu, 17 Feb 2005 00:54:19 -0800
From: "Thor (Hammer of God)" <thor@...merofgod.com>
To: "bkfsec" <bkfsec@....lonestar.org>, <davids@...master.com>
Cc: <kbo@....tiscali.de>, "Vincent Archer" <var@...y-all.com>,
	<bugtraq@...urityfocus.com>,
	"Scott Gifford" <sgifford@...pectclass.com>
Subject: Re: International Domain Name [IDN] support in modern browsers allows attackers to spoof domain name URLs + SSL certs.


> Symantec wouldn't do this.  The backlash they would recieve from angry 
> users alone would be enough to discourage it, nevermind the potential for 
> legal problems.

Hmmm...  I'm confused now... You just said in your last post that average 
users don't want, need, or know how certificates work, and how your previous 
(and specious) point stood because of that fact.  Yet here, you state that 
enough of a backlash from these users exists to keep a global entity like 
Symantec from taking action should they revoke a trusted CA from a users' 
certificate store even though the user (according to you) didn't know they 
trusted in the first place.   Explain that.

> Comparing CA accountability to meat sales isn't a valid analogy. 
> Obviously, the CAs don't want to be regulated, but trusting them because 
> of this is a bit like saying that business owners would never short-pay an 
> employee because of fear of what the employees would do.

David was not comparing accountability to sales.  He compared trust to 
trust.  Pretty simple stuff.

> It's also like saying that corporations never form trusts and price fix 
> for fear of the consumer.

Excellent point.  I retort by saying that I have a stamp collection of New 
Zealand butterflies.

> Obviously, both of these assumptions are wrong and the assumption 
> regarding CAs is also wrong.  The fact that it is assumed in the first 
> place is *the problem*.

Um, *you* made those assumptions.  And I agree: they are wrong.

> Also, the fact that the CA market is competitive only further muddies the 
> waters.  Not all CAs are in the same country and their competition forces 
> them to be price-competitive.  This reduces the priority of being 
> responsible.  Or, to use your meat analogy, mass-produced meat tends to be 
> of a lower quality than individually produced meat products, particularly 
> in unregulated countries.

I acquiesce.  I failed to take into account the multi-national 
not-for-profit CA's out there making a killing by scooping up the free 
end-user business that you claim does not exist in the first place.

> People who think that the market will inherently protect them have been 
> reading too much Ayn Rand and need to step away from the 
> fiction-proposed-as-fact isle.  No offense meant by that - it's said 
> tongue-in-cheek.  :)

No Barry, we just understand that the market corrects itself in these 
matters.  That's how the market works.  Once upon a time, there was no such 
thing as a certificate.  Now it is a billion dollar biz.  It has nothing to 
do with the BBB or who you think is the average user.  I deploy and maintain 
an extensive PKI infrastructure for my company as I do for many of my 
clients.  I'm happy to engage in further dialog regarding this subject so 
that I may have the opportunity to learn something, but before I do so, I'd 
like to get a glimpse into the vast PKI infrastructure you maintain so that 
I may prioritize your input.   Please describe your Cert/PKI infrastructure 
so that we may all benefit from your knowledge.

T



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ