Today's Topics: 1. Re: The Heartbleed Bug is a serious vulnerability in OpenSSL (Nico Williams) 2. Re: [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL (Jonathan Thornburg) 3. Re: [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL (ianG) 4. Re: [Cryptography] Github Pages now supports SSL (Eric Mill) 5. Re: OTR and XMPP (Randolph) 6. Re: [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL (tpb-crypto@laposte.net) 7. Re: [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL (Nico Williams) ---------------------------------------------------------------------- Message: 1 Date: Tue, 8 Apr 2014 09:48:02 -0500 From: Nico Williams To: Edwin Chu Cc: cryptography@randombit.net Subject: Re: [cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL Message-ID: <20140408144800.GG7962@localhost> Content-Type: text/plain; charset=us-ascii On Mon, Apr 07, 2014 at 11:02:50PM -0700, Edwin Chu wrote: > I am not openssl expert and here is just my observation. > [...] Thanks for this analysis. Sadly, a variable-sized heartbeat payload was probably necessary, at least for the DTLS case: for PMTU discovery. Once more, a lack of an IDL, standard encoding, and tools, has hurt us. Hand-coded parsers/encoders are disasters waiting to happen. The TLS ad-hoc message syntax and encoding are not even adhered to consistently in all the extensions, so I'm not sure that we could fix this problem now (in TLS 1.3, say). There was a thread on the TLS WG list about this a while back... Fixing this in 1.3 wouldn't fix the implementations. Making tooling available wouldn't either: it's very difficult to retrofit an IDL compiler into a codebase with hand-coded coders -- it's so difficult that it may be easier to build codebase- specific IDL compilers. Plus waiting for tooling would delay other important enhancements. Nico -- ------------------------------ Message: 2 Date: Tue, 8 Apr 2014 13:12:25 -0400 From: Jonathan Thornburg To: cryptography@metzdowd.com, cryptography@randombit.net Subject: Re: [cryptography] [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL Message-ID: <20140408171208.GA927@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]" 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 18:33:06 +0100 From: ianG To: cryptography@randombit.net Subject: Re: [cryptography] [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL Message-ID: <534432D2.6020501@iang.org> Content-Type: text/plain; charset=ISO-8859-1 On 8/04/2014 18:12 pm, 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. > > This seems like a flawed risk analysis to me. Indeed. And you should also include insider theft, machine melt-down, seizure by authorities, power loss, spammers taking over the server, etc etc. The point being that we concentrate on a particular group of ills *because we can* and we ignore other ills /because we don't understand them/ . The end result is often that we waste out money, we would be better of balancing the risk analysis to include and learn other important risks. How do we tell what's important or not? With historical facts. Or with theory. But all theory tells us about the unknown is how good people are at presenting FUD. It takes experiments to turn it into science. > 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. Ah, that is where framing the question is needed. I would have asked the question, what is the frequency and size of tsunamis? This is a question for which we have *a lot of data* . And how likely is a big one to damage the reactor? Well, we have a lot of data on how likely is a big one to damage big buildings. So some educated guesses can be made. And indeed, the water defences at Fukushima were rated for a lesser sized Tsunami, so someone asked the question, and fell on the wrong side of history. iang ------------------------------ Message: 4 Date: Tue, 8 Apr 2014 14:04:58 -0400 From: Eric Mill To: Bill Stewart Cc: cpunks , "cryptography@metzdowd.com List" , Cryptography List Subject: Re: [cryptography] [Cryptography] Github Pages now supports SSL Message-ID: Content-Type: text/plain; charset="iso-8859-1" Yeah, it's real terrific. -_____- @ITechGeek, my understanding was that SNI was handled at an OS level by WinXP, and no browser would work on it. I could be wrong, I haven't researched it myself. On Mon, Apr 7, 2014 at 10:31 PM, Bill Stewart wrote: > At 11:08 AM 4/4/2014, Eric Mill wrote: > >> I know most of the people on here have transcended the earthbound, >> maudlin Certificate Authority system, but as services-adopting-SSL-news >> goes, I'm particular excited about > 444555263195217920>Github Pages, which started quietly supporting SSL >> for *.github.io domains a few weeks back. >> > > Well that was convenient timing, considering the OpenSSL "Change All Your > Certs and Keys Now" bug announcement that just hit the wires :-) > > _______________________________________________ > The cryptography mailing list > cryptography@metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography > -- konklone.com | @konklone -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Tue, 8 Apr 2014 20:30:49 +0200 From: Randolph To: Pranesh Prakash Cc: Discussion of cryptography and related , Guardian Dev Subject: Re: [cryptography] OTR and XMPP Message-ID: Content-Type: text/plain; charset="utf-8" the alternative to OTR is the echo encryption, as deployed in this client: http://firefloo.sf.net As well offers this client to send Rosetta Encryption over XMPP. That is the second alternative. Please research the library used. Regards 2014-04-08 4:13 GMT+02:00 Pranesh Prakash : > Dear all, > In the March IETF 89 meeting in London, there were renewed discussions > around end-to-end encryption in XMPP. > > Here is the recording of the session: > > http://recordings.conf.meetecho.com/Recordings/watch. > jsp?recording=IETF89_XMPP&chapter=part_5 > > There was basic agreement that OTR is a horrible fit for XMPP since it > doesn't provide full stanza encryption. The very reasons for the benefits > of OTR (its ability to be protocol-agnostic) are the reasons for its > shortfalls too. > > However, there is no clear alternative. The closest is > draft-miller-xmpp-e2e. The one clear verdict was that more contributors > are required. > > The discussions are happening at: > > https://www.ietf.org/mailman/listinfo/xmpp > http://mail.jabber.org/mailman/listinfo/standards > > If anyone has the time to make contributions, please do jump in (and > spread the word). > > ~ Pranesh > -- > Pranesh Prakash > Policy Director, Centre for Internet and Society > T: +91 80 40926283 | W: http://cis-india.org > ------------------- > Access to Knowledge Fellow, Information Society Project, Yale Law School > M: +1 520 314 7147 | W: http://yaleisp.org > PGP ID: 0x1D5C5F07 | Twitter: https://twitter.com/pranesh_prakash > > > _______________________________________________ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Tue, 08 Apr 2014 21:18:52 +0200 From: tpb-crypto@laposte.net To: ianG , cryptography@metzdowd.com, cryptography@randombit.net Subject: Re: [cryptography] [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL Message-ID: <1316776432.92614.1396984732457.JavaMail.www@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: 7 Date: Tue, 8 Apr 2014 14:33:42 -0500 From: Nico Williams To: Jonathan Thornburg Cc: cryptography@metzdowd.com, cryptography@randombit.net Subject: Re: [cryptography] [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL Message-ID: <20140408193339.GJ7962@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 -- ------------------------------ Subject: Digest Footer _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ------------------------------ End of cryptography Digest, Vol 50, Issue 7 *******************************************