From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp88.iad3a.emailsrvr.com (smtp88.iad3a.emailsrvr.com [173.203.187.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 6427C21F237 for ; Fri, 11 Apr 2014 12:43:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp20.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 986891004BD; Fri, 11 Apr 2014 15:43:19 -0400 (EDT) X-Virus-Scanned: OK Received: from app17.wa-webapps.iad3a (relay.iad3a.rsapps.net [172.27.255.110]) by smtp20.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 774B91004D7; Fri, 11 Apr 2014 15:43:19 -0400 (EDT) Received: from reed.com (localhost.localdomain [127.0.0.1]) by app17.wa-webapps.iad3a (Postfix) with ESMTP id 6089E280058; Fri, 11 Apr 2014 15:43:19 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Fri, 11 Apr 2014 15:43:19 -0400 (EDT) Date: Fri, 11 Apr 2014 15:43:19 -0400 (EDT) From: dpreed@reed.com To: "Dave Taht" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20140411154319000000_59121" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: Message-ID: <1397245399.392818481@apps.rackspace.com> X-Mailer: webmail7.0 Cc: "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Bloat] [Cerowrt-devel] wired article about bleed and bloat and underfunded critical infrastructure X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 19:43:45 -0000 ------=_20140411154319000000_59121 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AI'm afraid it's not *just* underfunded. I reviewed the details of the = code involved and the fixes, and my conclusion is that even programmers of = security software have not learned how to think about design, testing, etc.= Especially the continuing use of C in a large shared process address spac= e for writing protocols that are by definition in the "security kernel" (ac= cording to the original definition) of applications on which the public dep= ends.=0A =0AEver since I was part of the Multics Security Project (which wa= s part of the effort that produced the Orange Book http://csrc.nist.gov/pub= lications/history/dod85.pdf) in the 80's, we've known that security-based c= ode should not be exposed to user code and vice versa. Yet the SSL librari= es are linked in, in userspace, with the application code.=0A =0AAlso, upgr= ades/changes to protocols related to security (which always should have bee= n in place on every end-to-end connection) should be reviewed *both at the = protocol design level* and also at the *implementation level* because chang= e creates risk. They should not be adopted blindly without serious examina= tion and pen-testing, yet this change just was casually thrown in in a patc= h release.=0A =0AI suspect that even if it were well funded, the folks who = deploy the technology would be slapdash at best. Remember the Y2K issue and= the cost of lazy thinking about dates. (I feel a little superior because i= n 1968 Multics standardized on a 72-bit hardware microsecond-resolution har= dware clock because the designers actually thought about long-lived systems= (actually only 56 bits of the original clock worked, but the hardware was = not expected to last until the remaining bits could be added)).=0A =0AThe o= pen source movement, unfortunately, made a monoculture of the SSL source co= de, so it's much more dangerous and the vulnerable attack surface of deploy= ments is enormous.=0A =0ARant off. The summary is that good engineering is= not applied where it must be for the public interest. That remains true e= ven if the NSA actually snuck this code into the SSL implementation.=0A=0A= =0AOn Friday, April 11, 2014 2:22pm, "Dave Taht" said= :=0A=0A=0A=0A> http://www.wired.com/2014/04/heartbleedslesson/=0A> =0A> And= Dan Kaminisky writes about "Code in the Age of Cholera"=0A> =0A> http://da= nkaminsky.com/2014/04/10/heartbleed/=0A> =0A> =0A> =0A> --=0A> Dave T=C3=A4= ht=0A> _______________________________________________=0A> Cerowrt-devel ma= iling list=0A> Cerowrt-devel@lists.bufferbloat.net=0A> https://lists.buffer= bloat.net/listinfo/cerowrt-devel=0A> ------=_20140411154319000000_59121 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I'm afraid= it's not *just* underfunded.   I reviewed the details of the code inv= olved and the fixes, and my conclusion is that even programmers of security= software have not learned how to think about design, testing, etc.  E= specially the continuing use of C in a large shared process address space f= or writing protocols that are by definition in the "security kernel" (accor= ding to the original definition) of applications on which the public depend= s.

=0A

 

=0A

Ever since I was part of the Multics Security Project (which w= as part of the effort that produced the Orange Book http://csrc.nist.g= ov/publications/history/dod85.pdf) in the 80's, we've known that security-b= ased code should not be exposed to user code and vice versa.  Yet the = SSL libraries are linked in, in userspace, with the application code.

= =0A

 

=0A

Also, upgrades/changes to protocols related to security (which alway= s should have been in place on every end-to-end connection) should be revie= wed *both at the protocol design level* and also at the *implementation lev= el* because change creates risk.  They should not be adopted blindly w= ithout serious examination and pen-testing, yet this change just was casual= ly thrown in in a patch release.

=0A

&nb= sp;

=0A

I suspect that even if it were w= ell funded, the folks who deploy the technology would be slapdash at best. = Remember the Y2K issue and the cost of lazy thinking about dates. (I feel a= little superior because in 1968 Multics standardized on a 72-bit hardware = microsecond-resolution hardware clock because the designers actually though= t about long-lived systems (actually only 56 bits of the original clock wor= ked, but the hardware was not expected to last until the remaining bits cou= ld be added)).

=0A

 

=0A

The open source movement, unfortunately, made a mo= noculture of the SSL source code, so it's much more dangerous and the vulne= rable attack surface of deployments is enormous.

=0A

 

=0A

Rant off.  = The summary is that good engineering is not applied where it must be for th= e public interest.  That remains true even if the NSA actually snuck t= his code into the SSL implementation.

=0A=0A


=
On Friday, April 11, 2014 2:22pm, "Dave Taht" <dave.taht@gmail.com= > said:

=0A
=0A

> http://www.wired.com/2014/04/heartbleedslesso= n/
>
> And Dan Kaminisky writes about "Code in the Age of = Cholera"
>
> http://dankaminsky.com/2014/04/10/heartbleed/=
>
>
>
> --
> Dave T=C3=A4ht
> _______________________________________________
> Cerowrt-de= vel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> ht= tps://lists.bufferbloat.net/listinfo/cerowrt-devel
>

=0A
------=_20140411154319000000_59121--