Netscape's use of SSL
Sun, 7 Nov 1999 15:03:09 -0800
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
I am very pleased to hear it! That really helps but see PKI issue:
>> >> 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
>> 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
It seems too hard to reason about transaction logic with bits and pieces of
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
Norman Hardy <http://www.mediacity.com/~norm>