we are working very hard to close the security cord around our application.
We started releasing the code, and we have recently added the full
build script, allowing anybody to check on her own that our code has
really being used to build the application available online.
But there is still one step missing: easily check that the code loaded
into the browser does match with the "certified"[1] checksum.
We are looking for a definitive answer, but we are not there, yet.
In the meanwhile, we have written a very simple php script that could
perform this check very easily. You can see it in action here:
- <http://www.clipperz.com/integrityCheck.php?md5=bdf19e25efbceae2e80e056adb0db81f>
If you change the value of the md5 parameter you can see that the page
content changes immediately.
While this script is hosted on owr server, your confidence in the
security does not improve much; but attached to this message you can
find the full script, ready to be deployed on any php-enabled web
server of your choiche.
You can even change the script to include the expected md5 signature
inside the code, in order to simplify the url. Otherwise you could
store the url with the checksum parameter in an easily accessible
place (del.icio.us?).
This is not a definitive solution, as it doesn't check the code
received by your browser, but the code received by somebody else (the
script in this case).
But I think it is a nice improvement, mainly because it makes
convenient enough to regularly verify the checksum; and this is an
habit that Clipperz users should carefully learn in order to grant
their data security.
What do you think about?
Giulio Cesare
[1] I use the term "certified" here very loosley.
It is enough to add the following line in the succees block:
echo("<script>setTimeout(\"window.location.replace('$pageUrl')\", (5 *
1000))</script>");
Attached the new version of the script.
Giulio Cesare
It would also be nice to have some type automated checksum system in
place. I've mentioned this before, but debian's APT system uses PGP
keys to verify that new releases are legitimate - something similar
could be useful to allow checksums for updated versions of the library
to be signed and downloaded by the proxy server so that you can make
changes to the code and have them be accepted by the proxy servers
without user intervention.
On Apr 21, 9:29 am, "Giulio Cesare Solaroli" <giulio.ces...@gmail.com>
wrote:
> On the online version of the script, I have just added an automatic
> redirect to the real application if the checksum verification succeed.
>
> It is enough to add the following line in the succees block:
> echo("<script>setTimeout(\"window.location.replace('$pageUrl')\", (5 *
> 1000))</script>");
>
> Attached the new version of the script.
>
> Giulio Cesare
>
> On 4/21/07, Giulio Cesare Solaroli <giulio.ces...@gmail.com> wrote:
>
> > Hi everybody,
>
> > we are working very hard to close the security cord around our application.
>
> > We started releasing the code, and we have recently added the full
> > build script, allowing anybody to check on her own that our code has
> > really being used to build the application available online.
>
> > But there is still one step missing: easily check that the code loaded
> > into the browser does match with the "certified"[1] checksum.
> > We are looking for a definitive answer, but we are not there, yet.
>
> > In the meanwhile, we have written a very simple php script that could
> > perform this check very easily. You can see it in action here:
> > - <http://www.clipperz.com/integrityCheck.php?md5=bdf19e25efbceae2e80e05...>
>
> > If you change the value of the md5 parameter you can see that the page
> > content changes immediately.
>
> > While this script is hosted on owr server, your confidence in the
> > security does not improve much; but attached to this message you can
> > find the full script, ready to be deployed on any php-enabled web
> > server of your choiche.
>
> > You can even change the script to include the expected md5 signature
> > inside the code, in order to simplify the url. Otherwise you could
> > store the url with the checksum parameter in an easily accessible
> > place (del.icio.us?).
>
> > This is not a definitive solution, as it doesn't check the code
> > received by your browser, but the code received by somebody else (the
> > script in this case).
> > But I think it is a nice improvement, mainly because it makes
> > convenient enough to regularly verify the checksum; and this is an
> > habit that Clipperz users should carefully learn in order to grant
> > their data security.
>
> > What do you think about?
>
> > Giulio Cesare
>
> > [1] I use the term "certified" here very loosley.
>
>
>
> integrityCheck.php
> 1KDownload
If the checksum didn't match, the extension could re-download the
current checksum from the server in case the file had been updated.
If that still didn't work, some sort of error message could be
displayed instructing the user to contact the signing authority and
advising against using the web page.
This would force an attacker to compromise the server, obtain the
private keyfile and obtain the key password. As long as the signing
authority used sensible security practices with they private key
(didn't store it on the server and used a secure password), the system
should stay secure. This system would require some trust in the
signing authority(ie, that they aren't using a null-password private
key that's publicly accessible), but would at least give users some
confidence that they were using uncorrupted files.
The nice thing about such an extension is that it could be used for
all sorts of web pages.
-Ryan
the firefox extension would definitely be a nice addition for our project.
But the distribution of the checksum should be thought very carefully,
as we have some very special constraint not usually found on other
projects.
We did like the idea of the checksum from the very beginning of the
project because it would allow to solve a long list of threats that a
project like Clipperz need to address:
- getting p0wned by some hackers/employees;
- phishing;
- sudden changes in the business policy of Clipperz;
- law enforcement subpoena to hack the application in order to leak some data.
The only problem left, is how to share the "right" checksum.
We could provide a reference value for the checksum, but a really
paranoid user should not trust it, as we would be able to update it
together with an hacked version of the application.
But we haven't settled down yet on how to conveniently balance the
simplicity of the service with the paranoia of the security.
Thanks for your attention.
Giulio Cesare
I like the idea of integrating code review and checksum
authentication. I would really appreciate having somewhere I could go
and read people's review of a codebase - it would be helpful to be
aware of vulnerabilites and strengths, and it would allow some
confidence in the codebase if it had been reviewed by multiple
reputable individuals. As a part of such a review, it would make
sense for anyone having reviewed the code to sign a checksum as a way
of ensuring what was reviewed and by whom.
I could imagine organizations which would review and sign codebase
checksums (possibly as a paid service) - you could tell your browser
to always accept checksums signed by a particular organization.
Alternately, for the uber-paranoid, they could review the code them
self and create their own signed checksum which would be the only
signature they would accept. This would be a pain when the library
changed, but that would be a trade-off which the user could make by
choosing whose signatures they allow on checksums.
I guess this is more of a long-term than immediate solution, but I
can't think of any simple way to create confidence that the code
you're using is both secure and authentic. I don't trust top-down
authentication (Microsoft comes to mind here) and a distributed system
would require infrastructure that simply isn't in place right now.
Maybe this could be another project...
-Ryan
On Jun 6, 11:54 am, "Giulio Cesare Solaroli" <giulio.ces...@gmail.com>
wrote:
> Hi Ryan,
>
> the firefox extension would definitely be a nice addition for our project.
>
> But the distribution of the checksum should be thought very carefully,
> as we have some very special constraint not usually found on other
> projects.
>
> We did like the idea of the checksum from the very beginning of the
> project because it would allow to solve a long list of threats that a
> project like Clipperz need to address:
> - getting p0wned by some hackers/employees;
> - phishing;
> - sudden changes in the business policy of Clipperz;
> - law enforcement subpoena to hack the application in order to leak some data.
>
> The only problem left, is how to share the "right" checksum.
>
> We could provide a reference value for the checksum, but a really
> paranoid user should not trust it, as we would be able to update it
> together with an hacked version of the application.
>
> But we haven't settled down yet on how to conveniently balance the
> simplicity of the service with the paranoia of the security.
>
> Thanks for your attention.
>
> Giulio Cesare
>