Introducing Stud (open source secure gateway)
devblog.bu.mpThis is an evented proxy around OpenSSL's async interface. It has a totally reasonably ring buffer library it uses to buffer the data it's proxying, and virtually no other logic. It's so simple it doesn't really even present many obvious opportunities for security bugs.
My only complaint is that Jamie didn't tap us to look at it too. I feel slighted!
Apart from that, this is great stuff. I have clients that can use it immediately. Thanks!
you're welcome! I did want to make this simple and bulletproof, avoiding dangerous or clever things on the critical path. Particularly wrt the upstream socket. I'm happy you approve.
And we definitely have your number in the Rolodex for some crazy things we might try soon when we need some sanity checks that we haven't gotten in over our heads.
FWIW, Jamie asked me to audit an earlier version of this code. I haven't looked at the version he released, but the version I saw looked secure to me (subject to the assumption that OpenSSL bugs aren't exploitable, at least).
.. and I owe much thanks to you for your feedback (and almost all of it was incorporated); I just hadn't asked you for permission to bring your name into the picture, so I didn't! ;-)
What had you done differently prior to Colin's feedback? Inquiring minds &c &c.
Mostly style and idioms. One bug related to inefficiency but not necessarily incorrect behavior. An optimization or two.
You have my permission. ;-)
tl;dr version: https://github.com/bumptech/stud
Nice job. This could be a workable interim solution until Mongrel2 gets native TLS/SSL support!
In the presence of tools like this and Pound, I'm wondering whether Mongrel2 should get TLS support.
So at first I thought this was for people who don't want to use something like nginx. But then I read "it's designed to be paired with an intelligent backend like haproxy or nginx." If I'm already using nginx, why wouldn't I just have it do SSL?
Oops, that was stupid, I somehow made it the github page without reading the actual blog post. nm.
Is this the same idea as stunnel, but meant to scale to more connections?
Seriously awesome name.
Why a proprietary protocol?
Not ignoring your question, btw, but I'm not at liberty to elaborate.
This is a very good question. The bump magic is timing and data, I can't think of any reason for a special protocol.