Tales from the Gryphon/ archives/ 2009/

Tales from the Gryphon

Archives for 2009/03

Manoj's hackergotchi
Add a new post titled:
Tuesday 31 March
2009
Link: Fighting FUD: Working with openssl

Posted late Tuesday evening, March 31st, 2009

Fighting FUD: Working with openssl

#+TITLE: Fighting FUD: Working with openssl #+AUTHOR: Manoj Srivastava #+EMAIL: srivasta@debian.org #+DATE: #+LANGUAGE: en #+OPTIONS: H:0 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:t skip:nil d:nil tags:not-in-toc #+INFOJS_OPT: view:showall toc:nil ltoc:nil mouse:underline buttons:nil path:http://orgmode.org/org-info.js #+LINK_UP: http://www.golden-gryphon.com/blog/manoj/ #+LINK_HOME: http://www.golden-gryphon.com/ Unfortunately, there is so much FUD associated with doing your own certificates, either based on how complex the operation is (which led to my previous supervisor insisting I use something like ~tinyca~), and now to my employer succumbing to the FUD and shelling out several hundreds, perhaps several thousands, of dollars a year for something we could well have handled in house. Public key infrastructure, in the form of the =X509= standard, is the underpinning of most of the secured communications over the 'net these days. The big winner in the transport protocols, ~TLS~, and its predecessor, ~SSL~, support =X509= certificates. There are several ways of getting your own services their own ~X509~ certs; one of which I am exploring below. One may, or course, opt to get a commercially signed certificate, and various companies are eager to do just that for you. They also charge about $400 per annum per certificate for the privilege of doing so. While there is some marginal benefit of doing so (some web browsers come with the commercial public certificate built in, allowing for an out of band distribution of the public cert), the benefit accrued is in the order or pennies, in my opinion, not hundreds of dollars, unless you are providing banking or retail services, where the end users might be justified in being paranoid. Why is there so much FUD your own certificates? Especially about how hard it is do to your own? As you can see below, it only takes three commands you have to master in order to set up your own private certifying authority, and sign your own certificates. The only marginal issue is that the user needs to verify your certificate out of band (if, really, they want to bother). Most people just accept the certificate, in my experience. The sole benefit that commercial entities provide is that they verify the identity of the person asking for the certificate, with varying degrees of diligence. For a Class 1 cert the CA usually just verifies that the email address of the requester was confirmed. For $400/year. For a Class two cert, they look up the company in a credit bureau records. A class 3 certs does an ID check with a notary public present, or a government issued ID. So, a class 3 cert is somewhat less diligent than becoming a Debian developer. Or getting your key signed at a Debian conference. As to the security aspects, or wondering whether to trust the information present on a designated web site, I have no idea how it helps verify any of those things in any way. So the web site is run by a person with a government provided ID, and who has a few hundred dollars to burn. So what? Me, I just sign my own certificates. And I think most small business web sites and mail servers are perfectly well served by using their own certificates. And there are just three simple commands that enable them to do this, in the Linux world. So what are these three commands? #+BEGIN_HTML Gory practical details and recipes hidden here #+END_HTML In conclusion, creating your own certifying authority is trivial, and certainly not worth several hundreds of dollars every year, and the functionality provided is identical.

Manoj

Sunday 01 March
2009
Link: Rethinking ucf redux

Posted late Sunday evening, March 1st, 2009

Rethinking ucf redux

#+TITLE: Rethinking ucf redux #+AUTHOR: Manoj Srivastava #+EMAIL: srivasta@debian.org #+DATE: #+LANGUAGE: en #+OPTIONS: H:0 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:t skip:nil d:nil tags:not-in-toc #+INFOJS_OPT: view:showall toc:nil ltoc:nil mouse:underline buttons:nil path:http://orgmode.org/org-info.js #+LINK_UP: http://www.golden-gryphon.com/blog/manoj/ #+LINK_HOME: http://www.golden-gryphon.com/ I have been thinking some more about how to improve ucf. One of the things that struck me was that based on my earlier #+BEGIN_HTML analysis #+END_HTML there are only five actions that ucf can take, and the decision about the actions depends on the state it finds the configuration file in on the target machine, and there are only eight of those. Now, thinking back to my days as a VLSI designer back in the halcyon days of electrical engineering, This is a pretty simple state machine. It is not as neat as it could be (where just three variables would be needed to keep track of things, but still, it bears investigation. This would be a way for converting the current procedural /ucf/ into a functional programming model. Hop over #+BEGIN_HTML here #+END_HTML for a look at how that went --- it was fun, and afforded me an opportunity to demonstrate how well /org/ handles #+BEGIN_HTML LaTeX.png #+END_HTML snippets.

Manoj


Webmaster <webmaster@golden-gryphon.com>
Last commit: terribly early Sunday morning, June 8th, 2014
Last edited terribly early Sunday morning, June 8th, 2014