Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 15 Aug 2013 10:30:19 -0600
From: Kurt Seifried <>
Subject: Re: HTTPS

Hash: SHA1

Ah you appear to be making two classical mistakes. You are confusing
technical means for enforcing policy (e.g. security policy, privacy
policy) with the actual policy itself. You are also making the second
classical mistake of "one size fits all", what you see as valid
security policy (anonymous access must be unencrypted, login access
MUST be encrypted) is what you think the entire world should use.

This is obviously not the case. Some organizations may be very
concerned with availability and exfiltration of data and ban ANY
encryption, some sites may be very concerned with the privacy and
integrity of their data and require mandatory encryption of their data
in transit, at rest, and so on. Who is right? Both are.

Technical measures like encryption are simply a means of enforcing
policy/laws/etc, First you decide on your policy (and take into
account any laws/etc.), then you find technical means to achieve that
policy. Not the other way around.

So in this case the policy can probably be stated as:

"When someone downloads a ruby gem via the system we want
to ensure they get the gem they requested, and not one that an
attacker has modified."

So one way to achieve this policy would be gem code signing. Several
efforts to implement this started and failed due to lack of community
support/etc., due in large part to people confusing technical measures
with policy, e.g. people were arguing the use of various cryptographic
primitives before they'd answered questions like "do we require end
developers to participate in this, or do we just involve
do we want end to end signing?" and so on.

Obviously none of this progressed. So now I think the best option is
to harden the existing system as best we can to protect users.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Version: GnuPG v1.4.14 (GNU/Linux)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.