Re: Certificate questions...

[EKR]

Jon Earle <[EMAIL PROTECTED]> writes:

> At 07:36 AM 3/7/00 -0800, you wrote:
> >Karl Denninger <[EMAIL PROTECTED]> writes:
> > > Well, confidentiality implies integrity, in that a tampered data stream
> > > won't decode.  Public key crypto with a known certification on the public
> > > key provides non-repudiation (assuming the private key has not been
> > > compromised)
> 
> >This is absolutely not true.
> >
> >Consider a data stream enciphered with RC4. It's perfectly
> >easy to undetectably flip any plaintext bit by
> >flipping the corresponding ciphertext bit. If you know the
> >plaintext, you can modify it predictably.
> 
> Perhaps... but isn't this impractical?  The key phrase here is "If you know the
> plaintext...".
If you know the plaintext you can make PREDICTABLE changes. Without
the plaintext, you can make arbitrary undetected changes.

> How would one know if a random, encrypted stream is a 
> recipe, a love letter, or a secret message to religious extremists?  It all 
> just looks like encrypted packets.
You can tell an incredible amount from traffic analysis.
For instance, connections on port 443 are almost always HTTP
over SSL. If you've been looking at the previous HTTP traffic
between this client and server pair, you can often get a pretty
good idea of what the first encrypted message is.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]]
  PureTLS - free SSLv3/TLS software for Java
http://www.rtfm.com/puretls/
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]

Re: Certificate questions...

[Jon Earle]

At 07:36 AM 3/7/00 -0800, you wrote:
>Karl Denninger <[EMAIL PROTECTED]> writes:
> > Well, confidentiality implies integrity, in that a tampered data stream
> > won't decode.  Public key crypto with a known certification on the public
> > key provides non-repudiation (assuming the private key has not been
> > compromised)

>This is absolutely not true.
>
>Consider a data stream enciphered with RC4. It's perfectly
>easy to undetectably flip any plaintext bit by
>flipping the corresponding ciphertext bit. If you know the
>plaintext, you can modify it predictably.

Perhaps... but isn't this impractical?  The key phrase here is "If you know the
plaintext...". How would one know if a random, encrypted stream is a 
recipe, a love letter, or a secret message to religious extremists?  It all 
just looks like encrypted packets.

Jon
-
Jon Earle   (613) 612-0946 (Cell)
HUB Computer Consulting Inc.(613) 830-1499 (Office)
http://www.hubcc.ca 1-888-353-7272 (Within Canada/US)

"God does not subtract from one's alloted time on Earth,
those hours spent flying."   --Unknown

__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]

Re: Certificate questions...

[Jon Earle]

At 12:23 AM 3/7/00 +0100, you wrote:

> > Yet, in today's world, you cannot have one without the other, which means
> > that to get EITHER you must pay someone.
>
>The pay part is untrue.  If you really don't care about authenticity but
>only are interested in confidentiality of your datastream (if you cannot
>verify the authenticity of the entities on either side of your datastream I
>think you're quite vulnerable for loosing your confidentiality, but that's
>your choice) you can just generate your own certificate.

And this is what we've done - we don't need to verify that the person on 
the far end of the connection really is Bob.  As long as the stream is 
strongly encrypted, we are safe from casual sniffing of packets.  You still 
need to access the protected portion of the site via a valid 
username/password, and that is where the authentication may enter into play 
(to strengthen the logon portion).  In that case, we'd need to generate 
individual certificates for each user, and truck them around wherever we 
go.  To much hassle for what we need, which is just basic protection from 
kiddies with sniffers.

If you're running an Ecommerce site, then issuing individual certificates 
is wholly impractical.  In that case, all we really want is encryption.  It 
would be nice to have a cert signed by Verisign, but we (our corporate 
entity) trust ourselves, and that is good enough for us.  I'm sure 
customers are more concerned with having their data encrypted moreso than 
worrying whether the session is being hijacked, which I believe is quite 
difficult to accomplish if the session (which is typically short) uses 
strong encryption.  Our customers trust us as a corporate entity, so I fail 
to see why us issuing our own certificate is any more or less "secure" than 
us paying $$ to another company to do the same thing.

> > Contrast this with PGP for email, in which I can publish a public key and
> > once you obtain it you're able to receive an encrypted communication from
> > me and decode the traffic.  My generation of that key pair does not require
> > that it be "certified" by any third party.
>
>I hope you made some typo here.  You do not use the thing conceptually
>referred to as "public key" to decode encrypted traffic/messages.  That's
>what the private thingie is for.  The public part is for signature
>verification (ie verifying the private part has been used to encrypt a piece
>of data).
>
>Problem with your PGP schema is that I can publish my public key on the
>keyserver (lets say the keys.pgpi.net which I trust a lot ;), you can get it
>there and use it to crypt data for me.  Essential problem here: how do you
>know that the key you're using is mine and not from someone claiming to be
>me (by entering *my* emailaddress and name during key generation)?  Using
>signatures --> signature=certificate.

In this case - who cares?  You'll receive a message composed and encrypted 
using the fake public key, but will be unable to decrypt it.  If you 
compose a message, a recipient using the fake key will not be able to 
decrypt it.  The worst that happens, as I see it, is an annoyance caused to 
both parties.


 >  What is true is
 >that those stupid browser applications refuse to see key generation and the
 >*possible* certification as different steps.  With openssl of course this is
 >possible.

>I agree the key generation and the certification process *should* be
>seperated, also in browsers.  It is *not* possible for me to make a copy of
>my oh so valuable private browser key *before* I receive my certificate
>(which can be up to five days according to our certification practise
>statement) which bothers me very much.  I can not revoke the certificate and
>just use the same key again.

I'm not understanding what you are discussing here.  Can you explain this 
concept a bit further please?

Cheers!
Jon
-
Jon Earle   (613) 612-0946 (Cell)
HUB Computer Consulting Inc.(613) 830-1499 (Office)
http://www.hubcc.ca 1-888-353-7272 (Within Canada/US)

"God does not subtract from one's alloted time on Earth,
those hours spent flying."   --Unknown

__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]

Re: Certificate questions...

[EKR]

Karl Denninger <[EMAIL PROTECTED]> writes:

> On Tue, Mar 07, 2000 at 12:23:33AM +0100, Jan Meijer wrote:
> > Hi Karl,
> > 
> > Whilst taking the risk to look like someone from Microshot, Netscape or the
> > others some comment on your pleads for clarity.
> > 
> > > There are to separate things that secure web servers do.
> > > 
> > > 1.  Authenticate who you're talking to, so that when you engage in
> > > commerce you have some indication that the merchant you think you're
> > > dealing with is really who you're dealing with.
> > > 
> > > 2.  Encrypt the data so that it cannot be intercepted between the
> > > sending and receiving machines.
> > 
> > True.  Crypto allows for two other quite basic functions: non-repudiation
> > and integrity.  You only mentioned authenticity and confendiatlity.
> 
> Well, confidentiality implies integrity, in that a tampered data stream
> won't decode.  Public key crypto with a known certification on the public
> key provides non-repudiation (assuming the private key has not been
> compromised)
This is absolutely not true.

Consider a data stream enciphered with RC4. It's perfectly
easy to undetectably flip any plaintext bit by 
flipping the corresponding ciphertext bit. If you know the
plaintext, you can modify it predictably.

> The "man in the middle" risk is a red herring.  As long as the CA vouches
> for the key exchange its "cool", and you'd only detect the man in the middle
> attack if you actually LOOKED at each certificate for each page served.
> 
> How many people click on the padlock and LOOK at each page's certificate?
> Without a warning nobody checks - and as such the risk is still there.
This is incorrect. The browser has automatic checks that
the certificate matches the server's domain name. These
checks aren't perfect, but they're not useless either. 
If these checks didn't exist then it would be necessary to check
every certificate manually. That would be bad.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]]
  PureTLS - free SSLv3/TLS software for Java
http://www.rtfm.com/puretls/
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]

RE: Certificate questions...

[mads]

Karl Denninger wrote:

> However, the concept that a PERSON needs to pay upwards of 
> $100 to get a key
> by which they can have a SSL connection work from a web 
> server is insane.

If you look at the simple operation of signing a server certificate,
then sure, that does seem a bit expensive, BUT that's not all you get.
If it was, then you should just use one of the certificates that 
mod_ssl lets you generate during installation. Setting up a CA to 
issue certificates is technically rather easy - getting the legal
stuff and all the procedures in place is quite a lot more complicated
(trust me - I've been been in that business for a while).
> 
> Why are there no public CAs - much like the public keyrings for PGP?
> 
Because it wouldn't make any sense - if you don't want liability, 
authenticity checks and lots of other legal stuff, then you might as
well forget about using certificates at all - all you'd have was the
encryption.

> Why does Nutscrape and Microslug only ship with COMMERCIAL, 
> and EXPENSIVE,
> CAs loaded?

You can only guess...
I've heard someone saying that Netscape wanted more than $100K to
put their root cert in the browser - which I suppose would be a
possible explanation.
You might also ask yourself why those two browsers only support
RSA patented algorithms...


vh

Mads Toftum, QDPH
---
The brain is a wonderful organ; it starts working the moment you get up
in the morning, and does not stop until you get to work.
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]

Re: Certificate questions...

[Stefan Kelm]

Karl,

> However, the concept that a PERSON needs to pay upwards of $100 to get a key
> by which they can have a SSL connection work from a web server is insane.

It is not! It's a business model and if you're not prepared to pay those
commercial CAs - don't.

> Why are there no public CAs - much like the public keyrings for PGP?

But there are:

   http://www.pca.dfn.de/dfnpca/pki-links.html#CA

> Why does Nutscrape and Microslug only ship with COMMERCIAL, and EXPENSIVE,
> CAs loaded?

Because non-commercial CAs simply can't afford to buy themselves into
the products. It's as simple as that. We've tried and we failed.

Cheers,

Stefan.

PS: This really isn't relevant to mod-ssl.

__
Stefan KelmPGP key: "finger [EMAIL PROTECTED]" or via key server
DFN-PCA  <[EMAIL PROTECTED]>
Vogt-Koelln-Str. 30   http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)   Tel: +49 40 428 83-2262 / Fax: -2241
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]

Re: Certificate questions...

[EKR]

Karl Denninger <[EMAIL PROTECTED]> writes:
> On Mon, Mar 06, 2000 at 02:10:42PM -0800, EKR wrote:
> > The generation, no. However, in order for people sending you mail
> > to be sure that they are not subject to active key substitution
> > attacks, they key pair does need to be securely bound to the
> > recipient. Unless you're prepared to exchange keys with all of your
> > correcpondents out of band, you do need third party key certification.
> > PGP accomplishes this using key signing rather than certificates
> > per se, but it's an analagous concept.
> 
> Understood.
> 
> However, the concept that a PERSON needs to pay upwards of $100 to get a key
> by which they can have a SSL connection work from a web server is insane.
> 
> Why are there no public CAs - much like the public keyrings for PGP?
> 
> Why does Nutscrape and Microslug only ship with COMMERCIAL, and EXPENSIVE,
> CAs loaded?
I can't speak for the rationales behind MS or NSCP's policies, but
I don't think this is as simple as you make it out to be.

The issue is maintaining reference integrity for HTTPS transactions.
The client has in hand a URL of the form .
When he connects to the server, the server presents his certificate.
This certificate should have the identity "www.example.com" (in the
CN field). If it doesn't, then the browser will pop up a dialog
complaining about this. The reason for this check is (once again)
to prevent active substitution attacks whereby someone with a
legitimate certificate for a different e.g. "www.attacker.com" 
poses as the server.

In order for this procedure to work correctly, the CAs must enforce
the binding between domain name and identity in certificate. If they
don't, then active attacks are possible. Thus, any CA trusted by MS or
NSCP must agree to these rules. But enforcing them is irritating and
expensive. I don't know of any non-commercial CA who promises
to do so.

Your comparison to PGP keyservers really isn't apt. PGP
keyservers are more like LDAP directories than CAs. The provider
of the keyserver doesn't vouch for the keys, he simply serves
them. The signatures on the keys are (usually) those of individuals.

-Ekr
-- 
[Eric Rescorla   [EMAIL PROTECTED]]
  PureTLS - free SSLv3/TLS software for Java
http://www.rtfm.com/puretls/
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]

Re: Certificate questions...

[Karl Denninger]

On Tue, Mar 07, 2000 at 12:23:33AM +0100, Jan Meijer wrote:
> Hi Karl,
> 
> Whilst taking the risk to look like someone from Microshot, Netscape or the
> others some comment on your pleads for clarity.
> 
> > There are to separate things that secure web servers do.
> > 
> > 1.  Authenticate who you're talking to, so that when you engage in
> > commerce you have some indication that the merchant you think you're
> > dealing with is really who you're dealing with.
> > 
> > 2.  Encrypt the data so that it cannot be intercepted between the
> > sending and receiving machines.
> 
> True.  Crypto allows for two other quite basic functions: non-repudiation
> and integrity.  You only mentioned authenticity and confendiatlity.

Well, confidentiality implies integrity, in that a tampered data stream
won't decode.  Public key crypto with a known certification on the public
key provides non-repudiation (assuming the private key has not been
compromised)

> > These are NOT the same function, and needing one of them does not imply
> > needing the other.
> 
> True

Yep.

> > Yet, in today's world, you cannot have one without the other, which means
> > that to get EITHER you must pay someone.
> 
> The pay part is untrue.  If you really don't care about authenticity but
> only are interested in confidentiality of your datastream (if you cannot
> verify the authenticity of the entities on either side of your datastream I
> think you're quite vulnerable for loosing your confidentiality, but that's
> your choice) you can just generate your own certificate.  What is true is
> that those stupid browser applications refuse to see key generation and the
> *possible* certification as different steps.  With openssl of course this is
> possible.

Yep.

> > Contrast this with PGP for email, in which I can publish a public key and
> > once you obtain it you're able to receive an encrypted communication from
> > me and decode the traffic.  My generation of that key pair does not require
> > that it be "certified" by any third party.
> 
> I hope you made some typo here.  You do not use the thing conceptually
> referred to as "public key" to decode encrypted traffic/messages.  That's
> what the private thingie is for.  The public part is for signature
> verification (ie verifying the private part has been used to encrypt a piece
> of data).  

Well, yes and no.

If I want to send you a message I can do several things with it:

1.  I can encrypt it with your PUBLIC key.  Once I do that I cannot
recover the message.  Only YOU can recover it, by using the private
key, which in theory at least only you have.  This provides both
confidentiality and data integrity, as the message will not decode
if tampered with.  It does NOT prove that I authored the message
though.

2.  I can SIGN it with my PRIVATE key.  That is basically just taking a
hash seeded with my private key and appending same.  This provides
non-repudiation and data integrity, as the message will not verify
if tampered with, and if it DOES verify against the public key then 
you know the private key was used to sign it with certainty.

3.  I can sign the message with my private key and then encrypt it with
your public key.  NOW I have a message that has all the benefits of
(1) and (2) with one further benefit - only *YOU* can determine
the message's origin!  Without your private key the signature cannot
be read, thus, nobody but you can prove that I sent it.

Now the problem here is that if the private key in question is compromised
then you can sign messages that are from someone else (the person who's key
you have) and you can also read messages sent to someone else (the person
who's key you have).  But that SAME risk exists with certificates, in that
if I get ahold of the private key for your web server (and either break the
PEM passphrase or if you foolishly unlock it) I can now do the same thing.

> Problem with your PGP schema is that I can publish my public key on the
> keyserver (lets say the keys.pgpi.net which I trust a lot ;), you can get it
> there and use it to crypt data for me.  Essential problem here: how do you
> know that the key you're using is mine and not from someone claiming to be
> me (by entering *my* emailaddress and name during key generation)?  Using
> signatures --> signature=certificate.

Simple:

If I use a "spoofed" key you can't read the output.  

Since I have to DELIVER the message to you, if you get something
that doesn't decode, you know the sender got a "bad" public key
from somewhere and its time for you to have a discussion with the
sender and find out where they got the key from.  

The first time you get an undecodable message you know someone 
has done this.

Second, if I get your key from the PGP keyring, I can look at who
  

Re: Certificate questions...

[Karl Denninger]

Absolutely.

I wonder if the DOJ might be interested in this

--
-- 
Karl Denninger ([EMAIL PROTECTED])  Web: http://childrens-justice.org
Isn't it time we started putting KIDS first?  See the above URL for
a plan to do exactly that!


On Mon, Mar 06, 2000 at 05:29:23PM -0500, Eric Moore wrote:
> It seems there is restraint of trade since only a few 'selected' 
> companies can get on the CA root of IE and Navigator.  To pay USD 300 
> every couple of years to prove you exist is silly.  The price of domaine 
> registration is coming down, why not certs since there is more e-commerce?
> 
> In the U.S. the cert only proves you have a DUNS number, a phone number, 
> and a fax'd copy of a state registration.  Every scam artist has those.
> 
> EM
> 
> 
> Karl Denninger wrote:
> 
> >Well, I understand that, but it seems that people (including Thawte,
> >Microslug and Nutscrape) are missing the point.
> >
> >There are to separate things that secure web servers do.
> >
> >1.   Authenticate who you're talking to, so that when you engage in
> > commerce you have some indication that the merchant you think you're
> > dealing with is really who you're dealing with.
> >
> >2.   Encrypt the data so that it cannot be intercepted between the
> > sending and receiving machines.
> >
> >These are NOT the same function, and needing one of them does not imply
> >needing the other.  
> >
> >Yet, in today's world, you cannot have one without the other, which means
> >that to get EITHER you must pay someone.
> >
> >Contrast this with PGP for email, in which I can publish a public key and
> >once you obtain it you're able to receive an encrypted communication from 
> >me and decode the traffic.  My generation of that key pair does not require
> >that it be "certified" by any third party.
> 
> 
> ---
> Eric Moore
> Miami, Florida
> 
> __
> Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
> User Support Mailing List  [EMAIL PROTECTED]
> Automated List Manager[EMAIL PROTECTED]
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]

Re: Certificate questions...

[Karl Denninger]

On Mon, Mar 06, 2000 at 02:10:42PM -0800, EKR wrote:
> Karl Denninger <[EMAIL PROTECTED]> writes:
> > Well, I understand that, but it seems that people (including Thawte,
> > Microslug and Nutscrape) are missing the point.
> > 
> > There are to separate things that secure web servers do.
> > 
> > 1.  Authenticate who you're talking to, so that when you engage in
> > commerce you have some indication that the merchant you think you're
> > dealing with is really who you're dealing with.
> > 
> > 2.  Encrypt the data so that it cannot be intercepted between the
> > sending and receiving machines.
> > 
> > These are NOT the same function, and needing one of them does not imply
> > needing the other.  
> This is incorrect.
> 
> Without authentication of the merchant's identity, you're subject to
> a variety of active attacks where the attacker substitutes his
> key for the merchant's.   You can only have encryption without 
> endpoint authentication if your threat model does not include 
> active attack.
> 
> > Yet, in today's world, you cannot have one without the other, which means
> > that to get EITHER you must pay someone.
> > 
> > Contrast this with PGP for email, in which I can publish a public key and
> > once you obtain it you're able to receive an encrypted communication from 
> > me and decode the traffic.  My generation of that key pair does not require
> > that it be "certified" by any third party.
> The generation, no. However, in order for people sending you mail
> to be sure that they are not subject to active key substitution
> attacks, they key pair does need to be securely bound to the
> recipient. Unless you're prepared to exchange keys with all of your
> correcpondents out of band, you do need third party key certification.
> PGP accomplishes this using key signing rather than certificates
> per se, but it's an analagous concept.

Understood.

However, the concept that a PERSON needs to pay upwards of $100 to get a key
by which they can have a SSL connection work from a web server is insane.

Why are there no public CAs - much like the public keyrings for PGP?

Why does Nutscrape and Microslug only ship with COMMERCIAL, and EXPENSIVE,
CAs loaded?

--
-- 
Karl Denninger ([EMAIL PROTECTED])  Web: http://childrens-justice.org
Isn't it time we started putting KIDS first?  See the above URL for
a plan to do exactly that!
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]

Re: Certificate questions...

[Jan Meijer]

Hi Karl,

Whilst taking the risk to look like someone from Microshot, Netscape or the
others some comment on your pleads for clarity.

> There are to separate things that secure web servers do.
> 
> 1.  Authenticate who you're talking to, so that when you engage in
> commerce you have some indication that the merchant you think you're
> dealing with is really who you're dealing with.
> 
> 2.  Encrypt the data so that it cannot be intercepted between the
> sending and receiving machines.

True.  Crypto allows for two other quite basic functions: non-repudiation
and integrity.  You only mentioned authenticity and confendiatlity.

> These are NOT the same function, and needing one of them does not imply
> needing the other.

True

> Yet, in today's world, you cannot have one without the other, which means
> that to get EITHER you must pay someone.

The pay part is untrue.  If you really don't care about authenticity but
only are interested in confidentiality of your datastream (if you cannot
verify the authenticity of the entities on either side of your datastream I
think you're quite vulnerable for loosing your confidentiality, but that's
your choice) you can just generate your own certificate.  What is true is
that those stupid browser applications refuse to see key generation and the
*possible* certification as different steps.  With openssl of course this is
possible.

 
> Contrast this with PGP for email, in which I can publish a public key and
> once you obtain it you're able to receive an encrypted communication from
> me and decode the traffic.  My generation of that key pair does not require
> that it be "certified" by any third party.

I hope you made some typo here.  You do not use the thing conceptually
referred to as "public key" to decode encrypted traffic/messages.  That's
what the private thingie is for.  The public part is for signature
verification (ie verifying the private part has been used to encrypt a piece
of data).  

Problem with your PGP schema is that I can publish my public key on the
keyserver (lets say the keys.pgpi.net which I trust a lot ;), you can get it
there and use it to crypt data for me.  Essential problem here: how do you
know that the key you're using is mine and not from someone claiming to be
me (by entering *my* emailaddress and name during key generation)?  Using
signatures --> signature=certificate.

I agree the key generation and the certification process *should* be
seperated, also in browsers.  It is *not* possible for me to make a copy of
my oh so valuable private browser key *before* I receive my certificate
(which can be up to five days according to our certification practise
statement) which bothers me very much.  I can not revoke the certificate and
just use the same key again.  

So, concluding:
You're right in stating encryption and authentication are two seperated
things and being unable to use encryption without authentication is stupid

You're wrong in your assumption of the usefullness this has.

Jan
-- 
alive ~ true
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]

Re: Certificate questions...

[Eric Moore]

It seems there is restraint of trade since only a few 'selected' 
companies can get on the CA root of IE and Navigator.  To pay USD 300 
every couple of years to prove you exist is silly.  The price of domaine 
registration is coming down, why not certs since there is more e-commerce?

In the U.S. the cert only proves you have a DUNS number, a phone number, 
and a fax'd copy of a state registration.  Every scam artist has those.

EM


Karl Denninger wrote:

>Well, I understand that, but it seems that people (including Thawte,
>Microslug and Nutscrape) are missing the point.
>
>There are to separate things that secure web servers do.
>
>1. Authenticate who you're talking to, so that when you engage in
>   commerce you have some indication that the merchant you think you're
>   dealing with is really who you're dealing with.
>
>2. Encrypt the data so that it cannot be intercepted between the
>   sending and receiving machines.
>
>These are NOT the same function, and needing one of them does not imply
>needing the other.  
>
>Yet, in today's world, you cannot have one without the other, which means
>that to get EITHER you must pay someone.
>
>Contrast this with PGP for email, in which I can publish a public key and
>once you obtain it you're able to receive an encrypted communication from 
>me and decode the traffic.  My generation of that key pair does not require
>that it be "certified" by any third party.


---
Eric Moore
Miami, Florida

__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]

Re: Certificate questions...

[EKR]

Karl Denninger <[EMAIL PROTECTED]> writes:
> Well, I understand that, but it seems that people (including Thawte,
> Microslug and Nutscrape) are missing the point.
> 
> There are to separate things that secure web servers do.
> 
> 1.Authenticate who you're talking to, so that when you engage in
>   commerce you have some indication that the merchant you think you're
>   dealing with is really who you're dealing with.
> 
> 2.Encrypt the data so that it cannot be intercepted between the
>   sending and receiving machines.
> 
> These are NOT the same function, and needing one of them does not imply
> needing the other.  
This is incorrect.

Without authentication of the merchant's identity, you're subject to
a variety of active attacks where the attacker substitutes his
key for the merchant's. You can only have encryption without 
endpoint authentication if your threat model does not include 
active attack.

> Yet, in today's world, you cannot have one without the other, which means
> that to get EITHER you must pay someone.
> 
> Contrast this with PGP for email, in which I can publish a public key and
> once you obtain it you're able to receive an encrypted communication from 
> me and decode the traffic.  My generation of that key pair does not require
> that it be "certified" by any third party.
The generation, no. However, in order for people sending you mail
to be sure that they are not subject to active key substitution
attacks, they key pair does need to be securely bound to the
recipient. Unless you're prepared to exchange keys with all of your
correcpondents out of band, you do need third party key certification.
PGP accomplishes this using key signing rather than certificates
per se, but it's an analagous concept.

-Ekr


-- 
[Eric Rescorla   [EMAIL PROTECTED]]
  PureTLS - free SSLv3/TLS software for Java
http://www.rtfm.com/puretls/
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]

Re: Certificate questions...

[Karl Denninger]

On Mon, Mar 06, 2000 at 09:48:47AM -, Airey, John wrote:
> >-Original Message-
> >From: Karl Denninger [mailto:[EMAIL PROTECTED]]
> >Sent: 03 March 2000 15:39
> >To: [EMAIL PROTECTED]
> >Subject: Re: Certificate questions...
> 
> 
> >Hi John,
> 
> >On Fri, Mar 03, 2000 at 10:06:19AM -, Airey, John wrote:
> >> Assuming we are talking about Thawte's server test certificates, they are
> >> only for use for one month. Using them helps you to understand how to
> >> install a real certificate without running the risk of destroying it (a
> very
> >> real risk with NT!)
> 
> >Not really true.  You can set the validity up to 365 days.
> 
> Obviously Thawte have changed their policy on test certificates then. I
> haven't used one for a while but they are a useful test of their certificate
> issuing procedure without running the risk of losing money because you get
> your csr wrong.
> 
> Just to clarify, with Windows NT it is possible to install a certificate and
> private key without actually having a copy of them on disk, AFAIK (although
> it would be foolish not to keep a backup, wouldn't it?). If you need to
> reinstall NT, then you've lost them!
> 
> Like I said, if this isn't a public site you can create your own. All a
> certificate does is prove who you are, but if you are only securing data for
> internal use, you hopefully know who you are anyway.

Well, I understand that, but it seems that people (including Thawte,
Microslug and Nutscrape) are missing the point.

There are to separate things that secure web servers do.

1.  Authenticate who you're talking to, so that when you engage in
commerce you have some indication that the merchant you think you're
dealing with is really who you're dealing with.

2.  Encrypt the data so that it cannot be intercepted between the
sending and receiving machines.

These are NOT the same function, and needing one of them does not imply
needing the other.  

Yet, in today's world, you cannot have one without the other, which means
that to get EITHER you must pay someone.

Contrast this with PGP for email, in which I can publish a public key and
once you obtain it you're able to receive an encrypted communication from 
me and decode the traffic.  My generation of that key pair does not require
that it be "certified" by any third party.

--
-- 
Karl Denninger ([EMAIL PROTECTED])  Web: http://childrens-justice.org
Isn't it time we started putting KIDS first?  See the above URL for
a plan to do exactly that!
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]

RE: Certificate questions...

[Airey, John]

>-Original Message-
>From: Karl Denninger [mailto:[EMAIL PROTECTED]]
>Sent: 03 March 2000 15:39
>To: [EMAIL PROTECTED]
>Subject: Re: Certificate questions...


>Hi John,

>On Fri, Mar 03, 2000 at 10:06:19AM -, Airey, John wrote:
>> Assuming we are talking about Thawte's server test certificates, they are
>> only for use for one month. Using them helps you to understand how to
>> install a real certificate without running the risk of destroying it (a
very
>> real risk with NT!)

>Not really true.  You can set the validity up to 365 days.

Obviously Thawte have changed their policy on test certificates then. I
haven't used one for a while but they are a useful test of their certificate
issuing procedure without running the risk of losing money because you get
your csr wrong.

Just to clarify, with Windows NT it is possible to install a certificate and
private key without actually having a copy of them on disk, AFAIK (although
it would be foolish not to keep a backup, wouldn't it?). If you need to
reinstall NT, then you've lost them!

Like I said, if this isn't a public site you can create your own. All a
certificate does is prove who you are, but if you are only securing data for
internal use, you hopefully know who you are anyway.

This reminds me of a joke.

Descartes was in a restaurant having a meal. The waiter asks him "would you
like to see the wine list, Sir?". He replies "I think not" and promptly
vanishes.

(I never said it was a funny joke).

John
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]

Re: Certificate questions...

[Mike_Innes]

Karl,
 Everything you say is true, and if you install a the CA certificate into
the browser then you will have the secure connection that you want, however if
you don't have the CA cert in the browser then the server that you are talking
to may not be who you then they are, so what? - this is the opportunity for a
'man in the middle' attack.

Instead of this:
 You -> server
You may have this:
 You -> 'man in the middle' -> server

The man in the middle would make you believe that he is the server and he would
make the server believe that he is you.
Both https connections would be secure, but (here's the point) the man in the
middle would have the unencrypted data.  This is similar to a previous thread on
ADH.

On top of this, depending on your server and clients there may be more of a
headache trying to use strong encryption, if everything is 'domestic strength'
then that's not an issue.
Mikey




Karl Denninger <[EMAIL PROTECTED]> on 03/03/2000 15:39:23

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:(bcc: Mike Innes/Virgin Direct/GB)

Subject:  Re: Certificate questions...




Hi John,

On Fri, Mar 03, 2000 at 10:06:19AM -, Airey, John wrote:
> Assuming we are talking about Thawte's server test certificates, they are
> only for use for one month. Using them helps you to understand how to
> install a real certificate without running the risk of destroying it (a very
> real risk with NT!)

Not really true.  You can set the validity up to 365 days.

> They are not intended for production use. Thawte's own certificates are
> accepted by all browsers (AFAIK) and prove to those who connect to your site
> that you are the company that you say you are. This is what you pay for, and
> if you ask me it's well worth the money.
>
> If you don't intend to connect your site to the outside world, you can make
> your own certificates anyway. The documentation to do that comes with
> openssl.
>
> John

I'm NOT using SSL for ecommerce so "proving" something is worthless to me.

My entire and sole use for SSL on my web server is to ENCRYPT TRAFFIC.  That
is, I don't CARE if someone believes I am who I say I am, but I very much
care that the CONTENT is not able to be picked off in transit.

For example, I receive faxes on my systems and store them in a private,
password-secured web directory.  By ensuring that any access to that
directory or its contents requires SSL, I ensure that nobody can pick off
the traffic in transit and SEE the faxes that I may view from a remote
location.  Since I use my fax system for things that I would consider
PRIVATE, this is important to me.

In this case I know damn well that I am who I say that I am, because I'm the
one connecting to the server.  My *ONLY* use for SSL here is to PROTECT THE
DATA, *NOT* certify ownership.

Likewise, I might want to make data available to another person that I (1)
want to password protect for them, and (2) want to make CERTAIN is not
compromised in transit.  HTTPS again does the job, but again, the
"certification" of who I claim to be is IRRELAVENT to the process.

There is NO WAY under the current paradigm that I've found to do this
without popping up warnings on every browser in existence.  This is a
severe and serious shortcoming in the SSL software in those browsers,
as not *EVERYONE* is interested in using SSL for Ecommerce where the
identity of the owner of the connection is important!

As it stands I'll buy a cert from Thawte if I can jump through their hoops,
but for some people it is inherently NOT WHAT THEY WANT TO DO in passing
encrypted traffic (eg: vetting that the sender is who they say they are).

In fact, for SOME potential uses of secure communication, it is absolutely
anathema that either end be positively identifyable in this kind of fashion.

This is something that you SSL folks need to look into finding a way to
resolve - perhaps a public "CA" similar to the MIT keyring for PGP keys is
called for here - a place where you can "sign" a key but not jump through
said hoops, yet keep the silly warnings off the user's computers!

--
--
Karl Denninger ([EMAIL PROTECTED])  Web: http://childrens-justice.org
Isn't it time we started putting KIDS first?  See the above URL for
a plan to do exactly that!
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]










Internet communications are not secure. This message is confidential to the intended 
addressee. Any copying or distribution of it by anyone without the ad

Re: Certificate questions...

[Karl Denninger]

Hi John,

On Fri, Mar 03, 2000 at 10:06:19AM -, Airey, John wrote:
> Assuming we are talking about Thawte's server test certificates, they are
> only for use for one month. Using them helps you to understand how to
> install a real certificate without running the risk of destroying it (a very
> real risk with NT!)

Not really true.  You can set the validity up to 365 days.

> They are not intended for production use. Thawte's own certificates are
> accepted by all browsers (AFAIK) and prove to those who connect to your site
> that you are the company that you say you are. This is what you pay for, and
> if you ask me it's well worth the money.
> 
> If you don't intend to connect your site to the outside world, you can make
> your own certificates anyway. The documentation to do that comes with
> openssl.
> 
> John

I'm NOT using SSL for ecommerce so "proving" something is worthless to me.

My entire and sole use for SSL on my web server is to ENCRYPT TRAFFIC.  That
is, I don't CARE if someone believes I am who I say I am, but I very much
care that the CONTENT is not able to be picked off in transit.

For example, I receive faxes on my systems and store them in a private,
password-secured web directory.  By ensuring that any access to that
directory or its contents requires SSL, I ensure that nobody can pick off
the traffic in transit and SEE the faxes that I may view from a remote
location.  Since I use my fax system for things that I would consider
PRIVATE, this is important to me.

In this case I know damn well that I am who I say that I am, because I'm the
one connecting to the server.  My *ONLY* use for SSL here is to PROTECT THE
DATA, *NOT* certify ownership.

Likewise, I might want to make data available to another person that I (1)
want to password protect for them, and (2) want to make CERTAIN is not
compromised in transit.  HTTPS again does the job, but again, the
"certification" of who I claim to be is IRRELAVENT to the process.

There is NO WAY under the current paradigm that I've found to do this
without popping up warnings on every browser in existence.  This is a 
severe and serious shortcoming in the SSL software in those browsers,
as not *EVERYONE* is interested in using SSL for Ecommerce where the
identity of the owner of the connection is important!

As it stands I'll buy a cert from Thawte if I can jump through their hoops,
but for some people it is inherently NOT WHAT THEY WANT TO DO in passing
encrypted traffic (eg: vetting that the sender is who they say they are).

In fact, for SOME potential uses of secure communication, it is absolutely
anathema that either end be positively identifyable in this kind of fashion.

This is something that you SSL folks need to look into finding a way to
resolve - perhaps a public "CA" similar to the MIT keyring for PGP keys is
called for here - a place where you can "sign" a key but not jump through
said hoops, yet keep the silly warnings off the user's computers!

--
-- 
Karl Denninger ([EMAIL PROTECTED])  Web: http://childrens-justice.org
Isn't it time we started putting KIDS first?  See the above URL for
a plan to do exactly that!
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]

Re: Certificate questions...

[Karl Denninger]

On Fri, Mar 03, 2000 at 09:31:58AM +, [EMAIL PROTECTED] wrote:
> Alex,,
>  The trouble with using self signed certs is that you need to install the CA
> cert in the browser to stop messages popping up when you connect to the site -
> obviously no real problem as you will either be using them for testing or in a
> closed environment (or limited number of clients).  Using the 'Free Test
> Certificates' from thawte is a little better as the CA cert that they use to
> sign the CSR is already installed in Netscape (only 4.7x?).
> 
> Karl,
>  To avoid this problem 'buy a cert' or install the CA cert into each browser
> (have a look at pkg.contrib/loadcacert.cgi)
> 
> Mikey

That would be nice EXCEPT that Thawte and most of the others won't SELL a
cert to an indivdual except under "extraordinary circumstances".

--
-- 
Karl Denninger ([EMAIL PROTECTED])  Web: http://childrens-justice.org
Isn't it time we started putting KIDS first?  See the above URL for
a plan to do exactly that!

__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]

Re: Certificate questions...

[Brian Johnson]

[EMAIL PROTECTED] wrote:

> Alex,,
>  The trouble with using self signed certs is that you need to install the CA
> cert in the browser to stop messages popping up when you connect to the site -
> obviously no real problem as you will either be using them for testing or in a
> closed environment (or limited number of clients).  Using the 'Free Test
> Certificates' from thawte is a little better as the CA cert that they use to
> sign the CSR is already installed in Netscape (only 4.7x?).

are there any security benifits in buying a cert over making my own test certificate 
if I only have a few clients that will be accessing the site?  This site will be 
accessed by very few people, but security is quite importaint..
Thanks
-Brian

__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]

RE: Certificate questions...

[Airey, John]

Assuming we are talking about Thawte's server test certificates, they are
only for use for one month. Using them helps you to understand how to
install a real certificate without running the risk of destroying it (a very
real risk with NT!)

They are not intended for production use. Thawte's own certificates are
accepted by all browsers (AFAIK) and prove to those who connect to your site
that you are the company that you say you are. This is what you pay for, and
if you ask me it's well worth the money.

If you don't intend to connect your site to the outside world, you can make
your own certificates anyway. The documentation to do that comes with
openssl.

John

-Original Message-
From: Alex C. Koch [mailto:[EMAIL PROTECTED]]
Sent: 02 March 2000 19:12
To: [EMAIL PROTECTED]
Subject: Re: Certificate questions...


Is getting one of these test certificate better than using a self signed 
test certificate that can be generated with openSSL?  I am currently using 
a certificate that I generated myself.  What would the advantages be of 
using a certificate from Thawte when it is not authenticated by them?


At 11:42 AM 3/2/00 -0600, you wrote:
>Hi folks,
>
>I have built the MODSSL package and Apache, and it works.  I got a
>"test" certificate from Thawte (their "unauthenticated" one) and it
>installed and worked properly.


Alex Koch
[EMAIL PROTECTED]
https://128.253.163.111 (SSL secured)
http://home.adelphia.net/~alexk

<<-- PGP Keys -->>
2048 bit RSA key id: 0x58635D8F
4096 bit DH/DSS key id: 0x0784EFC5


__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]
__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]

Re: Certificate questions...

[Mike_Innes]

Alex,,
 The trouble with using self signed certs is that you need to install the CA
cert in the browser to stop messages popping up when you connect to the site -
obviously no real problem as you will either be using them for testing or in a
closed environment (or limited number of clients).  Using the 'Free Test
Certificates' from thawte is a little better as the CA cert that they use to
sign the CSR is already installed in Netscape (only 4.7x?).

Karl,
 To avoid this problem 'buy a cert' or install the CA cert into each browser
(have a look at pkg.contrib/loadcacert.cgi)

Mikey




"Alex C. Koch" <[EMAIL PROTECTED]> on 02/03/2000 19:11:58

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:(bcc: Mike Innes/Virgin Direct/GB)

Subject:  Re: Certificate questions...




Is getting one of these test certificate better than using a self signed
test certificate that can be generated with openSSL?  I am currently using
a certificate that I generated myself.  What would the advantages be of
using a certificate from Thawte when it is not authenticated by them?


At 11:42 AM 3/2/00 -0600, you wrote:
>Hi folks,
>
>I have built the MODSSL package and Apache, and it works.  I got a
>"test" certificate from Thawte (their "unauthenticated" one) and it
>installed and worked properly.


Alex Koch
[EMAIL PROTECTED]
https://128.253.163.111 (SSL secured)
http://home.adelphia.net/~alexk

<<-- PGP Keys -->>
2048 bit RSA key id: 0x58635D8F
4096 bit DH/DSS key id: 0x0784EFC5


__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]










Internet communications are not secure. This message is confidential to the intended 
addressee. Any copying or distribution of it by anyone without the addressee's consent 
may be unlawful. If you are not the intended addressee, please inform us immediately 
and then delete this message. 

Virgin Direct Personal Financial Service Ltd is regulated by the Personal Investment 
Authority for life insurance, pension and unit trust business and represents only the 
Virgin Direct marketing group. Registered office: Discovery House, Whiting Road, 
Norwich NR4 6EJ, UK. Registered in England No. 3072766.

The Virgin One account is a secured personal bank account with The Royal Bank of 
Scotland plc. It is provided by Virgin Direct Personal Finance Ltd which is a 
representative only of Virgin Direct Personal Financial Service Ltd. Registered 
office: Waterhouse Square, 138-142 Holborn, London EC1N 2TH, UK. Registered in England 
no 3414708.

The Virgin Deposit Account is a personal deposit account with The Royal Bank of 
Scotland plc administered by Virgin Direct Personal Financial Service Ltd.


__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]

Re: Certificate questions...

[Alex C. Koch]

Is getting one of these test certificate better than using a self signed 
test certificate that can be generated with openSSL?  I am currently using 
a certificate that I generated myself.  What would the advantages be of 
using a certificate from Thawte when it is not authenticated by them?


At 11:42 AM 3/2/00 -0600, you wrote:
>Hi folks,
>
>I have built the MODSSL package and Apache, and it works.  I got a
>"test" certificate from Thawte (their "unauthenticated" one) and it
>installed and worked properly.


Alex Koch
[EMAIL PROTECTED]
https://128.253.163.111 (SSL secured)
http://home.adelphia.net/~alexk

<<-- PGP Keys -->>
2048 bit RSA key id: 0x58635D8F
4096 bit DH/DSS key id: 0x0784EFC5


__
Apache Interface to OpenSSL (mod_ssl)   www.modssl.org
User Support Mailing List  [EMAIL PROTECTED]
Automated List Manager[EMAIL PROTECTED]