Private Network is a WordPress plug-in that allows Administrators at different WordPress installations, for example www.alice.com and www.bob.com, to share remotely their private and public posts and pages.
- How does it work
- X.509 Certificate fields
- Certificate exchange
- Authentication Protocol
- Download (Current version 1.1)
- In the future
- Feedbacks and bugs
Say that Alice, the Administrator of www.alice.com wants to share her private posts with her best friend Bob that is the Administrator of www.bob.com;
this are the steps that both Alice and Bob would have to follow:
- Install Private Network plug-in and create the Certificate as per instructions below.
- Go to the admin section of Private Network and click
- Alice will have to enter Bob’s URL (www.bob.com) and Bob’s user-name (this is by default “admin”) in the provided text fields.
- Bob contact will appear in Alice’s contacts list with status
- Next time Bob logs-in to his site’s (www.bob.com) admin section and checks his contact list will notice Alice request with status
- Bob approves Alice request by pressing the
“Confirm Contact”button and then enables her to view his private posts by setting the status to
- Then Bob edits Alice’s Access Control List (ACL) adding items (categories, tags,posts,pages) that he wants to share with Alice
- Alice checks her contacts again and sees that Bob has confirmed her as a contact. She copies and paste the tag in her contact list associated with “Bob” into a new post (preferably a private post), saves the post and she can now view, from her blog, the items that Bob has shared with her.
- Activate the plugin through the ‘Plugins’ menu in WordPress
- Create your certificate from
`Settings`=> `Private Network` => `Certificate`
- Add contacts from
`Settings` => `Private Network` => `Contacts`
- Edit contact’s Access Control List
(Edit ACL), adding items to share with contact
- PHP 5 with OpenSSL support
The Certificate is in X.509 format and includes the following fields:
- name => WP user login (i.e. “admin”, this could be hashed to make it invisible ? feedback welcome)
- commonName => WP user display name
- organizationName => WP url address
- subjectAltName => user email address
- countryName => a 2 letter code of country (i.e. GB, US etc.)
- stateOrProvinceName => state or province (if not provided by the user the countryName is used)
- localityName => city
The following assumes that Alice and Bob are two principals, administrators of their own blogs at www.alice.com and www.bog.com respectively, have Private Network installed and have created their Certificates.
Certificate exchange happens at the moment that one of two principals adds the other as a contact, lets say that Alice wants to add Bob as a contact, the following will happen:
- Alice adds the url of bob (www.bob.com) into the field in the contacts section of Private Network and presses the Add button
- A post request containing Bob user-name and Alice X.509 Certificate in PEM format is sent to www.bob.com
- as www.bob.com receives the post request several validity check are carried out including: the certificate is a valid X.509 certificate, it contains all the required fields, the request comes from the ip address that the certificate claims to be belonging to
- if the request passes all the validity checks, the PEM certificate is hashed (sha256) to be used as an identity key of Alice and stored as a new record with other details including: the IP address, contact display name (extracted from the certificate), certificate in PEM format, email address (extracted from certificate)
- At this stage Bob will need to Confirm Alice’s contact request. Before confirming the request it is recommended (but not necessary) that Bob confirms with Alice her identity key, the identity key can be seen by Alice on her Certificate summary page, while bob can see it next to Alice record in his contact list. Note that it is strongly advisable to confirm the identity key in the case when the IP address shows as NOT verified.
- Upon Bob pressing the “Confirm Contact” button a post request is sent to Alice containing Bob’s X.509 Certificate in PEM format and Alice user name
- as www.alice.com receives the request the same validity check as point 3 are carried out on Bob’s request paramters
- As the validity check pass, Bob’s contact is updated on Alice contact table
- At this stage both contacts appears on each other box with status “Disabled”
- Bob will have to change Alice contact status to “Enabled” to let Alice retrieve his private posts, in the same manner Alice will have to change Bob contact status to “Enabled” to let Bob retrieve her private posts.
- Principals can disable or delete a contact at any moment to stop the other from viewing their own private posts.
Context: it is assumed that Alice and Bob have already exchanged their certificates (i.e. they appear as a contact in each other contacts list) and Alice wants to start viewing Bob private posts.
Alice will have created a post (better if private) an pasted into it Bob’s tag that appears next to Bob’s record on Alice contacts list. As Alice is viewing Bob’s private posts the following authentication protocol would have taken place:
- www.alice.com will send a post request to www.bob.com containing bob’s identity key and alice identity key.
- Upon www.bob.com receiving the request, it will pull out Alice contact details, do various checks including, IP address of request compared with stored Alice IP address
- www.bob.com will create 2 fresh 256 bits random number, lets call them nonce and secret
- nonce and secret will be combined as follow
nonce:secretthen encrypted with Alice public key and signed with Bob’s private key
- The nonce, the secret and other details including the timestamp and the identity keys will be stored in a session table for later use
- The encrypted
nonce:secretcombination together with the signature are sent back to www.alice.com base64 encoded.
- Upon www.alice.com receiving www.bob.com ‘s request, it will validate www.bob.com signature using Bob’s public key, (Effectively authenticating Bob) then will decrypt the
- At this stage www.alice.com will generate her half of the secret, another 256 bit fresh random number which combined with the decrypted Bob’s secret can be used (although is not used on this implementation) to encrypt subsequent transactions between www.alice.com and www.bob.com.
- www.alice.com will combine the nonce received from www.bob.com with her half of the secret in the following manner:
nonce:secretthen it will encrypt both using Bob’s public key and sign it using Alice’s Private key
- www.alice.com will send a post request to www.bob.com containing the nonce in the clear, acting as
session identifier, the signature and the encrypted nonce:secret combination
- www.bob.com will extract session details keyed by session identifier (sessions older than 1 minute are discarded), and do various checks including IP address comparison between current request and previous request stored in session table, then will verify www.alice.com signature using Alice’s public key (Effectively authenticating Alice), then will decrypt the nonce:secret combination, and concatenate his half of the secret with Alice’s half (again this can be used as key to encrypt subsequent messages from www.alice.com and www.bob.com, but it is not used on this implementation)
- at this state both www.alice.com and www.bob.com have authenticate each other and www.bob.com will send a response that includes the current session and Bob’s private posts.
- lastly www.alice.com upon receiving the response will compare the session received with the stored one and if they match it will output Bob’s private posts to Alice.
The above descriptions of Certificates exchange and Authentication Protocol, are to be seen as a very high level description, a much more detailed view can be seen by looking at the actual code.
Furthermore I like to clarify that by no means I am a cryptographic expert, I enjoy security issues and cryptology in general, I had fun reading Bruce Schneier book “Practical Cryptography” but this doesn’t make me an expert.
I agree with Schneier claim that secure cryptographic algorithms are easier to implement then secure cryptographic protocols.
Short disclaimer first:
Private Network plug-in is provided to you without any warranties, representations or gurantees of any kind, INCLUDING, WITHOUT LIMITATION THE WARRANTY OF MERCHANTABILITY AND WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE.
BY USING THE PLUG-IN YOU EXPRESSLY ASSUME ALL RISK OF LOSS ASSOCIATED WITH ANY DATA LOSS OR ANY DAMAGE ALLEDGED TO HAVE BEEN CAUSED BY THE PLUG-IN.
Provided you are happy with the above disclaimer please download the plug-in Private Network and enjoy !
In the future
In future versions of the plug-in I would like to:
- Revise the Authentication Protocol
- Add support for SSL (i.e. https)
- Maybe share single attachments
Please leave any feedback or bug report using the comment box below.