[thelist] Secure Site Expiration

[Steve Lewis]

Belinda Johnson wrote:

>>From their company:
>
[...]

>Again, I'm not sure what the people below are talking about but, the above
>information is how site security works.  I would be more than happy to
>conduct a class for the "major techies" on how this all works.  SMS seems to
>think I know what I'm talking about, after all, I teach the e-commerce /
>e-business class there.
>

Blah blah blah, internal server security.... you have just had smoke
blown in your face.  The person who composed this reply is not being
very helpfull, or very professional.

He prattles on about ASP and sessions and certificates not proving
anything... byt the only thing you care about is the fact that IP is not
an encrypted protocol, and that a web browser will transmit credit card
name, type, number and expiration date in the clear.  The first concern,
then is that someone may intercept (or "snoop" or "evesdrop" on) the
transmission between browser and server, and collect that data.  Until a
secure connection is established between a web browser and the web
server, there is no justification for anyone to presume that my little
brother is not going to go on a shopping spree with their credit card.

A certificate means that Verisign thinks you are talking to the correct
people.  It does nothing more than that, he is correct.*  Then you have
to address the issue of encryption, now that you have established the
identity of the server.  That is traditionally done using SSL through
HTTPS.  I will now paste in the *one* important piece of information in
his post now:

<snip>
You and I had spoken last week about purchasing a site certificate for the
Sharp Signs web site to give a sense of confidence to the customer that
their data is secure.  We are in the process of doing this but, Verisign
still needs to contact you regarding the authenticity of the information
within your incorporation document that was faxed to us.

As soon as they verify this, and generate the corresponding certificate key,
we will install it and make the changes to the site to use HTTPS as the
protocol.
</snip>

This tells us something we didn't know before:  they do not intend to
use their own domain name, and an appropriate certificate, to establish
identity of the server. They intend to have the certificate generated in
the name of your business. Thus you need to hold some people's hands and
coax them into helping with the generation of this certificate done fast.

1) get an email with a tracking number, case number, or SOME specific
evidence to his prior communications with Verisign so that you may
facilitate the generation of the certificate.

2) contact Verisign by telephone (expect a wait) and speak with someone
there about what needs to be done next.  They will request that your
organization fax business incorporation documentation (or similar proof
of your right to 'own' your domain name) to them.

3) knock on some doors there at work to make sure this gets done.

NOTES:

* the following may help explain the difference between the two
requisite tasks involved: authenticating identity and encrypting data.
 This has been shamelessly stolen from Verisign's Website, so please
excuse their corporate branding.
 [ http://www.verisign.com/products/site/faq/40-bit.html ]

What is the relationship between Public Keys and Certificates?
In Public Key Cryptography, if Alice wants to send a secret message to
Bob, she must obtain a copy of his public key. Before doing so, however,
she needs to make sure that the public key really belongs to Bob.

Certificates (also called Digital IDs) address this problem. A
certificate is an electronic document that binds a public key to a
particular individual or organization. Certificates are issued by a
trusted third party, called a Certification Authority (CA). Before
issuing a certificate, a good CA will go though a series of
authentication procedures to make sure that Bob is who he claims to be,
and that the public key in the certificate really belongs to Bob.

Your Server ID will contain the following information:
Your organization's common name (e.g. www.verisign.com)
Additional identifying information (e.g. IP and physical address)
Your public key
Expiration date of the public key
Name of the CA that issued the ID (i.e. VeriSign)
A unique serial number
The certificate is then encrypted (signed) with the CA's private key.
Thus, if the end users trust the CA, and have the CAs public key, they
can be assured of the certificate's legitimacy.