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

Akbar Hossain akkiehossain at googlemail.com
Thu Jan 21 00:27:23 CET 2010


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/20100120/2ee45121/attachment.htm 


More information about the foaf-protocols mailing list