On 05/28/13 19:30, Jim Starkey wrote: > 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? >
I think that such or similar protocol will be in my todo for next FB version. What is probably interesting - when fixing an error I've found that an ability of man-in-the-middle attack was far very from just theoretical due to services. In services API there is wonderful isc_spb_command_line tag, which makes it possible to transfer command line for services utility. Adding something like 'mod sysdba -pw newpassword' for any security database service looks rather interesting for an attacker. And Jim - big thanks for this and all previous advices regarding authorization, encryption and other related things! > 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 ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
