[Cryptography] cryptography Digest, Vol 12, Issue 9

Peter Trei petertrei at gmail.com
Thu Apr 10 18:29:39 EDT 2014


iang wrote:

- start quote -
While everyone's madly rushing around to fix their bits&bobs, I'd
encouraged you all to be alert to any evidence of *damages* either
anecdotally or more firm.  By damages, I mean (a) rework needed to
secure, and (b) actual breach into sites and theft of secrets, etc,
leading to (c) theft of property/money/value etc.

In risk analysis, we lean very heavily on firm indications of actual,
tangible damages, because risk analysis is an uncertain tool and the
security industry is a FUD-driven sector.  Where we have actual
experiences of lost money, time, destruction of property or whatever,
this puts us in a much better position to predict what is worth spending
money to protect.
- end quote -

There are now suggestions that Heartbleed has been exploited in the
wild:

https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agencies-using-heartbleed-november-2013

Even if this is not the case, I reject iang's (facetious, I know :-)
suggestion.
Security flaws aren't the same as tsunamis. Reporting a power station's
possible vulnerability to the former doesn't make tsunamis more likely.
However, the wide dissemination of a previously unknown security
flaw *does* make its future attempted exploitation a near certainty.

pt



On Wed, Apr 9, 2014 at 12:00 PM, <cryptography-request at metzdowd.com> wrote:

> Send cryptography mailing list submissions to
>         cryptography at metzdowd.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://www.metzdowd.com/mailman/listinfo/cryptography
> or, via email, send a message with subject or body 'help' to
>         cryptography-request at metzdowd.com
>
> You can reach the person managing the list at
>         cryptography-owner at metzdowd.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cryptography digest..."
>
>
> Today's Topics:
>
>    1. Re: The Heartbleed Bug is a serious vulnerability in OpenSSL
>       (ianG)
>    2. Re: The Heartbleed Bug is a serious vulnerability in OpenSSL
>       (Jonathan Thornburg)
>    3. Re: The Heartbleed Bug is a serious vulnerability in OpenSSL
>       (tpb-crypto at laposte.net)
>    4. Re: The Heartbleed Bug is a serious vulnerability in OpenSSL
>       (tpb-crypto at laposte.net)
>    5. Re: The Heartbleed Bug is a serious vulnerability in OpenSSL
>       (tpb-crypto at laposte.net)
>    6. Re: The Heartbleed Bug is a serious vulnerability in OpenSSL
>       (ianG)
>    7. Re: [cryptography] The Heartbleed Bug is a serious
>       vulnerability in OpenSSL (ianG)
>    8. Re: The Heartbleed Bug is a serious vulnerability in OpenSSL
>       (ianG)
>    9. Re: TLS/DTLS Use Cases (Nico Williams)
>   10. Re: [cryptography] The Heartbleed Bug is a serious
>       vulnerability in OpenSSL (Nico Williams)
>   11. Re: The Heartbleed Bug is a serious vulnerability in      OpenSSL
>       (Tom Mitchell)
>   12. Re: The Heartbleed Bug is a serious vulnerability in      OpenSSL
>       (Jerry Leichter)
>   13. Re: TLS/DTLS Use Cases (Bear)
>   14. Re: OpenPGP and trust (Bear)
>   15. Re: The Heartbleed Bug is a serious vulnerability in OpenSSL
>       (Dave Horsfall)
>   16. Re: The Heartbleed Bug is a serious vulnerability in OpenSSL
>       (Paul Ferguson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 08 Apr 2014 11:46:49 +0100
> From: ianG <iang at iang.org>
> To: cryptography at metzdowd.com, cryptography at randombit.net
> Subject: Re: [Cryptography] The Heartbleed Bug is a serious
>         vulnerability in OpenSSL
> Message-ID: <5343D399.8010702 at iang.org>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 7/04/2014 22:53 pm, Edwin Chu wrote:
> > Hi
> >
> > A latest story for OpenSSL
> >
> > http://heartbleed.com/
> >
> >     The Heartbleed Bug is a serious vulnerability in the popular OpenSSL
> >     cryptographic software library. This weakness allows stealing the
> >     information protected, under normal conditions, by the SSL/TLS
> >     encryption used to secure the Internet. SSL/TLS provides
> >     communication security and privacy over the Internet for
> >     applications such as web, email, instant messaging (IM) and some
> >     virtual private networks (VPNs).
> >
> >     The Heartbleed bug allows anyone on the Internet to read the memory
> >     of the systems protected by the vulnerable versions of the OpenSSL
> >     software. This compromises the secret keys used to identify the
> >     service providers and to encrypt the traffic, the names and
> >     passwords of the users and the actual content. This allows attackers
> >     to eavesdrop communications, steal data directly from the services
> >     and users and to impersonate services and users.
>
>
> We have here a rare case of a broad break in a security protocol leading
> to compromise of keys.
>
> While everyone's madly rushing around to fix their bits&bobs, I'd
> encouraged you all to be alert to any evidence of *damages* either
> anecdotally or more firm.  By damages, I mean (a) rework needed to
> secure, and (b) actual breach into sites and theft of secrets, etc,
> leading to (c) theft of property/money/value etc.
>
> In risk analysis, we lean very heavily on firm indications of actual,
> tangible damages, because risk analysis is an uncertain tool and the
> security industry is a FUD-driven sector.  Where we have actual
> experiences of lost money, time, destruction of property or whatever,
> this puts us in a much better position to predict what is worth spending
> money to protect.
>
> E.g., if we cannot show any damages from this breach, it isn't worth
> spending a penny on it to fix!  Yes, that's outrageous and will be
> widely ignored ... but it is economically and scientifically sound, at
> some level.
>
> I maintain a risk history here: http://wiki.cacert.org/Risk/History for
> the CA field, so if anyone can find any real damages effecting the CA
> world, let me know!
>
>
>
> iang
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 8 Apr 2014 13:12:25 -0400
> From: Jonathan Thornburg <jthorn at astro.indiana.edu>
> To: cryptography at metzdowd.com, cryptography at randombit.net
> Subject: Re: [Cryptography] The Heartbleed Bug is a serious
>         vulnerability in OpenSSL
> Message-ID: <20140408171208.GA927 at copper.astro.indiana.edu>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Apr 08, 2014 at 11:46:49AM +0100, ianG wrote:
> > While everyone's madly rushing around to fix their bits&bobs, I'd
> > encouraged you all to be alert to any evidence of *damages* either
> > anecdotally or more firm.  By damages, I mean (a) rework needed to
> > secure, and (b) actual breach into sites and theft of secrets, etc,
> > leading to (c) theft of property/money/value etc.
> >
> [[...]]
> >
> > E.g., if we cannot show any damages from this breach, it isn't worth
> > spending a penny on it to fix!
>
> This analysis appears to say that it's not worth spending money to
> fix a hole (bug) unless either money has already been spent or damages
> have *already* occured.  This ignores possible or probable (or even
> certain!) *future* damages if no rework has yet happened.
>
> This seems like a flawed risk analysis to me.
>
> In particular, this analysis could be used to argue against spending any
> money trying to reduce risk or damages from rare events which haven't
> happened yet.  For example, as of January 1, 2011 (= 69 days before the
> Fukushima Daiichi disaster), this analysis would have said that since no
> nuclear reactor in the world has ever been damaged by a tsunami (a true
> statement on that date), it isn't worth spending any money trying to
> secure nuclear reactors against tsunami damage.
>
> --
> -- "Jonathan Thornburg [remove -animal to reply]" <
> jthorn at astro.indiana-zebra.edu>
>    Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
>    "There was of course no way of knowing whether you were being watched
>     at any given moment.  How often, or on what system, the Thought Police
>     plugged in on any individual wire was guesswork.  It was even
> conceivable
>     that they watched everybody all the time."  -- George Orwell, "1984"
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 08 Apr 2014 21:18:52 +0200
> From: tpb-crypto at laposte.net
> To: ianG <iang at iang.org>, cryptography at metzdowd.com,
>         cryptography at randombit.net
> Subject: Re: [Cryptography] The Heartbleed Bug is a serious
>         vulnerability in OpenSSL
> Message-ID: <1316776432.92614.1396984732457.JavaMail.www at wwinf8313>
> Content-Type: text/plain; charset=UTF-8
>
> > Message du 08/04/14 18:44
> > De : "ianG"
> >
> > E.g., if we cannot show any damages from this breach, it isn't worth
> > spending a penny on it to fix! Yes, that's outrageous and will be
> > widely ignored ... but it is economically and scientifically sound, at
> > some level.
> >
>
> So, let's wait until another 40 million credit cards are stolen, then we
> prove this method was used exactly, then we will try to fix it in all
> deployments ... yeah, seems reasonable.
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 08 Apr 2014 22:02:24 +0200
> From: tpb-crypto at laposte.net
> To: ianG <iang at iang.org>, cryptography at metzdowd.com,
>         cryptography at randombit.net
> Subject: Re: [Cryptography] The Heartbleed Bug is a serious
>         vulnerability in OpenSSL
> Message-ID: <501480181.95836.1396987343949.JavaMail.www at wwinf8313>
> Content-Type: text/plain; charset=UTF-8
>
> > Message du 08/04/14 21:42
> > De : "ianG"
> > A : tpb-crypto at laposte.net, cryptography at metzdowd.com,
> cryptography at randombit.net
> > Copie ? :
> > Objet : Re: [Cryptography] The Heartbleed Bug is a serious vulnerability
> in OpenSSL
> >
> > On 8/04/2014 20:18 pm, tpb-crypto at laposte.net wrote:
> > >> Message du 08/04/14 18:44
> > >> De : "ianG"
> > >>
> > >> E.g., if we cannot show any damages from this breach, it isn't worth
> > >> spending a penny on it to fix! Yes, that's outrageous and will be
> > >> widely ignored ... but it is economically and scientifically sound, at
> > >> some level.
> > >>
> > >
> > > So, let's wait until another 40 million credit cards are stolen, then
> we prove this method was used exactly, then we will try to fix it in all
> deployments ... yeah, seems reasonable.
> >
> >
> > Well, be blind if you like. But 40 million stolen credit cards are
> > measurable, are damages, and are directly relatable by statistical
> > models to theft damages.
> >
> > My advice is when you have a number like 40m in front of you, then you
> > should DO SOMETHING. Spend a penny, dude!
> >
>
> Your first advice is extremely dangerous and preposterous, I was being
> sardonic in my comment, but let's get this straight.
>
> You said you control a quite famous bug list. I should not ask this here,
> but considering the situation we found ourselves regarding encryption
> infrastructure abuse from the part of US government ... I'm just curious
> and can't resist it.
>
> How much are you being paid to give such dangerous and preposterous
> advice? Or, who are your handlers?
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 08 Apr 2014 22:35:46 +0200
> From: tpb-crypto at laposte.net
> To: ianG <iang at iang.org>, cryptography at metzdowd.com,
>         cryptography at randombit.net
> Subject: Re: [Cryptography] The Heartbleed Bug is a serious
>         vulnerability in OpenSSL
> Message-ID: <1903091161.97701.1396989346005.JavaMail.www at wwinf8313>
> Content-Type: text/plain; charset=UTF-8
>
>
>
> > Message du 08/04/14 22:18
> > De : "ianG"
> > A : tpb-crypto at laposte.net, cryptography at metzdowd.com,
> cryptography at randombit.net
> > Copie ? :
> > Objet : Re: [Cryptography] The Heartbleed Bug is a serious vulnerability
> in OpenSSL
> >
>
> > On 8/04/2014 21:02 pm, tpb-crypto at laposte.net wrote:
> >
> > > You said you control a quite famous bug list.
> >
> >
> > Not me, you might be thinking of the other iang?
> >
> > > I should not ask this here, but considering the situation we found
> ourselves regarding encryption infrastructure abuse from the part of US
> government ... I'm just curious and can't resist it.
> >
> > the shoe turns, the knife fits...
> >
> > > How much are you being paid to give such dangerous and preposterous
> advice? Or, who are your handlers?
> >
> >
> > Nothing, nix. I wish. Please!?
> >
> > At this stage it is customary to post a bitcoin address but I don't even
> > have one of them....
> >
> >
>
> Interesting way to try avoid answering about the subject directly. You
> should know that bad advice is noticed and sooner than you may think, your
> reputation falls between your fingers like sand and nobody will pay
> attention to your crazy rants anymore.
>
> Which is a good payout for someone that sells his soul for so little.
>
> Regarding automated exploit tools that will be used to cause enormous
> damage related to this bug, well they are already being devised and are in
> their earliest stages, but perfectly workable:
>
> https://www.mattslifebytes.com/?p=533
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 08 Apr 2014 20:42:10 +0100
> From: ianG <iang at iang.org>
> To: tpb-crypto at laposte.net, cryptography at metzdowd.com,
>         cryptography at randombit.net
> Subject: Re: [Cryptography] The Heartbleed Bug is a serious
>         vulnerability in OpenSSL
> Message-ID: <53445112.9090904 at iang.org>
> Content-Type: text/plain; charset=UTF-8
>
> On 8/04/2014 20:18 pm, tpb-crypto at laposte.net wrote:
> >> Message du 08/04/14 18:44
> >> De : "ianG"
> >>
> >> E.g., if we cannot show any damages from this breach, it isn't worth
> >> spending a penny on it to fix! Yes, that's outrageous and will be
> >> widely ignored ... but it is economically and scientifically sound, at
> >> some level.
> >>
> >
> > So, let's wait until another 40 million credit cards are stolen, then we
> prove this method was used exactly, then we will try to fix it in all
> deployments ... yeah, seems reasonable.
>
>
> Well, be blind if you like.  But 40 million stolen credit cards are
> measurable, are damages, and are directly relatable by statistical
> models to theft damages.
>
> My advice is when you have a number like 40m in front of you, then you
> should DO SOMETHING.  Spend a penny, dude!
>
>
>
> iang
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 08 Apr 2014 21:10:33 +0100
> From: ianG <iang at iang.org>
> To: Nico Williams <nico at cryptonector.com>,      Jonathan Thornburg
>         <jthorn at astro.indiana.edu>
> Cc: cryptography at metzdowd.com, cryptography at randombit.net
> Subject: Re: [Cryptography] [cryptography] The Heartbleed Bug is a
>         serious vulnerability in OpenSSL
> Message-ID: <534457B9.8040006 at iang.org>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 8/04/2014 20:33 pm, Nico Williams wrote:
> > On Tue, Apr 08, 2014 at 01:12:25PM -0400, Jonathan Thornburg wrote:
> >> On Tue, Apr 08, 2014 at 11:46:49AM +0100, ianG wrote:
> >>> While everyone's madly rushing around to fix their bits&bobs, I'd
> >>> encouraged you all to be alert to any evidence of *damages* either
> >>> anecdotally or more firm.  By damages, I mean (a) rework needed to
> >>> secure, and (b) actual breach into sites and theft of secrets, etc,
> >>> leading to (c) theft of property/money/value etc.
> >>>
> >> [[...]]
> >>>
> >>> E.g., if we cannot show any damages from this breach, it isn't worth
> >>> spending a penny on it to fix!
> >>
> >> This analysis appears to say that it's not worth spending money to
> >> fix a hole (bug) unless either money has already been spent or damages
> >> have *already* occured.  This ignores possible or probable (or even
> >> certain!) *future* damages if no rework has yet happened.
> >
> > The first part (gather data) is OK.  The second I thought was said
> > facetiously.  It is flawed, indeed, but it's also true that people have
> > a hard time weighing intangibles.
>
>
> Right, exactly.  Thought experiment.
>
>
> > I don't know how we can measure anything here.  How do you know if your
> > private keys were stolen via this bug?  It should be possible to
> > establish whether key theft was feasible, but establishing whether they
> > were stolen might require evidence of use of stolen keys, and that might
> > be very difficult to come by.
>
>
> Precisely, that is the question.  What happens if we wait a year and
> nothing .. happens?
>
> What happened with the Debian random plonk?  Nothing, that I ever saw in
> terms of measurable damages.  The BEAST thing?  Twitter, was it?
>
> What happened with PKI?  We (I) watched and watched and watched ... and
> it wasn't until about 2011 that something finally popped up that was a
> measurable incident of damages, 512bit RSA keys being crunched from memory.
>
> That's 16 years!  Does that mean (a) PKI was so good that it clobbered
> all attacks, or (b) PKI was so unnecessary because there was nobody
> interested in attacks?
>
> Dan Geer once said on this list [0]:
>
>     "The design goal for any security system is that the number of
> failures is small but non-zero, i.e., N>0. If the number of failures is
> zero, there is no way to disambiguate good luck from spending too much.
> Calibration requires differing outcomes."
>
> We now have what amounts to a *fantastic* opportunity <ghoulish laugh>
> to clarify delta.  We've got a system wide breach, huge statistics, and
> it's identifiable in terms of which servers are vulnerable.
>
> Hypothesize:  Let the number of attacked servers be 1% of population of
> vulnerable servers.  Let our detection rate be 1%.  Multiply.  That
> means 1 in 10,000 attacked servers.  Let's say we have 1m vulnerable
> servers.
>
> We should detect 100 attacks over the next period.
>
> We should detect something!
>
>
> > We shouldn't wait for evidence of use of
> > stolen keys!
>
>
> (Well, right.  I doubt we can actually tell anyone to wait.)
>
> > Nico
>
>
>
>
> iang
>
>
>
> [0] http://financialcryptography.com/mt/archives/001255.html
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 08 Apr 2014 21:17:59 +0100
> From: ianG <iang at iang.org>
> To: tpb-crypto at laposte.net, cryptography at metzdowd.com,
>         cryptography at randombit.net
> Subject: Re: [Cryptography] The Heartbleed Bug is a serious
>         vulnerability in OpenSSL
> Message-ID: <53445977.9030904 at iang.org>
> Content-Type: text/plain; charset=UTF-8
>
> On 8/04/2014 21:02 pm, tpb-crypto at laposte.net wrote:
>
> > You said you control a quite famous bug list.
>
>
> Not me, you might be thinking of the other iang?
>
> > I should not ask this here, but considering the situation we found
> ourselves regarding encryption infrastructure abuse from the part of US
> government ... I'm just curious and can't resist it.
>
> the shoe turns, the knife fits...
>
> > How much are you being paid to give such dangerous and preposterous
> advice? Or, who are your handlers?
>
>
> Nothing, nix.  I wish.  Please!?
>
> At this stage it is customary to post a bitcoin address but I don't even
> have one of them....
>
>
>
> iang
>
>
>
> ------------------------------
>
> Message: 9
> Date: Tue, 8 Apr 2014 14:21:20 -0500
> From: Nico Williams <nico at cryptonector.com>
> To: Bear <bear at sonic.net>
> Cc: Bill Stewart <billstewart at pobox.com>,       Cryptography List
>         <cryptography at metzdowd.com>
> Subject: Re: [Cryptography] TLS/DTLS Use Cases
> Message-ID: <20140408192118.GI7962 at localhost>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Apr 08, 2014 at 12:12:54PM -0700, Bear wrote:
> > On Sat, 2014-04-05 at 18:23 -0500, Nico Williams wrote:
> > > Also, HTTP is just about the worst datagram protocol ever.  There's no
> > > XID, so responses have to be sent in the same order as requests over
> > > any one keptalive TCP connection.  Yuck.  (When I've brought this up
> > > in the context of HTTPbis I've been told to go away.)
> >
> > To be fair, keep-alive was not part of the design.  Http was initially
> > a completely stateless protocol, and actually a fairly well designed
> > one.  The reason keep-alive is not well supported is because it's got
> > nothing to do with the original design and was bolted on as an
> > afterthought.
>
> It was added as a new minor version of the protocol.  That would tend to
> indicate (to me anyways) that it wasn't an afterthought.
>
> > Is there a take-home lesson there?  Only that if we engage in elegant
> > design we should not trust those who come after us not to screw it up.
>
> Are you saying that HTTP/1.0 was elegant?  Well, I suppose it was, if we
> ignore all the complexity of text, line-oriented headers (the two ways
> to express multiple header values, continuation lines, verbosity).  The
> elegant part is the REST/CRUD aspects, IMO.
>
> Anyways, the part that interests me here is that there's still no
> interest in fixing this, particularly when HTTP/2.0 is so much about
> performance.  Perhaps the lesson is that we don't learn from our
> lessons.
>
> (I haven't checked recently, so it's possible that this has been
> addressed since.  I sure hope so!)
>
> Nico
> --
>
>
> ------------------------------
>
> Message: 10
> Date: Tue, 8 Apr 2014 14:33:42 -0500
> From: Nico Williams <nico at cryptonector.com>
> To: Jonathan Thornburg <jthorn at astro.indiana.edu>
> Cc: cryptography at metzdowd.com, cryptography at randombit.net
> Subject: Re: [Cryptography] [cryptography] The Heartbleed Bug is a
>         serious vulnerability in OpenSSL
> Message-ID: <20140408193339.GJ7962 at localhost>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Apr 08, 2014 at 01:12:25PM -0400, Jonathan Thornburg wrote:
> > On Tue, Apr 08, 2014 at 11:46:49AM +0100, ianG wrote:
> > > While everyone's madly rushing around to fix their bits&bobs, I'd
> > > encouraged you all to be alert to any evidence of *damages* either
> > > anecdotally or more firm.  By damages, I mean (a) rework needed to
> > > secure, and (b) actual breach into sites and theft of secrets, etc,
> > > leading to (c) theft of property/money/value etc.
> > >
> > [[...]]
> > >
> > > E.g., if we cannot show any damages from this breach, it isn't worth
> > > spending a penny on it to fix!
> >
> > This analysis appears to say that it's not worth spending money to
> > fix a hole (bug) unless either money has already been spent or damages
> > have *already* occured.  This ignores possible or probable (or even
> > certain!) *future* damages if no rework has yet happened.
>
> The first part (gather data) is OK.  The second I thought was said
> facetiously.  It is flawed, indeed, but it's also true that people have
> a hard time weighing intangibles.
>
> I don't know how we can measure anything here.  How do you know if your
> private keys were stolen via this bug?  It should be possible to
> establish whether key theft was feasible, but establishing whether they
> were stolen might require evidence of use of stolen keys, and that might
> be very difficult to come by.  We shouldn't wait for evidence of use of
> stolen keys!
>
> Nico
> --
>
>
> ------------------------------
>
> Message: 11
> Date: Tue, 8 Apr 2014 15:32:11 -0700
> From: Tom Mitchell <mitch at niftyegg.com>
> To: "cryptography at metzdowd.com" <cryptography at metzdowd.com>
> Cc: "cryptography at randombit.net" <cryptography at randombit.net>
> Subject: Re: [Cryptography] The Heartbleed Bug is a serious
>         vulnerability in        OpenSSL
> Message-ID:
>         <CAAMy4URAE7WiMZud3HjLh1n=d54=
> 1+pgOjT+ZdquXapHpYH2rQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tue, Apr 8, 2014 at 10:12 AM, Jonathan Thornburg <
> jthorn at astro.indiana.edu> wrote:
>
> > On Tue, Apr 08, 2014 at 11:46:49AM +0100, ianG wrote:
> > > While everyone's madly rushing around to fix their bits&bobs, I'd
> > > encouraged you all to be alert to any evidence of *damages*
> >
>
>
> > [[...]]
> > >
> > > E.g., if we cannot show any damages from this breach, it isn't worth
> > > spending a penny on it to fix!
> >
> > This analysis appears to say that it's not worth spending money to
> > fix a hole (bug) unless either money has already been spent or damages
> > have *already* occured.
> >
>
> May I add that the analysis must take into account the ability
> to detect an exploit and the value of the exploit over time.
> This might be very hard to detect.
>
> To me the bigger you are or more interesting you are the
> more important it is to fix.  Time makes exploited data like
> a public key a risk for the life of the key and perhaps longer.
>
> This one is especially nasty in that it may have exposed any
> data visible to the ssl-bug compromised process.   In the case of
> a private key escape the ability to detect future abuse is near zero.
>
> Fixing this is important.  Less so for me but astoundingly so
> for any host that a CSS might pull from or any host that transacts
> money.    To some degree this is a two end problem so both
> ends need to be aware.
>
> I will be installing patched code as quickly as it shows up.
>
> --
>   T o m    M i t c h e l l
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.metzdowd.com/pipermail/cryptography/attachments/20140408/caa09cca/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 12
> Date: Tue, 8 Apr 2014 20:22:02 -0400
> From: Jerry Leichter <leichter at lrw.com>
> To: Jonathan Thornburg <jthorn at astro.indiana.edu>
> Cc: cryptography at metzdowd.com, cryptography at randombit.net
> Subject: Re: [Cryptography] The Heartbleed Bug is a serious
>         vulnerability in        OpenSSL
> Message-ID: <2B02EDFC-609A-4255-A3EC-182E74334104 at lrw.com>
> Content-Type: text/plain; charset=us-ascii
>
> On Apr 8, 2014, at 1:12 PM, Jonathan Thornburg <jthorn at astro.indiana.edu>
> wrote:
> >> E.g., if we cannot show any damages from this breach, it isn't worth
> >> spending a penny on it to fix!
> >
> > This analysis appears to say that it's not worth spending money to
> > fix a hole (bug) unless either money has already been spent or damages
> > have *already* occured.  This ignores possible or probable (or even
> > certain!) *future* damages if no rework has yet happened.
> You're misreading what Iang wrote.  To say one should not fix a *potential
> problem that hasn't yet occurred* because we can't prove it's caused any
> losses yet is absurd.  Before the problem actually occurs, all we have to
> go on is our estimates of the possible cost, and we have to anticipate
> those costs.
>
> However, in the case of a problem that *has actually occurred*, if you
> *still* can't show any loses - then you have to seriously ask whether the
> problem is worth fixing, or whether it isn't really a "problem" at all.
>
> For example, there are all sorts of plausible-sounding arguments that if
> people are exposed to signals at the frequencies and power levels used for
> WiFi then various bad things will happen to them.  Well ... we've exposed
> many millions of people to such signals for extended periods of time, and
> the evidence is that the "problem" - exposure to RF - doesn't produce any
> real costs.  The research that shows that is valuable; and documentation of
> the actual costs (or lack thereof) for various classes of software bugs
> would *also* be valuable.  Without such research an documentation, our risk
> analyses are lacking a solid foundation.
>                                                         -- Jerry
>
>
>
>
> ------------------------------
>
> Message: 13
> Date: Tue, 08 Apr 2014 12:12:54 -0700
> From: Bear <bear at sonic.net>
> To: Nico Williams <nico at cryptonector.com>
> Cc: Bill Stewart <billstewart at pobox.com>,       Cryptography List
>         <cryptography at metzdowd.com>
> Subject: Re: [Cryptography] TLS/DTLS Use Cases
> Message-ID: <1396984374.22160.3.camel at excessive.dsl.static.sonic.net>
> Content-Type: text/plain; charset="UTF-8"
>
> On Sat, 2014-04-05 at 18:23 -0500, Nico Williams wrote:
>
> > Also, HTTP is just about the worst datagram protocol ever.  There's no
> > XID, so responses have to be sent in the same order as requests over
> > any one keptalive TCP connection.  Yuck.  (When I've brought this up
> > in the context of HTTPbis I've been told to go away.)
> >
>
> To be fair, keep-alive was not part of the design.  Http was initially
> a completely stateless protocol, and actually a fairly well designed
> one.  The reason keep-alive is not well supported is because it's got
> nothing to do with the original design and was bolted on as an
> afterthought.
>
> Is there a take-home lesson there?  Only that if we engage in elegant
> design we should not trust those who come after us not to screw it up.
>
>
>
>
>
> ------------------------------
>
> Message: 14
> Date: Tue, 08 Apr 2014 13:21:48 -0700
> From: Bear <bear at sonic.net>
> To: Peter Gutmann <pgut001 at cs.auckland.ac.nz>
> Cc: cryptography at metzdowd.com, crypto at senderek.ie
> Subject: Re: [Cryptography] OpenPGP and trust
> Message-ID: <1396988508.22160.39.camel at excessive.dsl.static.sonic.net>
> Content-Type: text/plain; charset="UTF-8"
>
> On Sun, 2014-04-06 at 20:59 +1200, Peter Gutmann wrote:
> > Ralf Senderek <crypto at senderek.ie> writes:
> >
> > >You can easily solve this problem by obtaining a certificate that
> verifies in
> > >almost all browsers for a few bucks per year,
> >
> > And the neat thing is that any bad guy can buy a cert from the same CA
> you
> > bought your one from (or any other commercial CA of their choice), set
> up a
> > dummy server, and all your friends will connect thinking it's the real
> thing.
> > The false sense of security created by the cert will make things much
> easier
> > for them.
>
> For a while now I've been considering 'continuity' as an (adhoc)
> approach to security.  It could be a supplement to the web-of-trust
> or a supplement to X.509, or even something that provides a certain
> level of trust on its own for particular purposes.
>
> In a continuity-based system, you'd be associating each key with
> an entity.  An entity presenting a different key/cert, without some
> continuity measure such as new-key-signed-by-old plus revocation
> of old key, should not be assumed to be the same entity regardless
> of what they or their cert claims.
>
> And revocation of old key is a very important part of it, because
> with revocation you get a situation where an impersonator is forced
> to either use a key that the impersonated person can decrypt (leaving
> possible evidence) or break the impersonated person's key (leaving
> possible evidence).
>
> Anyway this is the sort of thing that approach would address.  You
> have bought a cert for your site, some other guy has bought a
> cert for his site, and when people log on, they get a cert - but
> not the one they've been getting up to that moment. This is a
> continuity violation, and absolutely nothing that their software
> knows is associated with your site should be working for or with
> this other site which has a different key.
>
> My vision of UI for this would be that each site should come up
> next to (or under, or over) a banner that lists previous interactions
> with that site, and that a completely new previously-unseen cert,
> regardless of who it's signed by or what it says, should come up
> with a banner that says,
>
> "YOU HAVE NEVER ACCESSED THIS SITE BEFORE TODAY - NEW KEY HAS NO
> PREVIOUS HISTORY."
>
> Obviously if the user "knows otherwise" there's something wrong.
> If it's important, and there's no continuity, then the user should
> be making a phone call and getting his bank to verify that yes, it
> did in fact change its key since last time he connected.  The bank
> doesn't want the hassle of answering phone calls?  Then it should
> do the continuity dance, sign the new cert with the old one, and
> revoke.
>
>
>
>
>
> ------------------------------
>
> Message: 15
> Date: Wed, 9 Apr 2014 12:12:22 +1000 (EST)
> From: Dave Horsfall <dave at horsfall.org>
> To: Cryptography List <cryptography at metzdowd.com>
> Subject: Re: [Cryptography] The Heartbleed Bug is a serious
>         vulnerability in OpenSSL
> Message-ID: <alpine.BSF.2.00.1404091208370.739 at aneurin.horsfall.org>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> Is there an echo here somewhere?  Three and counting...
>
> -- Dave, remebering the Johnny Cash lyrice
>
>
> ------------------------------
>
> Message: 16
> Date: Tue, 08 Apr 2014 20:15:02 -0700
> From: Paul Ferguson <fergdawgster at mykolab.com>
> To: ianG <iang at iang.org>
> Cc: cryptography at metzdowd.com
> Subject: Re: [Cryptography] The Heartbleed Bug is a serious
>         vulnerability in OpenSSL
> Message-ID: <5344BB36.7070207 at mykolab.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Ian,
>
> On 4/8/2014 3:46 AM, ianG wrote:
>
> >
> > I maintain a risk history here: http://wiki.cacert.org/Risk/History
> > for the CA field, so if anyone can find any real damages effecting
> > the CA world, let me know!
> >
>
> Thank you very much for providing a pointer to the CAcert Risk History
> page -- that is extraordinarily useful. :-)
>
> Cheers,
>
> - - ferg
>
> - --
> Paul Ferguson
> VP Threat Intelligence, IID
> PGP Public Key ID: 0x54DC85B2
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iF4EAREIAAYFAlNEuzYACgkQKJasdVTchbKlzgD+MdDTtiTDBwyWBq2DTuE7OTAn
> xCBrX+KFkKxabmxLVeQA/A/YzQ+loOqsQAjKuGVImDKBuNrDItH47yZergLhDT+X
> =nEzj
> -----END PGP SIGNATURE-----
>
>
> ------------------------------
>
> _______________________________________________
> cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
> End of cryptography Digest, Vol 12, Issue 9
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140410/798d47ad/attachment.html>


More information about the cryptography mailing list