RE: Free CA

[mark schoneman]

In the January issue of Computer Security Journal, Carl Ellison and
Bruce 
Schneier have article "Ten Risks of PKI: What You're not Being Told
about 
Public Key Infrastructure"

It can be found at http://www.counterpane.com/pki-risks.html

It really addresses policy and process issues more than technical
weaknesses.

Re: Free CA

[Tom Damon]

> 
> If users accept certificates without some independent way of verifying
> the identity of the signer, then this obviates the entire point of
> certificates, which is to prevent active attack on the connection.
> The vast majority of the complexity of SSL is there to prevent
> active attack. By choosing to use unauthenticated certificates,
> you are opening the door to a broad class of attacks.
> 
I agree completely. Imagine this: I have just connected to a server which I
BELIEVE to be a well known e-commerce site. There may or may not be some
network hanky-panky going on (DNS spoofing, man-in-the-middle...). What
assurance do I have that I'm really connected to the right server? At least,
with the preloaded roots, I have some assurance that a responsible party has
verified the servers identity. It's not a perfect system, but it puts enough
blocks up to make breaking it a non-trivial exercise.

__
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Free CA

[EKR]

"Leland V. Lammert" <[EMAIL PROTECTED]> writes:

> At 03:09 PM 6/12/00, you wrote:
> >Interesting...  I don't quite understand what the preloaded root certs
> >have as extra value.
> 
> The ONLY reason for e-commerce folks to sign up with a Root Cert CA
> (like Verisign or Thawte) is to prevent the nasty messages when a
> user initiates an SSL connection. Other than that, I, for one, will
> continue to use our self-generated certs .
This message confirms something I've long believed: The messages that
the browser puts up to warn you of errors in certificate verification
are worthless because users don't understand what they mean and will
blithely click through them.

If users accept certificates without some independent way of verifying
the identity of the signer, then this obviates the entire point of
certificates, which is to prevent active attack on the connection.
The vast majority of the complexity of SSL is there to prevent
active attack. By choosing to use unauthenticated certificates,
you are opening the door to a broad class of attacks.

-Ekr



__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Free CA

[Leland V. Lammert]

At 03:09 PM 6/12/00, you wrote:
>Interesting...  I don't quite understand what the preloaded root certs
>have as extra value.

The ONLY reason for e-commerce folks to sign up with a Root Cert CA (like Verisign or 
Thawte) is to prevent the nasty messages when a user initiates an SSL connection. 
Other than that, I, for one, will continue to use our self-generated certs .

Lee

   Leland V. Lammert[EMAIL PROTECTED]
  Chief Scientist Omnitec Corporation
  Network/Internet Consultants  www.omnitec.net


__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Free CA

[Arley Carter]

On Tue, 13 Jun 2000, Douglas [iso-8859-1] Wikström wrote:

> What you are saying is that I am free to buy stuff on the internet,
> sending the seller my creditcard number, and then tell the Bank it was
> not me. Given the following attack scenario I cant believe that is the
> case:
> 
Yup. If you are using a stolen credit card number it happens every day in
the physical world.  If you use your own credit card number and say you
didn't get the merchandise, then the merchant can track the delivery
receipt through the courier.  This would land you in an upcoming edition
of "Dumb crook news". ;-)

If what you bought was bytes of intellectual property, then the marginal
cost to the merchant is zero below a certain percentage of loss before it
threatens the foundation of the economic payment system.  

Bottom line, at a certain level of pain one of two scenarios will happen:
1. Banks will swallow the cost of implementing certs because it is
economically profitable to do so.
2.  The current model of Web commerce with credit cards will collapse, to 
be replaced by some other model.

The market for CA's is not and never will be a one size fits all market. 
What markets do others on the list think will become a viable market for
CA's in the near term, 1-2 years, and medium term, 5 years? 

Cheers:
-arc

Arley Carter[EMAIL PROTECTED]
Tradewinds Technologies, Inc.   www.twinds.com
Winston-Salem, NC  USA  Network Engineering & Security  
 

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Free CA

[Douglas Wikström]

Hello!

> > 4. At the practical and everyday level, we can be pretty sure that the
> > certs delivered with Netscape and IE are OK.  If we go to some fairly
> > well-traversed public site using one of these certs, some red flags will
> > go up when the you get signature mis-matches...  That will tip you off
> > that your cert list has been compromised.  Besides you could say: "What am
> > I risking? I take a no less a risk when I give my credit card to the
> > cashier, or when I order that L.L. Bean hunting jacket over the phone.
> > Don't bother me with your paranoia."
> 
> There in lies part of the problem and also part of the answer on how CA's
> should be structured.  The market niche for CA's needs to be defined more
> clearly.  Internet credit card commerce did not start to take off until
> last Christmas season when banks generally agreed that a web or internet
> credit card transaction classified as a "card not present" transaction,
> the same as a mail order telephone transaction.  The card card holder is
> not liable for misuse or loss.  The risk of loss is totally with the
> bank and the merchant.
What you are saying is that I am free to buy stuff on the internet,
sending the seller my creditcard number, and then tell the Bank it was
not me. Given the following attack scenario I cant believe that is the
case:

1) I use my own creditcard to by software on the internet using some
free of charge provider of space and email. Then I go to the nearest
internet-cafe with my zip disk and download the software. I never use
the free space or email again. In this way I can get ANY information for
free virtually without any risk of being caught.

2) Imagine what this means when/if selling of information (eg software)
on the net grows (which is not unrealistic given high performance
connections). Anybody can use my creditcard number to get software for
free. Note that this is NOT the case with the traditional postal order
companies (see above) (or pizza delivery :-) since in that case somebody
needs to physically be present when recieving the merchandise (since the
merchandise is of physical nature). It is hard for the Bank to argue
that I recieved something sent to a total stranger, and it involves some
work for the stranger to cover his tracks if the fraud is large.

The possible gain of the adversary is much larger in the electronic
world than in the real world (the >> scenario described above by
somebody else).

3) Note that everytime you shop in any store or go to a restaurant
somebody sees your card number. Thus it DOES NOT help to use a special
"internet" creditcard/paycard on the internet that wont allow large
payments.

4) If one is paranoid the only way today is to use either a cash-card,
plain old cash, or to be billed ofcourse.

5) We could fix all this with "physically secure" smartcards, and
infrastructure for using them ofcourse.

> An interesting question is "What less of loss is the bank willing to
> absorb before it becomes economically viable for the bank consortiums that
> run Mastercard and Visa to begin issuing and mandating the use of the
> bank issued cert for transactions?"  Implementing or mandating the use I
> believe just as big a marketing problem as a technical problem.
I agree, this is not a tech problem.
-- 

--
 Douglas Wikström <[EMAIL PROTECTED]>
--
 Yes, God created Man before Woman,
 but one always makes a draft before the masterpiece.
--
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Free CA

[Arley Carter]

On Mon, 12 Jun 2000, Yuji Shinozaki wrote:

> I think the problem is multi-leveled:

> 
> 
> 4. At the practical and everyday level, we can be pretty sure that the
> certs delivered with Netscape and IE are OK.  If we go to some fairly
> well-traversed public site using one of these certs, some red flags will
> go up when the you get signature mis-matches...  That will tip you off
> that your cert list has been compromised.  Besides you could say: "What am
> I risking? I take a no less a risk when I give my credit card to the
> cashier, or when I order that L.L. Bean hunting jacket over the phone.  
> Don't bother me with your paranoia."

There in lies part of the problem and also part of the answer on how CA's
should be structured.  The market niche for CA's needs to be defined more
clearly.  Internet credit card commerce did not start to take off until
last Christmas season when banks generally agreed that a web or internet
credit card transaction classified as a "card not present" transaction,
the same as a mail order telephone transaction.  The card card holder is
not liable for misuse or loss.  The risk of loss is totally with the
bank and the merchant. 

An interesting question is "What less of loss is the bank willing to
absorb before it becomes economically viable for the bank consortiums that
run Mastercard and Visa to begin issuing and mandating the use of the
bank issued cert for transactions?"  Implementing or mandating the use I
believe just as big a marketing problem as a technical problem.

Bank 1 :  "More secure"  Bank 2 :  "Less hassle"
Refrain with apologies to the beer industry. ;-)
 
Compared to the total volume, credit card usage Internet usage is still a
tiny fraction.  With Internet time however, I don't wouldn't want to guess
a product life cycle time here.

This leaves 999 (at least) other uses for CA's.  Time needs to spent on
how to define these market niche, scale economies and  implementation
issues.

Cheers:
-arc

Arley Carter[EMAIL PROTECTED]
Tradewinds Technologies, Inc.   www.twinds.com
Winston-Salem, NC  USA  Network Engineering & Security  


__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Free CA

[Dr Stephen Henson]

Richard Levitte - VMS Whacker wrote:
> 
> 
> Oh, what a beautiful mixup I did there between server and client
> certs!  Even got myself confused :-).  However, the fact still
> remains, there's no trust path of value to me, the value of certer
> certs in themselves is more or less none, except to give the server
> and my browser a chance to start an encrypted session, which is
> probably fine for most people.  And from that point of view you're
> absolutely right, the warning about an unknown CA is just an
> annoyance.  But hey, it would be possible for someone to get a
> perfectly legal CA cert signed by, Thawte, and then use it to sign a
> cert presumably for, oh say, Amazon, and thereby fool a whole bunch of
> people.  And in that case, a *silent* browser is a bit more scary to
> me.  Setting up a secure channel is nice enough, but authentication is
> a different matter, and depending on your level of paranoia, quite a
> difficult one at that.
> 
> People just don't have that clue yet...  Or maybe I'm just overly
> paranoid...
> 

Paranoia is essential for crypto work :-)

I reckon this kind of issue is likely to become more important as more
CAs get added to browsers.

A corrupt CA or one which can be forcibly persuaded (e.g. by government
security agencies) to issue bogus certificates can reak havoc with
typical browser or S/MIME client behaviour. 

For example if some country wants to monitor all traffic to a certain
secure site it issues a bogus certificate from its trusted CA and then
performs a man in the middle attack on its gateways.

S/MIME can be handled because many pieces of software will silently
replace a certificate with a new one. So sending a signed message with
the fake ID to the 'victim' allows all traffic from then on to be read.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Free CA

[Yuji Shinozaki]

On Mon, 12 Jun 2000, Richard Levitte - VMS Whacker wrote:

> Oh, what a beautiful mixup I did there between server and client
> certs!  Even got myself confused :-).  However, the fact still
> remains, there's no trust path of value to me, the value of certer
> certs in themselves is more or less none, except to give the server
> and my browser a chance to start an encrypted session, which is
> probably fine for most people.  And from that point of view you're
> absolutely right, the warning about an unknown CA is just an
> annoyance.  But hey, it would be possible for someone to get a
> perfectly legal CA cert signed by, Thawte, and then use it to sign a
> cert presumably for, oh say, Amazon, and thereby fool a whole bunch of
> people.  And in that case, a *silent* browser is a bit more scary to
> me.  Setting up a secure channel is nice enough, but authentication is
> a different matter, and depending on your level of paranoia, quite a
> difficult one at that.
> 
> People just don't have that clue yet...  Or maybe I'm just overly
> paranoid...

You may be paranoid, but that doesn't mean that people aren't out to get
you :-)  

I think the problem is multi-leveled:

1. Most users don't understand what a PKI or a CA is.  So, having a pop-up
that comes up with a new CA, sends them into a complete quandary and makes
them feel uneasy.

2. Netscape and MS don't want to make the user feel uneasy, if they don't
have to.  So, they provide a "trust list" of CAs and set the browsers so
that everyone "trusts" these CA's without being bothered with questions.  
[ In other words:  Hide the issues from the user to keep them from feeling
icky ]

3. Of course, at the technical purist level, this is wrong.  Every CA
(i.e. every self-signed cert) that you use should be verified by some
out-of-band (non-PKI) method and closely protected locally, so that you
are always assured of using a copy that you have personally verified.
However, this is not easy to do.  Frankly, it is a lot of work and in most
cases, impractical.

4. At the practical and everyday level, we can be pretty sure that the
certs delivered with Netscape and IE are OK.  If we go to some fairly
well-traversed public site using one of these certs, some red flags will
go up when the you get signature mis-matches...  That will tip you off
that your cert list has been compromised.  Besides you could say: "What am
I risking? I take a no less a risk when I give my credit card to the
cashier, or when I order that L.L. Bean hunting jacket over the phone.  
Don't bother me with your paranoia."

1. and 2. perpetuate each other.  By making the browsers as "friendly" as
possibly, Netscape and IE gloss over and hide the real issues behind PKI.  
But of course, by hiding the issues the user population will never learn.
Since the user population doesn't understand this stuff, you must continue
to hide it.  When those situations that aren't "well-hidden" (requiring a
pop-up) occur, the usually well-hidden issues are exposed, leaving the
user scratching his/her head.

Why hide it?  Because the issues are complicated.  To do it "right" (as in
3.) is impractical and given the current education of the users in PKI
issues, nearly impossible.  So we settle for the situation, like in 4.

But shouldn't we have higher goals than that?  

yuji

Yuji Shinozaki  Computer Systems Senior Engineer
[EMAIL PROTECTED]   Advanced Technologies Group
(804)924-7171   Information Technology & Communication
http://www.people.virginia.edu/~ys2nUniversity of Virginia


__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Free CA

[Richard Levitte - VMS Whacker]

From: Bill Klein <[EMAIL PROTECTED]>

bill> Richard Levitte wrote:
bill> >Interesting...  I don't quite understand what the preloaded root certs
bill> >have as extra value.  I for one don't really know anyone at Verisign
bill> >or Thawte, and can therefore not give them more trust than anyone else
bill> >that I know more or less nothing about.  For example, I'd rather trust
bill> >a cert for Oscar Jacobsson if it was issued by Celo Communications [1]
bill> >than if it was issued by Thawte, simply because I happen to know that
bill> >Oscar works at Celo, and Celo should at least know something more
bill> >about it's employees than Thawte or Verisign ever would...

Oh, what a beautiful mixup I did there between server and client
certs!  Even got myself confused :-).  However, the fact still
remains, there's no trust path of value to me, the value of certer
certs in themselves is more or less none, except to give the server
and my browser a chance to start an encrypted session, which is
probably fine for most people.  And from that point of view you're
absolutely right, the warning about an unknown CA is just an
annoyance.  But hey, it would be possible for someone to get a
perfectly legal CA cert signed by, Thawte, and then use it to sign a
cert presumably for, oh say, Amazon, and thereby fool a whole bunch of
people.  And in that case, a *silent* browser is a bit more scary to
me.  Setting up a secure channel is nice enough, but authentication is
a different matter, and depending on your level of paranoia, quite a
difficult one at that.

People just don't have that clue yet...  Or maybe I'm just overly
paranoid...

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \  SWEDEN   \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

Unsolicited commercial email is subject to an archival fee of $400.
See  for more info.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]