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
has vouched for you (signed your key). If there's nothing there I
might get a bit suspicious. If someone else who I know has signed
your key, and their footprint matches, I can be pretty sure its you.
> 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.
Well, in fact you can with Apache+modssl. In fact, the private key and CRT
files are separate, and the private key file is not destroyed when used.
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.
--
--
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]
