[OpenID] rfc2817: https vs http
Peter Williams
pwilliams at rapattoni.com
Tue Sep 2 02:52:23 UTC 2008
In the beginning was the https security model: and it was good. A process known as the universal browser could, given os autorization, acces a socket. Then came the fall, born of vanity. The socket as means to access ssl gave way to the ssl library and the bundling of tcp with the application. Rather than use the crypto service provider of the motherboard/os (eg intel) and the pki smib similarly, folk decided that one process could spawn a trusted process group, and enforce a security model independent of the reference monitor of the os. One spawned process/thread was the frame and another was the new browser frame that could be invoked by javascript, and registered with the (secure) window manager as a event target and ole automation engine in its own right.
In the course of discarding the assurance model of the orange book, some folks decided that frames and browser instances (but only those in a common process tree) could share ssl session and (secure) cookie stores. Others fashioned otherwise could not. Those that would notgenrally assumed the browser would, per nsa counsel, leverage certified os security services ( such as process isolation) and that would govern who could access which cookie store.
Sigh.
-----Original Message-----
From: SitG Admin <sysadmin at shadowsinthegarden.com>
Sent: Monday, September 01, 2008 6:31 PM
To: Ben Laurie <benl at google.com>
Cc: cryptography at metzdowd.com <cryptography at metzdowd.com>; general at openid.net <general at openid.net>
Subject: Re: [OpenID] rfc2817: https vs http
>typically last on the order of five minutes, an insanely conservative
>figure.
>
>What we need is something like HTTPS, shareable across protocols, with
>caches that last at least hours, maybe days.
You can use a custom session handler (not too difficult - databases
work for this) to set your own duration. But the issue here isn't
convenience, it's security. No matter how impeccable the cryptography
end is, it can't detect when a thief has broken into the user's home
and is logging into their sessions. Who logs out when they don't need
to? Or when a temporary network outage prevents someone (let's call
her Alice) at a public terminal from logging out (because it's the
remote server that registers this), and that person doesn't know how
to delete cookies (or doesn't have the permissions on that system to
do so), but has to leave before the network comes back up, and the
next person (let's call him Bob) to visit that site will be prepared
to log into Bob's account, but instead will find that the site
recognizes their computer and says "Hello, Alice. Welcome . . . "
-Shade
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general
More information about the general
mailing list