I just explained this all in great detail, so please read that. I don't
just think you are confused; I am positive you are.
However, I did notice that you are the same person who gives many good
answers to other peoples' questions. This giving of your time to be
helpful is commendable, and I apologize for mistaking you for a troll. I
just honestly don't understand the confusion.
I'll only correct a couple of points that you seem to keep bringing up
that are incorrect. I believe these might be the root of all confusion.
Richard Lynch wrote:
>Work with me here, okay?
>I steal his SSL certificate.
>I steal his domain name.
>I put them on my own web-server.
>When/how do the C&A people catch this?
In public key cryptography, it is the *keys*, not the digital
certificate that encrypt/decrypt the communication.
In your example above, how do you propose stealing "his" private key? It
is in his Web server, right? You have his digital certificate, but that
only guarantees that his pulic key is associated with his domain name.
Even if you can "steal" his domain name and somehow get traffic going to
you, you can't decrypt the communication without the private key. This
is why I tried to explain the necessity of generating the request for a
digital certificate from the Web server that it will be installed on. If
you steal his entire server as well and he doesn't report it to the CA
that issued his certificate, he may as well let you run your rogue site
off of his server; it's the same difference.
Think of it this way. Let's use https://www.amazon.com/ as an example.
Do you trust doing business with them? I sure do; at least I trust 100%
that my HTTP requests are going to get to the www.amazon.com server
safely. If someone stole their SSL certificate:
1. They wouldn't be able to install it on any other Web server anyway
(your item 3 above is invalid)
2. It only guarantees that Amazon's public key really belongs to
www.amazon.com - we knew that already
So, you've done nothing.
Now, on to "stealing" their domain name. All of a sudden, Amazon is
getting no traffic. Think they won't notice? Think it matters since the
HTTP requests you'll be receiving can't be decrypted by you anyway?
>If I *really* trust the person who owns a domain name, they are going to
>take care of any hijack/theft just as quickly with an unsigned cert as they
>are with a signed cert. I don't trust the C&A people to facilitate that
>process any faster or better than somebody I actually *DO* trust in the
>first place -- The person I personally know who owns that domain name who is
>going to make damn sure they catch and rectify any hijacking with or without
>a signed Cert as fast as possible. I trust that person because I know them,
>not the C&A people I don't know personally, and who have *PROVEN* themselves
>untrustworthy. I trust people, not corporations, not technology, and
>*CERTAINLY* not the C&A Signers.
This is the other major misunderstanding. How is your friend supposed to
"take care of any hijack/theft" exactly? If someone "hijacks" all of his
traffic, sure, he might notice a lack of traffic. However, what if only
a small audience is targetted? A few people mistakenly go to the wrong
www.friend.org site and do business. If there was no SSL warning letting
them know that something was wrong, they would happily do business.
Your friend may be the best Web surfer in the world, but I doubt he can
keep up with every Web site on the Web at all times to make sure that no
one else is impersonating him. He has to rely on the technology, and
that technology is SSL.
That's all for me. I'm going to start charging you for more information
about SSL. :) I still strongly suggest you read a book. I even suggested
a single 50 page chapter that will probably clarify everything for you.
You seem to think you have a grasp about what is going on, but I can
assure you that you don't.
I don't know how much clearer I can get. I've got other work to do.
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php