I agree completely with your analysis and the contrary conclusion. But
don't feel too bad -- the MySQL security handshake also suffers from a
man-in-the-middle vulnerability wide enough to drive a truck through
that wasn't recognized until I took a critical look at when designing
the NimbusDB security handshake.
There is an SRP validation protocol kicking around, but in my ever
humble opinion, it's ludicrously overbuilt and expensive. I just enable
encryption after the initial message exchange then look very carefully
at the next message after decryption. Due to a change in the
meta-protocol, however, this was a lot easier for me than for Firebird.
Relatively early in NimbusDB development I abandoned all stream
protocols in favor of message based protocols. In specific, each
message is preceded with an unencrypted four byte binary length. This
has all sorts of benefits:
* An extreme long denial-of-service message can be rejected before
allocating resources to receive it
* Message decode can be validated by checking the actual length versus
the deconstructed length
* A store-and-forward messaging proxy becomes trivial (and protocol
independent)
* A multi-socket listening thread / worker threads architecture is
clean, simple, and (almost) bomb-proof (this is a win so big that it
can't be over emphasized)
* Received messages can be easily managed for multiple purposes
(applied, logged, queued, replayed, etc.)
If the new Firebird protocol hasn't switched to counted-packets and it
isn't too late, you might give it some thought.
There are a couple of other things that I have taken to doing that might
be of some interest. One is a standard XML-based initial connection
protocol for all processes. This makes it very easy to add additional
services to a server without resorting to multiple ports. This is much
more important to the NuoDB architecture than Firebird, is almost
certainly too late (it was too late in 1985), but is something to think
about.
The other change is switch to self-describing message encoding. I use
an encoding where the "type" byte encodes both type and length and
sometimes value. There are, for example, type codes for specific
integer between, say, -10 to 32 as well as type codes for integers of
length 1 through 8. When encoding data records, average encoding
lengths were about 60% the length of Firebird's run length encoding.
XDR is getting rather long in tooth, don't you think?
On 5/28/2013 6:54 AM, Alex Peshkoff wrote:
On 05/27/13 20:10, Jim Starkey wrote:
Is the attach package encrypted with the session key? If so, the hash
of the session key isn't necessary. If not, the exchange is susceptible
to a man-in-the-middle attack with a buggered DPB.
Hops...
Though such attack looks at the first glance just theoretically
possible, that should be fixed.
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
