Alberto Serra wrote:

> Привет! 

I've always wondered what this is exactly. I'm going to assume it's a 
friendly greeting. :)

> Chris Shiflett wrote:
>> Richard,
>>> Do you really believe that for $200 (or $119, or $500) that they 
>>> "proven"
>>> themselves trustworthy?
> LOL no, I don't. As a matter of fact crooks usually have more money in 
> their pockets than honest people do, so it's highly possible that a 
> crook will pay the money while the innocent will save his last cent :)) 

Please watch the attribution here. I never posed that question (Do you 
really believe ...), as it is very misleading and would indicate that I 
have very little knowledge about PKI systems, which is not the case. I 
know that the purchase of a certificate from a trusted Certificate 
Authority is a very important part of the security that SSL provides, 
and I would not pose a rhetorical question in a weak attempt at 
trivializing this.

>> Now you've changed from "secure" to "secure from snooping." Notice 
>> the difference? It is significant. Like I said before, encrypting the 
>> transmission is useless by itself. To put it plainly:
>> encryption != security
>> What if you trust your friend who owns, and you want to 
>> do business with him? Maybe you visit his site and enter a credit 
>> card number somewhere. Thankfully, you notice that the lock icon is 
>> showing, and that he is using SSL. With this warped idea of SSL where 
>> encryption is all that counts, what if you find out that you're not 
>> really on You're really at, and he 
>> has a virtual domain setup for Also, he generated his 
>> own certificate for using his own CA (good thing there 
>> was not C&A process to undergo). So you have now sent the evil 
>> criminal your credit card number because you trusted his domain name. 
>> Good thing it's secure, right?
> So, let's see if I got you right:
>   1) SSL just says we our packets are difficult to open, that is,
>      they are encrypted. Nothing more 

NO! :)

That's what some other guy was trying to say. He is wrong.

SSL does much more than encrypt the communication. Part of my response 
was a bit satirical in a weak attempt at pointing out how ridiculous a 
notion this is. I guess it didn't help very much. :)

Note the use of the phrase, "With this warped idea of SSL where 
encryption is all that counts...."

I apologize for adding to the confusion there. 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.

>   2) Our packets are difficult to open but they are totally open
>      to Uncle Sam's control software, as the RSA thingy cannot
>      shield them from "governmental inspection", which makes sense
>      if you are writing software for an american citizen but
>      it's pretty annoying if your customer is from somewhere else.

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.

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.

>   3) A key is nothing more than a negotiation token, a mere building
>      brick that is used to fire the process.

A key, when spoken of as one entity, is a key pair. It contains both the 
public and private keys. The use of these in cryptography is called 
asymmetric cryptography. To understand asymmetric cryptography, it is 
helpful to first explain what symmetric cryptography is.

Symmetric cryptography is basically the use of a single key for the 
encryption and decryption. Most two-way encryption algorithms you are 
probably familiar with use this approach. For two people to effectively 
encrypt their communication with this approach, it is necessary for both 
parties to have the same key. To submit this key over the Internet would 
be a poor idea, because it could be intercepted, right? Ironically, most 
keys for use with symmetric cryptography are distributed over the 
Internet using asymmetric crptography. :) Others use some sort of 
physical transfer, like meeting each other on a dark street corner with 
a briefcase. :)

The problem with trying to use this type of approach to encrypt 
communication between a Web client and a Web server is pretty clear. If 
your customers can be anyone, then anyone must have access to the key. 
Thus, all of your customers would be able to decrypt communication from 
all of your other customers. Otherwise, if each client's communication 
was encrypted using a different key, you would have to have a separate 
key for each client, *plus* you would have to have a secure way to 
receive these keys on the initial transaction in a timely manner. This 
poses a real challenge.

The solution is asymmetric cryptography (public key cryptography). With 
this approach, each party has a key pair. The cryptography is quite 
advanced, and I've only begun to comprehend the generation of the keys 
myself. 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 

To see how this helps solve the problem of securing Web transactions, 
remember that both the Web client and the Web server possess a key pair. 
Thus, we have four keys:

1. Web server's public key
2. Web server's private key
3. Web client's public key
4. Web client's private key

Items 1 and 3 are exchanged in the initial SSL handshake. This takes 
place prior to the HTTP request being transmitted. Because information 
encrypted with the public key can only be decrypted with the 
corresponding private key, the basic exchange works like this:

1. All HTTP requests are encrypted with item 1, so that only item 2 can 
be used to decrypt them.
2. All HTTP responses are encrypted with item 3, so that only item 4 can 
be used to decrypt them.

With this method, the only entity that can decrypt the HTTP request is 
the Web server receiving the request, and the only entity that can 
decrypt the HTTP response is the Web client that sent the original request.

This overview only covers how the cryptography is made secure. Remember, 
PKI provides the following assurances:

1. Identification
2. Authentication
3. Authorization
4. Integrity
5. Confidentiality
6. Non-repudiation

So, we have effectively only described how item 5 is achieved.

I do not have the time to explain each of these items in as much detail, 
but the most important topic of the things left is item 1, 
identification, which is alluded to in your next question.

>   4) the "trust" you buy is something like a fixed IP number, that is
>      the guys in the major do certify that you *are* who you pretend
>      to be.

The trust I spoke of in my earlier response dealt with identification. 
If you cannot guarantee the identity of the entity with which you are 
communicating (whether the communication is encrypted or not), then your 
communication is very insecure.

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, 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.

>   5) If the one I am pretending to be is a criminal, being trusted by
>      Verisign (or whoever in their place) won't make any difference.
>      Their "license" just means that you are really dealing with those
>      you think you are dealing with and that they do bear legal
>      responsibility for whatever will happen in the transaction.
>      Again, legal action will eventually have different
>      results depending on where the trusted company is based, since
>      not all countries have the same normative set. But that has
>      nothing to do with the SSL protocol in itself. 

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.

The role companies like VeriSign play goes back to the assumption we 
made above, where we assumed the digital certificate to be trustworthy. 
Since a digital certificate guarantees us that a specific person is 
associated with a specific public key, we must trust this certificate in 
order to trust the association. In the case of HTTP transactions, the 
entity that needs to trust the (SSL) certificate is the browser. 
Browsers come with a whole group of Root certificates that are trusted 
by default, and any digital certificate issued by these CAs are thus 
trusted. Any certificate issued by a trusted CA is going to claim 
something like the following:

"I guarantee that this particular public key is associated with this 
particular domain name; Trust me!"

So, when our browser communicates with, it uses this 
guarantee to make sure that only the *real* can decrypt the 
communication. If someone at tries to impersonate, this guarantees us that they will not be able to encrypt 
the communication.

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.

> Now, there's a question regarding point 4). What if someone from 
> 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). In order to make this association in the 
first, a request for an SSL certificate must be created by the Web 
server intended to be used to service that particular domain name, and 
adequate proof that you are the rightful owner of the domain name is 
also required. Without this, the CA wouldn't know which public key was 
*definitely* yours, so it couldn't, in good faith, create the digital 

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. With all of these things in 
place, the browser connecting to the crook's site with SSL would not 
issue a warning. In practice, however, not only is this extremely 
hypothetical, but the people at would surely have found 
out about this (their Web site is gone, all of a sudden) and notified 
the CA. The digital certificate would be revoked, so it would no longer 
be valid.

Why does revoking it do any good? Remember, there is a chain of trust. 
To trust a digital certificate requires that you trust the CA from which 
it was generated. When done with software rather than people, a check is 
made with the CA to make sure this certificate is still valid.

> As for point 2), please get me right. I have my own political opinions 
> as anybody
> else, but my concern here is a professional one, since my customers 
> are 99%
> not americans. Small-mid sized companies (including mine) usually do 
> not give a
> damn about having their messages read by american eyes (we are simply 
> not worth the trouble of looking in our archives) but large companies 
> and Govt. organizations are *much* less indifferent to the subject, 
> and I guess it's understandable, they want their privacy to be for real.

I understand the concern. However, like I said, regardless of political 
policies, you can be assured that the communication cannot be decrypted, 
tampered with, etc. Political entities could put pressure on the 
recipient of the communication to reveal it, but that is all. Of course, 
the US government may have figured out how to break 128 bit public key 
cryptography, but I seriously doubt it.

This just skims the surface on PKI and SSL. I hope it at least clarifies 
a few things, because there was a lot of misinformation being thrown 
around earlier.

Happy hacking.


PHP General Mailing List (
To unsubscribe, visit:

Reply via email to