From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konstantin Kliakhandler Subject: Re: Why no secure code retrieval Date: Mon, 4 Jul 2016 09:15:57 +0300 Message-ID: References: <87mvm4sewl.fsf@systemreboot.net> <87y45m28vp.fsf@saiph.selenimh> <87lh1k5dj1.fsf@free.fr> <20160702165130.GA1401@scamper2.bantercat.co.uk> <87eg7bnqob.fsf@free.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1142df1e04a0ae0536c945b3 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48590) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJxAo-0001HO-6G for emacs-orgmode@gnu.org; Mon, 04 Jul 2016 02:16:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bJxAl-0006SC-Ji for emacs-orgmode@gnu.org; Mon, 04 Jul 2016 02:16:01 -0400 Received: from mail-it0-x233.google.com ([2607:f8b0:4001:c0b::233]:36043) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bJxAl-0006Rw-CK for emacs-orgmode@gnu.org; Mon, 04 Jul 2016 02:15:59 -0400 Received: by mail-it0-x233.google.com with SMTP id g4so14162951ith.1 for ; Sun, 03 Jul 2016 23:15:58 -0700 (PDT) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Robert Horn Cc: Arun Isaac , Bastien , Stromeko@nexgo.de, emacs-orgmode@gnu.org, Nicolas Goaziou , Ian Barton --001a1142df1e04a0ae0536c945b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the clarification and the detailed analysis. Sounds like you did you homework - I have a lot lo learn. Anyway, I would say that we agree on most points, and I'm more than content to leave it at that :-). Best Regards, Kosta -- )=C2=B0))=C2=B0((=C2=B0( Konstantin Kliakhandler Sent on the go. On Jul 4, 2016 03:17, "Robert Horn" wrote: > > Konstantin Kliakhandler writes: > > > > > Sufficient for what? I believe we were discussing security (that was my > > intention at least, and so did your previous email seem to indicate). A= nd > > if this is the case, you have just contradicted yourself. I apologize f= or > > pointing it out so directly, and also if I misunderstood you. > > Sufficient for current risk mitigation in my opinion. You disagree. > > We both agree that signed tags would be better. > > Choices are based on an evaluation of risks, threats, and mitigation > costs. Emacs has had very few security vulnerabilities > discovered. There are only 18 CVE since 2000. None of these allowed > priviledge escalation, and the two most severe required local user > assistance. So org-mode is not in a high risk location. > > That means that I look for very low cost steps, i.e., very simple easy > changes. Signing tags falls into that category because it only affects > a few people and is not particularly difficult to manage for very small > groups. > > Another step that I would take is to establish and publish the planned > security processes. These should be established and understood well > before any event takes place. Taking adhoc reactive steps in an > emergency often causes more problems. > > > I believe that these days elpa is accessed by default via https and tha= t > > archives are signed, though please correct me here. Assuming it is the > > case, there isn't much one can do beyond the currently suggested steps,= I > > think. > > > > I took a quick look inside package.el and it is still incomplete. It's > also got a big todo list, so I expect this to change with subsequent > releases. As of Emacs 24.3 ELPA did not have package signatures. Emacs > 24.5 has package signatures, but no way for the user to verify that what > is installed matches the signature. > > As of 24.5, the default behavior in package.el is: > - package signatures are optional > - package signatures are only checked to confirm that the tar file that > is downloaded matches the signature. There is no tooling for subsequent > verifications. > - invalid signatures are ignored by default > - missing signatures are ignored by default > - package.el has dependencies on programs external to emacs. If these > dependencies are not met, it reverts to default behavior. > > This is clearly better than 24.3. > > Again, in terms of risk/cost/mitigation evaluation I would have the tool > that creates the ELPA package for org-mode also create a signature. It > might do that already. Package.el does not indicate which packages are > signed. I would let the folks taking care of ELPA deal with the rest in > later releases. > > Use of https for most ELPA repositories does protect against in transit > content corruption, but not necessarily much else. Looking at > elpa.gnu.org I notice: > - Their certificate expired today and has not been updated, oops > - They use Let's Encrypt as signing authority. This means that the > certificate verifies that whoever responds to the domain name http port > controls the TLS certificate and web content. That's enough for > many purposes, but it doesn't mean much in terms of server security. > > In transit MITM is a minor threat for software distribution. I've only > detected MITM activity in public locations once in the real world. (I > was thrilled. It's a really rare event.) It was in a very high threat > location (Washington DC area, a public wifi). > > The big MITM threat is the dangers from malicious javascript insertion > into unprotected browser activity. > > R Horn > rjhorn@alum.mit.edu > --001a1142df1e04a0ae0536c945b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks for the clarification and the detailed analysis. Soun= ds like you did you homework - I have a lot lo learn. Anyway, I would say t= hat we agree on most points, and I'm more than content to leave it at t= hat :-).

Best Regards,
Kosta

--=C2=A0
)=C2=B0))=C2=B0((=C2=B0(=C2=A0
Konstantin Kliakhandler
Sent on the go.

On Jul 4, 2016 03:17, "Robert Horn" &l= t;rjhorn@alum.mit.edu> wrote:=

Konstantin Kliakhandler writes:

>
> Sufficient for what? I believe we were discussing security (that was m= y
> intention at least, and so did your previous email seem to indicate). = And
> if this is the case, you have just contradicted yourself. I apologize = for
> pointing it out so directly, and also if I misunderstood you.

Sufficient for current risk mitigation in my opinion.=C2=A0 You disagree.
We both agree that signed tags would be better.

Choices are based on an evaluation of risks, threats, and mitigation
costs.=C2=A0 Emacs has had very few security vulnerabilities
discovered. There are only 18 CVE since 2000.=C2=A0 None of these allowed priviledge escalation, and the two most severe required local user
assistance.=C2=A0 So org-mode is not in a high risk location.

That means that I look for very low cost steps, i.e., very simple easy
changes.=C2=A0 Signing tags falls into that category because it only affect= s
a few people and is not particularly difficult to manage for very small
groups.

Another step that I would take is to establish and publish the planned
security processes.=C2=A0 These should be established and understood well before any event takes place.=C2=A0 Taking adhoc reactive steps in an
emergency often causes more problems.

> I believe that these days elpa is accessed by default via https and th= at
> archives are signed, though please correct me here. Assuming it is the=
> case, there isn't much one can do beyond the currently suggested s= teps, I
> think.
>

I took a quick look inside package.el and it is still incomplete.=C2=A0 It&= #39;s
also got a big todo list, so I expect this to change with subsequent
releases.=C2=A0 As of Emacs 24.3 ELPA did not have package signatures.=C2= =A0 Emacs
24.5 has package signatures, but no way for the user to verify that what is installed matches the signature.

As of 24.5, the default behavior in package.el is:
=C2=A0- package signatures are optional
=C2=A0- package signatures are only checked to confirm that the tar file th= at
=C2=A0is downloaded matches the signature.=C2=A0 There is no tooling for su= bsequent
=C2=A0verifications.
=C2=A0- invalid signatures are ignored by default
=C2=A0- missing signatures are ignored by default
=C2=A0- package.el has dependencies on programs external to emacs.=C2=A0 If= these
=C2=A0dependencies are not met, it reverts to default behavior.

This is clearly better than 24.3.

Again, in terms of risk/cost/mitigation evaluation I would have the tool that creates the ELPA package for org-mode also create a signature.=C2=A0 I= t
might do that already.=C2=A0 Package.el does not indicate which packages ar= e
signed.=C2=A0 I would let the folks taking care of ELPA deal with the rest = in
later releases.

Use of https for most ELPA repositories does protect against in transit
content corruption, but not necessarily much else.=C2=A0 Looking at
elpa.g= nu.org I notice:
=C2=A0- Their certificate expired today and has not been updated, oops
=C2=A0- They use Let's Encrypt as signing authority.=C2=A0 This means t= hat the
=C2=A0certificate verifies that whoever responds to the domain name http po= rt
=C2=A0controls the TLS certificate and web content.=C2=A0 That's enough= for
=C2=A0many purposes, but it doesn't mean much in terms of server securi= ty.

In transit MITM is a minor threat for software distribution.=C2=A0 I've= only
detected MITM activity in public locations once in the real world.=C2=A0 (I=
was thrilled.=C2=A0 It's a really rare event.)=C2=A0 It was in a very h= igh threat
location (Washington DC area, a public wifi).

The big MITM threat is the dangers from malicious javascript insertion
into unprotected browser activity.

R Horn
rjhorn@alum.mit.edu
--001a1142df1e04a0ae0536c945b3--