PostgreSQL Security



My first “in-person” class of my graduate program was a discussion on security of PostgreSQL given by Bruce Momjian.  Not surprisingly, PostgreSQL offers a full range of SSL support and a slew of encryption options.  As impressive as the options are, the challenge seems to me, in deciding what trade-offs make sense for a particular employment.

For example, if one chooses column level encryption, than that data is not only encrypted to malicious entities, but to friendly daemons like the statistics collector.  There are definitely some interesting systems engineering decisions that need to made when deciding what data is critical enough to be encrypted.

On the TLS side, I couldn’t help but to think of Adam Langely’s (Google Chrome TLS guy) talk from HOPE#9, which I unfortunately did not attend but fortunately, the audio is now posted!  Essentially, if the state of web SSL is as bad as he says it is, I wonder how many databases actually have SSL incorporated correctly?  Of course, security is a multi-pronged beast and SSL isn’t going to help you when somebody steals the hard-drive with your database on it.

Having taken classes only online, I took advantage of this antiquated medium (going to class in person is so 2011) and asked a lot of questions, probably much to the chagrin of my fellow students.  But, it was a nice change of pace and I can see why so many physical study groups have sprung up from the Coursera courses.


TLS False Start is dead

So for about a year and half, Chrome has been speeding up TLS / SSL connections by a mechanism called “TLS False Start.”  The performance improvements were impressive; False Start dropped connection times by 30% or just under 200 ms.  The details of TLS False start are described in this tech memo, but the basics are that the client starts sending application data immediately after the Change Cipher Spec and Finished messages, without waiting from the server.  This essentially removes one round trip across the network.  Actually, it’s quite clever since once the client has sent the Change Cipher Spec message, it has shifted over to the bulk encryption algorithm and finished the key exchange and doesn’t necessarily need to wait for the server to confirm.

However, the reasons for its demise are a bit comical and unfortunately False Start’s tragedy has much to do with a good protocol and restrictive implementations.   My favorite problem was that a major vendor of SSL Terminators (servers acting as the SSL / TLS endpoint, probably with hardware acceleration) has some sort of minor bug preventing the use of TLS False start.  The vendor refused to fix it.

One, fairly major, SSL terminator vendor refused to update to fix their False Start intolerance despite problems that their customers were having. I don’t believe that this was done in bad faith, but rather a case of something much more mundane along the lines of “the SSL guy left and nobody touches that code any more”. However, it did mean that there was no good answer for their customers who were experiencing problems.

I can see how this can happen and why the company wouldn’t want to fix it.  By the way, I’ll be returning to work in August… (no I don’t work for this vendor). 🙂

One of the frustrating aspect of protocol design is that there is a duality consisting of what the protocol says and the populous implementation.  Actually, its more of an oligarchy, where the most popular implementation sets the standard.

Well, you can still install HTTPS Everywhere in Chrome so that’s a good thing.  I highly recommend it.  Not only is supported by the EFF, a great organization, it’ll always attempt to use the https version of a website, making your web traffic more secure.

HTTPS Everywhere from the EFF

[UPDATE] For those with a Wireshark inclination, here are two captures of TLS False Start in action.

TLS False start in action on the client and server
False start on the client side only (chrome)