[thelist] Secure Site Expiration

Scott Dexter sgd at ti3.com
Mon May 6 17:26:00 CDT 2002

eek. I just caught onto this thread and need to say a couple things:

> First, a server certificate creates a circular
> authentication.  The web site is requested by a browser.
> Next, the browser determines if a certificate exists.  Note
> that it does not have to be a verisign certificate, it can be
> a certificate that is self generated by the site. Once the
> browser determines that a certificate exists, the authority
> for that certificate is contacted to see if the certificate
> is valid. In the case of verisign, their database is
> contacted to determine if the certificate is in fact assigned

Nope. Wrong. Sorry.

The way it works:

Your browser has a few pre-installed public keys (Verisign, Thawte are a
couple). These keys are used to help establish a secure session on the
server by:

Browser initiates session by requesting on the secure port (https uses
port 443, not port 80), and the server uses its private key certificate
(which contains identification information) to shake hands with your
browser and its (pre) installed public key. This negotiation results in
a private key pairing that's used for the remainder of the session
(symmetric key encryption) between your browser and the server ONLY.
Nobody else can read the data. Verisign is NOT contacted. If the site
has its own private key certificate installed, the ONLY way you'd be
able to use it would be if you at some point downloaded and installed
its corresponding public key.

I point at http://www.howstuffworks.com/encryption1.htm as a start, and

* http://support.microsoft.com/default.aspx?scid=kb;EN-US;q245152 and

* http://www.netscape.com/security/techbriefs/ssl.html

for further reading.

> to that specific IP address AND that specific web address
> (URL).  If it is valid then the rest of the processing is
> completed.  NOTE that nothing here encrypts or does anything
> with the data.  THAT'S THE WAY IT WORKS.

Once the symmetric key session is set up, ALL data is encrypted.

> Now, encrypted data is a function of the web server software,
> like apache or IIS from Microsoft.  How it is encrypted can
> take many forms but the most common is to use HTTPS as the
> protocol.  This is NOT the only way encryption takes place.
> As a matter of fact, it is the very LEAST secure of all the protocols.

A function how? --SSL (via https) is a configurable function (installing
the certs, setting up the sites for it, etc), but encrypting the data as
it sit on disk is something the developer has to do, outside of the web
server software. Ask for an enumeration here of the protocols. HTTPS is
the only one that your browser is going to use.

What's the most secure, in this person's opinion?

> protocol.  Note that the Sharp Signs web site and database is
> protected behind several fire walls which prevent hacking.
> Using Microsoft's ASP protocol, data is collected and sent
> back to the "secure server" at Country Bunny.

a) unless the data is encrypted during transit, you could put 500
firewalls in place and still have the data read by someone while in
transit. Firewalls help prevent attack to the servers, but the data in
transit is naked without SSL.

b) ASP isn't a protocol. And s/he's a *teacher* ??

c) In the process of going from Country Bunny<->Sharp Signs, does the
server name change? If not, you can lean on the certificate for Country
Bunny. For example: https://www.countrybunny.com/ and
https://www.countrybunny.com/SharpSigns/ will both use the same
certificate, whereas https://www.countrybunny.com/ and
https://www.sharpsigns.com/ will not. SSL certs are tied to the fully
qualified domain name (and a single ip address).

d) How exactly is the data sent back and forth to the servers? --Is that
path encrypted? How?

> A little about ASP.  ASP uses a technology called "sessions".

It doesn't have to; it's a feature.

>  Sessions cannot be duplicated by a hacker.  Sessions are a
> combination of the server address, the time of day, the
> browsers id and several other indicators that are ONLY
> available for the moment in time that the screen is created.

No. Sessions are based on a 32 byte GUID that's unique per CLIENT IP
address, and used as a lookup on the server and stored in a
(non-persisted) cookie to the client with each request. The ASPSESSID
cookie remains constant through the browser's session, and idle timeouts
are tracked on the server (garbage collection).

> The data and the screen do NOT exist either on the server OR
> on the browser other than in the browsers temporary memory.


> ASP is a complex protocol and paired with "sessions" is very secure.

Again, ASP isn't a protocol, and the storage of sessions, being server
side, is fairly isolated, but I wouldn't call it "secure" because the
developer can do whatever s/he wants with it. At least with SSL, the
developer has no control: the data is encrypted regardless.

> Ok, why do people think that it is not secure?  Because
> verisign has led people to this conclusion.  If you read the

It's not secure because the data isn't encrypted.

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

And that, folks, just scares me.


More information about the thelist mailing list