Привет!
>> Chris Shiflett wrote:
> it is very misleading and would indicate that I
> have very little knowledge about PKI systems,
Come on, nobody here would ever think of that. Especially since most of
us (put me as first one in the list) should know much more about PKI
ourselves before judging anybody's knowledge :) Which is why we keep
making questions that sometimes may be pretty absurd.
> I was trying to point out
> how insecure this model would be if encryption were all that SSL
> provided and the only trust involved was the trust of a domain name.
Yes, I've got it now.
> No government, as far as I know, can break the public key cryptography
> currently being used by most SSL-enabled sites (using the strong
> security - 128 bit certificates). This includes the United States.
I was saying this because I remember (maaany years ago, when the whole
PGP thing started) reading some fire exchanges about RSA keys and the
way the encrypting chips were going to be "friendly" to american eyes.
Honestly, at that time I was not that interested to the issue and I just
gave it a quick read, which left me with a wrong opinion.
> Now, SSL only encrypts your communication in transit, of course. I'm
> sure your local government could find a way to make the entity you are
> communicating with release the information in the communication to them.
> This is, of course, outside the scope of SSL.
And outside the scope of my worries :) I am responsible for the software
I deliver, whatever happens out of it is none of my bag :)
> However, it is adequate to know that one key is used to do the
> encrypting, while the other is used for the decrypting. These are
> generally referred to as public and private keys, because one is made
> available to the public while the other is kept safely stored (in the
> case of Web browsers, it is stored in the certificate repository of the
> browser).
Yes, glad that I did use PGP sometimes :) this part is clear :) So
Verisign is actually just "signing" the key as I did on PGP and that
means anyone trusting me can trust you if they receive a message signed
with your key, because when evaluating the message they will now it';s
been signed by a key that I would trust myself. Right? Man, I don't even
wanna imagine where and how Verisign password is kept LOLOL
> Digital certificates solve this problem. A digital certificate, as RSA
> describes it, is a document that says:
>
> "I guarantee that this particular public key is associated with this
> particular user; Trust me!"
So actually, when you spend your $200 what happens is:
1) Verisign (or whoever) starts a process to control they really wanna
play with you (and this has nothing to do with IT or SSL, they will
have their own policies)
2) Verisign (or whoever) starts a process to control your public key
and possibly something else in your system
3) If the above has a positive answer they just sign your kay and hand
it over to you. So there is no need for a central db. Trust is *in*
the key and need not be searched for. The only thing to do is to
verify that the trusting key has not been revoked.
That is, if it works like PGP. But this is probably too easy, as this
way they would have no way to revoke my key without invalidating all
keys on this planet. So this is a simplification. But just tell me if I
got the basic message.
> So, assuming for the moment that we trust the certificate, we can assume
> that a particular public key belongs to a particular user. For example,
> you can be guaranteed that a public key belongs to me (Chris Shiflett)
> and thus, only Chris Shiflett will be able to decrypt the communication.
> If someone is trying to pose as me, you may send them encrypted
> communication, but they won't be able to decrypt it.
Yes, because they have stolen the public key and could crypt the
question but since they have not the private key they cannot open the
answer.
> Well, I disagree that this has nothing to do with the SSL protocol
> itself. Identification is a very important part of enabling secure
> transactions to take place over the Web. Without this, there would be no
> "ecommerce" as it has been dubbed.
...
> Of course, as users of Web browsers such as Netscape and Internet
> Explorer, we have to trust AOL/Time Warner and Microsoft, respectively,
> (yeah, scary thought) to only trust CAs that have high integrity,
> security, etc. An extensive C&A (Certification and Accredidation)
> process is used to make this guarantee.
Yes, but this is the part I doubt. When I buy a certificate from Kiev,
how on earth those guys sitting in Washington are to know who I am and
what I do for a living? They will have to handle the job to someone
else. This layering of delegations will include banks and governmental
stuff, and there is no such thing as a government that will not accept
bribery.
Chris, what me and Richard doubt is *NOT* the tech factor. That part is
okay. But is a man taking the final decision as whether to sign the
certificate or not. And everybody is for sale on this planet. Everybody.
It just depends on the price you can pay. You are going to kill your own
mother if I put 100 billion dollars on the table. You are, as I am and
anybody is. It's easy to moral while the bucks are in the realm of
examples, but once they are phisically on the table everybody is for
sale. At least, that's my own life experience.
What we *do not* believe (correct me Richard if I misunderstood you) is
that Verisign (or whoever in their place) will actually do more than
verifying that www.goodguys.org is really existing and it's there. And
this is just a protection against hackers but has nothing to with
consumer's privacy or security. People at goodguys.org will not be
checked anyway as far as they behaviour as a company is concerbed (that
would cost *much* more than $200 and it would be way to easy for the
crooks to buy themselves a virginity by doubling the money).
Which is why I still like better to transfer all credit card processing
to banks and have my sites saying that "WE DO NOT PROCESS CREDIT CARDS
AT ALL". When they want to pay they see a bank logo and domain, not
mine. And if anything goes wrong it will be a bank problem, not mine.
But certifying is now clear. And that means that I can use the trust
chain in order to allow secure communications myself. When all I need is
protection from intrusions this will be just perfect. And yes, I can
have my customers pay $200 for that. It looks good and it also *is* good.
>
>> Now, there's a question regarding point 4). What if someone from
>> www.goodguys.com
>> gets the certified key pair and hands it over to some crook outside
>> the company? I hope this is not just as easy as it sounds (the key
>> pairs will probably check something in the environment before starting
>> to shout "YEAAAH!! IT'S MEEE!!!") but still...
>
> This would be a scary thought. Luckily it's not possible. A key pair is
> unique per Web server, right? Well, recall that the digital certificate
> only guarantees that a certain public key belong to a certain entity (in
> this case, a Web server).
There is a post saying the just transfered the keys. How? Maybe they
just signed the new keys with the old ones? This is even *more* scary.
But it can't be. The planet would be full of replicant keys. So what?
> So, for your above scenario to work, the crook outside the company would
> have to be handed the actual Web server software as it is currently
> compiled (for example, hand him the whole physical server) to be able to
> use that digital certificate. In addition to this, the crook would also
> need to trick someone's computer into resolving the domain name to be
> *his* IP address rather than the real one.
Copy the stlen keys to the new server, do a small virus that will write
the host table for a few hours a day and then restore it on any win32
machine and you have done that. No problems. And since you could copy
the keys you will have no trouble in stealing away a full copy of the
site. You might not get the data as usually they have different admins
and this would require a bit too risky an intrusion (two people knowing
you is way too much) but you can just redirect users to get the real
output while you get the input as man-in-the-middle.
It's the keys that worry me, host table is just one click away on 99,99%
of customers machines. Again, I am talking security on internal
communications, not really ecommerce, as banks do ecommerce much better
than I will be ever be able to do myself.
> In practice, however, not only is this extremely
> hypothetical, but the people at www.goodguys.com would surely have found
> out about this (their Web site is gone, all of a sudden)
Not if you use the host table on the client machine and do it as a
man-in-the-middle. www.goodguys.com would not see anything at all (apart
from users complaints about slow performance). I am afraid the only way
is to revoke old keys and generate a new pair at short random intervals.
To make sure no one can use stolen keys. Again, this is for internal
communications, not for the Verisign thingy. Am I right?
But still... current communications would be still going on, because
they use the key that was generated on the fly with the old pair. Or
not? If it's so you could close the attack window by regenerating the
key pair at *any* new session. Right?
пока
Альберто
Киев
--
@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@-_=}{=_-@
LoRd, CaN yOu HeAr Me, LiKe I'm HeArInG yOu?
lOrD i'M sHiNiNg...
YoU kNoW I AlMoSt LoSt My MiNd, BuT nOw I'm HoMe AnD fReE
tHe TeSt, YeS iT iS
ThE tEsT, yEs It Is
tHe TeSt, YeS iT iS
ThE tEsT, yEs It Is.......
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
