[OpenID] rfc2817: https vs http

[Peter Williams]

So Ben, in your browser are you going to properly use the SSL re-handshake process, to periodically rebuild keying material, when the client initiates a request to resync after 1m, on an existing session?

With the Netscape model (defined in days when all American internet security products were designed with compromise built-in, by govt fiat) the server has complete control. You don't have to stay with that model. You can share control these days with the client, and "move forward". You can even facilitate SSL-role swapping during re-handshake, and turn SSL into a peer-peer protocol. While you are at it, put the core openid handshake into an TLS hello extension, so the whole http/https issue goes away. Make it a proprietary google extension number, for now.

Now, Google would be making a difference in security! Once you have your own browser; none of this is hard..and shifts the 15 year old paradigm.

Be bold Don't be afraid of new classes of vulnerabilities. They go away, naturally, as your peers then do THEIR job.



-----Original Message-----
From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Ben Laurie
Sent: Monday, September 01, 2008 7:50 PM
To: SitG Admin
Cc: cryptography at metzdowd.com; general at openid.net
Subject: Re: [OpenID] rfc2817: https vs http

On Tue, Sep 2, 2008 at 2:01 AM, SitG Admin
<sysadmin at shadowsinthegarden.com> wrote:
>> 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.

I repeat: not if the client drops the session after five minutes.

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

True, but entirely unrelated to SSL session duration.
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general