Netscape's use of SSL

Ben Laurie
Sun, 07 Nov 1999 23:14:31 +0000

Norman Hardy wrote:
> At 21:33 +0000 99/11/07, Ben Laurie wrote:
> >Norman Hardy wrote:
> >>
> ...
> >> You assume that the browser compares the "name on the cert" with the domain
> >> name in the URL. I wish this were so. It may be so. (Tyler thinks it is.) I
> >> have heard from someone who I think read the code that it was not so. That
> >> theory was merely that people with certs were obviously good and the only
> >> the rare user would actually want to see which good guy he was talking to.
> >> I would be much comforted by a Netscape page that explained what the
> >> browser did. A test is also feasible and useful. I hope I am wrong. I wish
> >> I were sure one way or the other.
> >
> >Well, I am. The browser does compare the cert. This actually causes a
> >FAQ for Apache-SSL, which is "why can't I use name-based virtual hosts
> >with SSL?" - the problem being that the cert doesn't match the URL, and
> >the browser bleats loudly about bad guys and men-in-the-middle and
> >stuff.
> I am very pleased to hear it!  That really helps but see PKI issue:
> <>.

Boy, you are a pessimist, aren't you? What a CA actually does is to
ensure that the owner of the private key is also the owner of the domain
name bound to that key. This is done by verifying company registration
paperwork and the like. What I'm talking about here is the kind of CA
that issues server certs that are recognised by mainstream browsers.
Clearly (well, its clear to me, but after recent revelations on the
subjects of SSL and PKI I fully expect it to not be at all clear to
other participants on this list) a CA can choose to have an entirely
different registration policy, but that is pretty much the policy used
by the only two CAs that matter in this context (Verisign and Thawte)
plus all the CA wannabes chasing them from behind.

DNs are only required to be distinct if you wish to use directories. PKI
doesn't actually need them, which makes X.509 a somewhat ironic choice
for certificates. But that's showbiz.

What you do need is for there to be a strong binding between where you
are and the key. Which there is.

> >> >> Another weakness that I think plagues Netscape is that the duration of a
> >> >>session, in which a secret key is shared between the browser and site, is
> >> >>not available to application logic at the site. Such logic now has a
> >> >>difficult time associating successive https transactions from the same
> >> >>browser with each other.
> >> >
> >> >This is silly: the SSL session is not intended as an application session
> >> >- there's no requirement for the browser to use a single SSL session,
> >> >for example, nor for the server to reuse it if asked, and the timeout
> >> >may, for security reasons, be wildly different from the timeout on an
> >> >application session. If you want an application session, you should
> >> >create one in the usual way, not attempt to abuse the SSL session as
> >> >one.
> >>
> >> I agree that it was not intended that to be used as an application session,
> >> and I think that that is a pitty. The available schemes to maintain
> >> application session context seem baroque and error prone to me. I think
> >> that application session duration must usually be compatible with a human
> >> remembering some context. Sounds like a good match to me.
> >
> >Sure. A good match between an application session and a user. But a very
> >poor match between the appropriate lifetime of a cryptographic object
> >and any other consideration. Cookies are the appropriate mechanism.
> I show my prejudice here but I like to keep my stack (context) on my own
> machine.
> It seems too hard to reason about transaction logic with bits and pieces of
> its state
> scattered about, just waiting to be lost or replayed. It would seem that some
> are able to do this.
> I don't expect to convince you or anyone else here however with so little
> explanation.

Actually, that's more than enough to convice me, because I was already
convinced. What I meant is that you should keep the session ID in a
cookie (or as part of all URLs, this being the other scheme), not any of
the session state. Note that the session ID could easily be viewed as a
capability, AFAICS (but I'm probably exposing my ignorance here).




"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi