[foaf-protocols] foaf.me with https, vs http

Akbar Hossain akkiehossain at googlemail.com
Thu Jan 21 01:11:21 CET 2010


On Wed, Jan 20, 2010 at 11:46 PM, Peter Williams <pwilliams at rapattoni.com>wrote:

>  Thanks. That helps.
>

Welcome

>
> I’ve implemented scenario B to demo level (and A is a given). I have not
> implemented the combination of A and B (which feels like a cute demo, for
> showcasing). Since my demo is supposed to be rigorously RESTful, I have no
> notion of web session (only persistent “transport sessions” that are
> provided by SSL in a manner transparent to the web layer). There is no
> notion of being “logged in”, and thus one cannot the RP cannot signal the
> IDP to destroy its persistent transport session (SSL of course) with the
> windows desktop
>

Makes sense for what you are programming.

> The only things missing in supporting B is the ability to (a) actually
> verify the RSA signatures (which I’m debugging), support the exception cases
> of the state machines disclosed on the spec page, and implement some window
> for accepting the timestamp . (There is no evidence of an anti-replay
> requirement, requiring caching, making the scheme essentially equivalent to
> the 1-pass strong auth mechanism documented in X.509 1988). I’m not sure how
> much of an official proposal foafssl.org’s message decls and states are,
> though. It’s mostly a demo of a “nominal” token asserting IDP using a
> redirect binding, from what I can tell. Its rather similar to the OASIS
> “simple signing” binding of SAML, of course (which does away with the SOAP
> and XML wrappers/marshalling). WE might be better to simply use what he
> simple saml SAML binding provides, particularly if it removes the SOAP and
> XML handling obligation so its easy for string processing php/perl scripts
> to process.
>
Saw your email on another thread about RDFa on the homepage of testssl.org.
Sorry I didnt get a chance to reply. I like the idea/concept. There is a
copy of testssl.org public key on the foaf.me server which it uses but I see
mileage in some sort of Web of Trust for Public Keys. So foaf.me being an
agent and asserting it knows the key of testssl.org as this, etc.

Correct re timestamps are not checked for replay attacks and the like. The
function in question is getAuthFromDelegatedFOAFSSL() - timestamp checks I
vague remember being on the TODO list mentioned on a thread.

>
> So far I’ve implemented B using a end-end script, rather than make its
> tokenhandler an formal inceptor in the stack that has its claims goes into
> the authorization policy handlers, along with  other claims from the other
> tokens on the call (if any). Its relatively trivial to move the script class
> into the listener behaviour, so it becomes an interceptor… A class is a
> class, in .NET world.
>
>
>
> One interesting experiment is to have the client induce server-side
> destruction of transport session …by doing a TCP close on WITHOUT first
> doing a SSL close. For conforming servers, this forces  the server to cease
> further use of that transport session (ssl3 sessionid) on ALL outstanding
> connections, including those connections derived from the pre-master secret
> tied to the SSL3 sessionid.
>

Good luck


>
>
>
>
>
>
> *From:* Akbar Hossain [mailto:akkiehossain at googlemail.com]
> *Sent:* Wednesday, January 20, 2010 3:27 PM
> *To:* Peter Williams
> *Cc:* foaf-protocols at lists.foaf-project.org
> *Subject:* Re: [foaf-protocols] foaf.me with https, vs http
>
>
>
> Hi Peter,
>
> The login on behaviour foaf.me changed back in December.
>
>
> http://lists.foaf-project.org/pipermail/foaf-protocols/2009-December/001204.html
>
> The scenario/behaviours you describe is the result of supporting both the
> delegated server (B) and the direct ssl authentication (A) within a single
> function.
>
> [The setup of the server and the site is maybe not what you would not
> expect on a site using a delegated login service]
>
> The foaf.me server  has an ssl connection and asks for a client
> certificate on all pages served. I dont think you would expect this on site
> using testssl.org.
>
> So if you visit https://foaf.me it will ask for a client certificate. If
> you supply an authenticated certificate it will store the result in a
> session cookie.  If you press the log out button the session get cleared. If
> you now press the login button it does scenario B.
>
> If you start at http://foaf.me (must be a new session) the login button is
> scenario B.
>
> The relevant code is here.
>
>
> http://github.com/melvincarvalho/libAuthentication/blob/master/lib/libAuthentication.php
>
> The function to start with is getAuth().
>
> Thanks
>
>
>
>
>  On Wed, Jan 20, 2010 at 2:46 PM, Peter Williams <pwilliams at rapattoni.com>
> wrote:
>
> Has the behavior of foaf.me changed, recently?
>
>
>
> (I’m back to programming my foaf-demonstrate website to rely on
> foafssl.org’s signed tokens, simply by copying what foaf.me does in
> practice).
>
>
>
> Here is what the evidence from observing foaf.me’s interaction with
> foafssl.org suggests:
>
>
>
> A If I connect a browser to foaf.me using https, the site seems to rely
> directly upon the client cert (and associated foaf document). It directly
> mints a web session.
>
>
>
> B If I connect a browser to foaf.me using http, it redirects to
> foafssl.org (which seems to rely upon the client cert and associated foaf
> document). The redirect is sent over https. Foafssl.org seems to returns a
> redirect status response (over https, though I didn’t look for a possible
> ssl half close) bearing an hmac-signed token targeting foaf.me. The
> redirects seems to induce the browse to connect over HTTP to Foaf.me , which
> seems to rely upon that token, presumably  after verification, and then
> mints a web session.
>
>
>
> The web sessions minted by foaf.me in cases A and B seem identical,
> despite there being very different bases of reliance and quite different
> levels of transport security used during the processes of reliance. Note in
> B how the asserted token is transferred over http  vs https at one point and
> in B the token’s security is a simple hmac (vs the ssl-handshake’s read key
> for integrity used during reliance in case A).
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100121/72686dca/attachment.htm 


More information about the foaf-protocols mailing list