[foaf-protocols] HOWTO: Use FOAF+SSL from a command line

Joe Presbrey presbrey at gmail.com
Mon Apr 12 21:54:45 CEST 2010


I know all about TLS and wasn't talking about FOAF endpoints
specifically.  If you trust my WebID and want to talk to my
TLS-enabled endpoint, why do I have to buy a CA cert from someone you
trust?  Can my endpoint tout my WebID or can I link to its own unique
WebID/pubkey from my FOAF and have you trust it as well?  It seems the
assurance would be that the communication is encrypted at least
between you and me (my WebID) and of course by extension, between you
and people I trust with my private keys.  Sorry if I'm missing
something here -- FOAF+SSL is just a lot more compelling to me as a
completely ad-hoc trust network (no Verisign).

I would still assert that going from HTTP+FOAF+SSL-via-3rd-party-IdP
to HTTPS+FOAF+SSL(noCA)-direct is an upgrade in security at least from
the perspective of the server.  Of course via either means the client
cannot absolutely trust they are talking to The Right Server.  But for
the server, who really knows what that IdP is going to say or that it
has not been compromised?  I think its always most secure for servers
to make their own decisions regarding authentication when possible.

Also, I'm pretty sure Melvin was publishing these URIs as test
endpoints and did not mean to have you submit anything critical other
than a standard SSL handshake via copy-paste of the command line to
check that its working ;)

--
Joe Presbrey

On Mon, Apr 12, 2010 at 1:08 PM, Bruno Harbulot
<Bruno.Harbulot at manchester.ac.uk> wrote:
> Hi Joe,
>
> This isn't really about FOAF endpoints, or FOAF+SSL authentication, this is
> about transport-level security to the service provider.
>
> Using '--no-check-certificate' simply says "I don't really mind if the thing
> I'm talking to and authenticating to isn't the server I meant to communicate
> with".
>
> It's not a problem as such: there are a number of websites out there that
> are not TLS-enabled and that require the user to log on. FOAF+SSL is an
> improvement over that model in that, even if you don't trust the server, you
> won't send your private information (that would be a password) to the
> potentially rogue server.
> However, if you don't check the server certificate, other assumptions that
> come with the use of HTTPS fall apart (mainly, the fact that you're not
> talking to a man-in-the-middle instead of the server you wanted). Not
> verifying the server certificate is bad practice for this reason.
>
>
> That's a slightly different problem to the hosting of FOAF documents, which
> should also be done on HTTPS for having some level of assurance that they
> haven't been altered (at least not during the transport).
> In this case, it's up to the certificate consumer (that verifies the WebID
> via the dereferencing of the FOAF document) to check that it trusts the
> certificate of the server hosting that FOAF document.
> That's done via the trust manager (probably default cacerts) in Java, or it
> seems, via whatever trust anchors librdf is configured with in
> mod_authn_webid (I'm not sure how it's done there).
>
>
> Best wishes,
>
> Bruno.
>
> Joe Presbrey wrote:
>>
>> Requiring CAs is fine but in linked data esp. FOAF a few questions come to
>> mind:
>>
>> Can I link to the CA I'm signing my endpoints from my FOAF?
>> Can I ask/crawl my FOAF network to generate a '--ca-directory' of my
>> friends?
>>
>> --
>> Joe Presbrey
>>
>> On Mon, Apr 12, 2010 at 7:19 AM, Bruno Harbulot
>> <Bruno.Harbulot at manchester.ac.uk> wrote:
>>>
>>> Hi Melvin,
>>>
>>> How about *NOT* using --no-check-certificate, but --ca-certificate or
>>> --ca-directory instead, with wget? Not checking the server certificate
>>> defeats the point of using TLS.
>>>
>>> For curl, the options are similar: --cert, --key, --cacert, --capath.
>>> However, the user's certificate must be in PEM format (this is what's
>>> produced by the openssl command you've given anyway, so that's not a
>>> problem).
>>>
>>> Best wishes,
>>>
>>> Bruno.
>>>
>>> Melvin Carvalho wrote:
>>>>
>>>> 1. Preparation
>>>> ===========
>>>>
>>>> You are assumed to already have a FOAF+SSL certificate in your browser.
>>>>
>>>> If you have not already, save a backup of this (in firefox
>>>> Edit->Preferences->Advanced->Encryption View Certificates->Backup)
>>>>
>>>>
>>>> 2. Create .cer and .key
>>>> =================
>>>>
>>>> Use openssl to create a .cer and .key file that you will need to access
>>>> a page later.
>>>>
>>>> I am assuming the saved file is foafssl.p12
>>>>
>>>> openssl pkcs12 -in foafssl.p12 -nocerts -out foafssl.key
>>>> openssl pkcs12 -clcerts -nokeys -in foafssl.p12 -out foafssl.cer
>>>>
>>>>
>>>> 3. Use wget to access a foaf+ssl protected resource
>>>> =======================================
>>>>
>>>> In this example I'm just using a test page i made at
>>>> https://foaf.cc/everyone, but any foaf+ssl resource should work, e.g.
>>>> https://foaf.me/simpleLogin.php or https://dig.xvm.mit.edu/test/everyone
>>>>
>>>> *3.1 Without a WebID*
>>>>
>>>> wget -qO- --no-check-certificate https://foaf.cc/everyone
>>>> Array
>>>> (
>>>>    [REMOTE_USER] =>
>>>>    [SSL_CLIENT_VERIFY] => NONE
>>>>    [SSL_CLIENT_CERT] =>
>>>> )
>>>>
>>>> *3.2 With a WebID*
>>>>
>>>>  wget -qO- --no-check-certificate https://foaf.cc/everyone
>>>> --certificate=./foafssl.cer --private-key=./foafssl.key
>>>> Enter PEM pass phrase:
>>>> Array
>>>> (
>>>>    [REMOTE_USER] => <http://foaf.me/melvincarvalho#me>
>>>>
>>>>    [SSL_CLIENT_VERIFY] => GENEROUS
>>>>    [SSL_CLIENT_M_VERSION] => 3
>>>>    [SSL_CLIENT_M_SERIAL] => 0255
>>>>    [SSL_CLIENT_V_START] => Oct 30 12:34:20 2009 GMT
>>>>    [SSL_CLIENT_V_END] => Oct 30 12:34:20 2010 GMT
>>>>    [SSL_CLIENT_V_REMAIN] => 202
>>>>    [SSL_CLIENT_S_DN] => /CN=FOAF ME Cert http://foaf.me/melvincarvalho
>>>>    [SSL_CLIENT_S_DN_CN] => FOAF ME Cert http://foaf.me/melvincarvalho
>>>>    [SSL_CLIENT_I_DN] =>
>>>> /C=GB/ST=LONDON/L=Wimbledon/O=FOAF.ME/CN=FOAF.ME/emailAddress=ca at foaf.me
>>>> <http://FOAF.ME/CN=FOAF.ME/emailAddress=ca@foaf.me>
>>>>
>>>>    [SSL_CLIENT_I_DN_C] => GB
>>>>    [SSL_CLIENT_I_DN_ST] => LONDON
>>>>    [SSL_CLIENT_I_DN_L] => Wimbledon
>>>>    [SSL_CLIENT_I_DN_O] => FOAF.ME <http://FOAF.ME>
>>>>    [SSL_CLIENT_I_DN_CN] => FOAF.ME <http://FOAF.ME>
>>>>    [SSL_CLIENT_I_DN_Email] => ca at foaf.me <mailto:ca at foaf.me>
>>>>
>>>>    [SSL_CLIENT_A_KEY] => rsaEncryption
>>>>    [SSL_CLIENT_A_SIG] => md5WithRSAEncryption
>>>>    [SSL_CLIENT_CERT] => -----BEGIN CERTIFICATE-----
>>>> MIID0jCCAzugAwIBAgICAlUwDQYJKoZIhvcNAQEEBQAwcTELMAkGA1UEBhMCR0Ix
>>>> DzANBgNVBAgTBkxPTkRPTjESMBAGA1UEBxMJV2ltYmxlZG9uMRAwDgYDVQQKEwdG
>>>> T0FGLk1FMRAwDgYDVQQDEwdGT0FGLk1FMRkwFwYJKoZIhvcNAQkBFgpjYUBmb2Fm
>>>> Lm1lMB4XDTA5MTAzMDEyMzQyMFoXDTEwMTAzMDEyMzQyMFowNTEzMDEGA1UEAxMq
>>>> Rk9BRiBNRSBDZXJ0IGh0dHA6Ly9mb2FmLm1lL21lbHZpbmNhcnZhbGhvMIIBIjAN
>>>> BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv0aWEsahXIsyM+RFfrk5peo2CbHf
>>>> MP8V9Jd1rZrEH1f0I6x8wnootCKxF4efROytvSSsLZSDqodjVoV88UuFfHV8rgf3
>>>> gKfm2S7pmy6O84k7PxeqXO+dPsEW5xgqYN5wxI7agmNQRTOAWvJmZnKzzAs2Whjr
>>>> QLwAr9WeFSF0MKQpCtDNk+nm9tWuMmSrBTLK8/6hWLU5eOfRtjFU3SsgWDici5if
>>>> jRVVAirP2pkC+gyNgZIWCVZa9CR1qT9f6TWXiKSHA0mbWWoL3HAqjU2wka9ZWrcN
>>>> B6WiTeBbJfrphIw8xNm9PP9OQWYabBWfgq+7OcXbuzZs9KLHJWhyRa90nQIDAQAB
>>>> o4IBLzCCASswCQYDVR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5l
>>>> cmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFFbD6dcbXxx2B5tXtRUWKR9bYde/
>>>> MIGjBgNVHSMEgZswgZiAFELZDvt6tNTvvl9Lh36+061MZMMzoXWkczBxMQswCQYD
>>>> VQQGEwJHQjEPMA0GA1UECBMGTE9ORE9OMRIwEAYDVQQHEwlXaW1ibGVkb24xEDAO
>>>> BgNVBAoTB0ZPQUYuTUUxEDAOBgNVBAMTB0ZPQUYuTUUxGTAXBgkqhkiG9w0BCQEW
>>>> CmNhQGZvYWYubWWCCQC4izjTitF14jArBgNVHREEJDAihiBodHRwOi8vZm9hZi5t
>>>> ZS9tZWx2aW5jYXJ2YWxobyNtZTANBgkqhkiG9w0BAQQFAAOBgQBe9Fssxq2+t/UR
>>>> tAYgGStbcKyn66beZGmIb89zFtnjY2PNJOpfIMZtgsJKEAgAWdnxtoXsmmE7yJEd
>>>> L9hXruqk2oJix2qm/Po/MxnUaVnhdVMM+UHyOsNkg+4natLVkdkDlLlRDbPl650T
>>>> s2nMES7pyN3VbrUv1l+kbcfSZIMgvg==
>>>> -----END CERTIFICATE-----
>>>>
>>>>
>>>> In this way you can automate the process of sending authenticated
>>>> requests to resources across the web, getting responses, processing
>>>> them, and acting on the information.  Hopefully this will be one more
>>>> tool for us to be able to generate data centric communities.
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> foaf-protocols mailing list
>>>> foaf-protocols at lists.foaf-project.org
>>>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>>>
>>> _______________________________________________
>>> foaf-protocols mailing list
>>> foaf-protocols at lists.foaf-project.org
>>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>>>
>


More information about the foaf-protocols mailing list