| Subject | Re: [Firebird-Architect] Block Encryption, Initialization Vector, and Security |
|---|---|
| Author | Olivier Mascia |
| Post date | 2010-11-10T14:23:05Z |
Le 10 nov. 2010 à 14:04, Alex Peshkoff a écrit :
There might be challenges in using TLS as a tunnel for the current FB line-protocol. I haven't look at it closely enough. But you can't go wrong trying to use TLS for that matter. On a security (and public-relation) point of view it will always be better to say Firebird uses standard TLS v1.0, v1.1 or whatever with a choice of this or that cipher-suite, than say it is secured using a home-made SSL look-alike which will never have been scrutinized as much.
I faced those questions and challenges a good 7 or 8 years ago (AFAIR) and went the OpenSSL way (which was much more of a challenge by then than today, especially on Windows platform which was my main target at that time). I use it for certificate management, server and client and users authentication and for encryption of the line-protocol between the client-side of an application and its server-side (which is "in the cloud" or local on the LAN depending on the customer). Pretty much the same needs than those of fb. The license requirements (essentially BSD-style licensing) should not be an issue for Firebird. http://www.openssl.org/source/license.html
Honestly the issue with OpenSSL is its documentation (http://www.openssl.org/docs/) and learning curve when the basics, covered in 2 hours or less, are set aside.
—
Olivier Mascia
> Just want to make sure...The exact format of what flows over the wire does not have to be under FB control or understanding. When you send() 64 bytes from fb over the wire, what does flow over the wire? You don't care about the tcp packets, their headers, checksums, the IP packets, the ethernet frame, the actual transport medium, be it copper or light fiber. What counts for fb are the bytes that fb emits and sees at the application level. Now throw TLS in-between, what still counts is what fb sees and emits.
> If we choose this approach, we partially loose control over format of
> data, transmitted over network, and this is architectural choice. If TLS
> really does provide "good enough" protection - that's OK.
There might be challenges in using TLS as a tunnel for the current FB line-protocol. I haven't look at it closely enough. But you can't go wrong trying to use TLS for that matter. On a security (and public-relation) point of view it will always be better to say Firebird uses standard TLS v1.0, v1.1 or whatever with a choice of this or that cipher-suite, than say it is secured using a home-made SSL look-alike which will never have been scrutinized as much.
I faced those questions and challenges a good 7 or 8 years ago (AFAIR) and went the OpenSSL way (which was much more of a challenge by then than today, especially on Windows platform which was my main target at that time). I use it for certificate management, server and client and users authentication and for encryption of the line-protocol between the client-side of an application and its server-side (which is "in the cloud" or local on the LAN depending on the customer). Pretty much the same needs than those of fb. The license requirements (essentially BSD-style licensing) should not be an issue for Firebird. http://www.openssl.org/source/license.html
Honestly the issue with OpenSSL is its documentation (http://www.openssl.org/docs/) and learning curve when the basics, covered in 2 hours or less, are set aside.
—
Olivier Mascia