Fwd: [guardian-dev] Piñata server intrusion bounty
hannes at mehnert.org
Wed Feb 11 02:03:15 PST 2015
-----BEGIN PGP SIGNED MESSAGE-----
On 02/11/2015 06:49, grarpamp wrote:> ---------- Forwarded message
> From: Patrick Connolly <patrick.c.connolly at gmail.com> Date: Tue,
> Feb 10, 2015 at 1:38 PM Subject: [guardian-dev] Piñata server
> intrusion bounty To: Guardian Dev
> <guardian-dev at lists.mayfirst.org>
> Would this be an interesting thing to put on a duplicate (...or
> production?) system and publicize?
> Might be an interesting practise for creating a form of canary,
> especially for projects that perhaps can't afford full and
> constant audits.
I'm one of the authors of OCaml-TLS, and we setup the bounty.
So why did we do it? Because lots of company security bounties are
very bureaucratic and intransparent - in order to receive the bounty
you've to argue with the company - you might not disclose the
vulnerability, they might not agree to the vulnerability, etc. (see
[I don't share all arguments of both articles]).
Thus, having a transparent way [the blockchain] and an automated
transmission (the server replies after successful authentication with
the private key - no interaction from myself or the other author
needed) - motivated us to put something against those security bounties.
Unfortunately, it can only show the existence of issues, not their
absence. The amount of the bounty is high enough to get some attention
- - but might be too low for professionals to properly analyse (but
then, they'd be able to brag about their success and get some fame).
A too high bounty would put myself and the other author too much into
the focus of a targeted attack. Obviously we have access to that
private key in some way or another..
If you consider doing something like that again (which I appreciate),
please take care to not deduce the security of YYY from no successful
attack on the bounty (it depends very much on time, publicity, bounty
- - whether it gets interest).
It is crucial that such a bounty does not replace proper code audits
(I don't have a good definition of "proper" here).
Also, it would be neat to think about a good way how the server can
prove that it actually has the private key to the bounty - but I
believe it is impossible (similar to that the server cannot prove it
runs the software we claim it does).
So far we had roughly 75000 accesses to the website, and roughly 5000
TLS handshakes to the client/server/reverse client - which very much
shows that it primarily gets publicity.
I especially like our setup that you can short-circuit the server with
its client and observe a successful TLS handshake which afterwards
transmits the private key over the encrypted channel.
I'm happy to discuss this further, and get feedback on the setup,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
More information about the cypherpunks