Tag Archives: encryption

The “appearance of trustability” on foo.Github.io

Github is an awesome repository system that is very popular. Basically if you want to work on something (code, a book, electronic files) and then allow others to freely make suggested modifications (think track changes in a Microsoft Word doc), GitHub is the new way of life. I have used on publishing a book, writing code, taking a Python course online, and others are using it at a scale to produce some of the fantastic tools you see online.

I recently saw a post (included below) that clarified how their encryption was setup. Basically encryption allows you to confidentially send data to another party without the fear of others intercepting, stealing, or modifying it. It appears though that for foo.GitHub.io they are presenting the appearance of encryption, but in fact do not have it. Meaning the actual files are sent in the clear.

This is a problem in our structure of security and compliance. Today we have regulations and industry standards that are designed to prescribe specific security safeguards and levels to ensure a baseline amount of security. If organizations don’t meet the true intent of the regulations, do only enough to pass inspection, but create an environment that is susceptible to basic attacks – the user (you and me) are the one’s who suffer.

While it is disappointing for an organization to setup something that clearly creates false trust and checks a box, it is more a call to action for those who operate these systems to embrace pride of the services they are delivering. Much as Steve Jobs desired the insides and outsides of a system to be done correct – the security of an organization should not just look but be right.

We must do better as owners, operators, and security professionals. Trust depends on indicators and expectations being met, and to violate that begs the question… what else is being done in the same manner?

“cben” comment below on github.com issues post:

Turns out there is no end-to-end security even with foo.github.io domain. Got this response from GH support (emphasis mine):

[…opening commentary removed…]

While HTTPS requests may appear to work, our CDN provider is adding and removing the encryption at their end, and then the request is transmitted over the open internet from our CDN provider to our GitHub Pages infrastructure, creating the appearance of trustability.

This is why we do not yet officially support HTTPS for GitHub Pages. We definitely appreciate the feedback and I’ll add a +1 to this item on out internal Feature Request List.

via Add HTTPS support to Github Pages · Issue #156 · isaacs/github · GitHub.

Best,

James

Change all your passwords, now.. it is that simple

There is a lot of reason to change passwords and in most business settings passwords are requested to be changed every 90 days. This is usually for the end users and rarely for the system to system accounts. A recent vulnerability creates the possibility that any account that accesses a system on the internet (specifically using HTTPS w/ OpenSSL, but lets not complicate the clarion call here) is exposed and known by someone other than the owner.

By that very condition the password should be changed, and now.

So if you are a person reading this …

  1. Pull up your accounts and begin methodically changing them to a fresh new version (there is a condition here that the site you are updating at has already fixed the vulnerability and has internally followed good practices, but lets presume best scenario here)
  2. Add a note on your calendar 3-4 months from now, to again change the passwords

If you run an technology environment that had OpenSSL installed and was vulnerable, grab a cup of coffee and sandwich, then…

  1. Begin the methodical (perimeter first .. working your way in through layers) and careful task of updating all of the certificates, credentials, and end-user accounts. Also consider end-users too.
  2. Write amazing and clear explanations to the need, value, and importance of this process to your users
  3. Set all users that have accounts accessing your services, to be forced to reset.
  4. Log out (invalidate sessions) all Apps and online cookie sessions (revoke, etc..)
  5. Reissue your private key and SSL certificate
  6. Review and examine your API and third party connections to confirm these are updated, reset, and secured
  7. Add a bit of extra monitoring on the logs for a bit

This is all the result of the Heartbleed.com disclosure, but lets not get technical here .. these are good practices, but now with the probability above 'unlikely', it is a timely habit to re-embrace.

 

Stay safe,

 

James