Re: [cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL
I am not openssl expert and here is just my observation.
TLS frame messages into length-prefixed records. Each records has a
1 byte contentType and a 2 byte record length, followed by the record
content and MAC.
Heartbeat messages are TLS records with contentType 24 of this content format:
struct {
HeartbeatMessageType type;
uint16 payload_length;
opaque payload[HeartbeatMessage.payload_length];
opaque padding[padding_length];
} HeartbeatMessage;
Note that there are two length fields involved, the TLS record length
and the heartbeat message payload_length. It is possible to construct
a heartbeat message that has the heartbeat payload_length larger than
the record length. The TLS heartbeat protocol further requires that
the respondent of heartbeat request should copy the payload to the
response. Failing to bound check the heartbeat message payload_length,
openssl may copy the memory region beyond the incoming record buffer
to the response buffer. The 64 k limit is the maximum possible size of
a TLS record because the length is 2 byte long.
Edwin
Edwin
On Mon, Apr 7, 2014 at 7:14 PM, konfku...@riseup.net wrote:
The git blame in a heartbeat:
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db9023b881d7cd9f379b0c154650d6c108e9a3
The big question is:
Seeing these diff lines, how does one reveal 64k of memory?
The first who codes is the first who posts.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] OTR and XMPP
On 8/04/2014 03:13 am, Pranesh Prakash wrote: 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_XMPPchapter=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. Has anyone got a text-based summary of what this is about? I'm happy to read, but I find listening to recordings doesn't really work. 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). iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL
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 bitsbobs, 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL
On Apr 8, 2014 2:03 AM, Edwin Chu edwinche...@gmail.com wrote:
I am not openssl expert and here is just my observation.
TLS frame messages into length-prefixed records. Each records has a
1 byte contentType and a 2 byte record length, followed by the record
content and MAC.
Heartbeat messages are TLS records with contentType 24 of this content
format:
struct {
HeartbeatMessageType type;
uint16 payload_length;
opaque payload[HeartbeatMessage.payload_length];
opaque padding[padding_length];
} HeartbeatMessage;
Here: https://github.com/FiloSottile/Heartbleed
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL
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 -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL
On Tue, Apr 08, 2014 at 11:46:49AM +0100, ianG wrote: While everyone's madly rushing around to fix their bitsbobs, 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] jth...@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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Github Pages now supports SSL
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 billstew...@pobox.com 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 https://twitter.com/benbalter/status/ 444555263195217920Github Pages, which started quietly supporting SSL for *.http://github.iogithub.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 cryptogra...@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography -- konklone.com | @konklone https://twitter.com/konklone ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] OTR and XMPP
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 pran...@cis-india.org: 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_XMPPchapter=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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL
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. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL
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 bitsbobs, 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 -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL
On Tue, Apr 8, 2014 at 3:18 PM, tpb-cry...@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. Keep it as is if you want. https://www.mattslifebytes.com/?p=533 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL
On Tue, Apr 8, 2014 at 6:46 AM, ianG i...@iang.org wrote: On 7/04/2014 22:53 pm, Edwin Chu wrote: ... 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. This system works great for the firms involved. The first data breach I was part of, it cost me over $10,000 to fix. I did not find out until I had judgements against me, and the collection agencies came after me. The latest breach I got sucked into only involved a compromised credit card, so it only cost me $75 to have a new one shipped to me while I was out of town (I only have one credit card). Saving those pennies has worked out great for me. I'm glad the executives got their bonuses and the stock holders got their dividends. Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL
Message du 08/04/14 21:42 De : ianG A : tpb-cry...@laposte.net, cryptogra...@metzdowd.com, cryptography@randombit.net Copie à : Objet : Re: [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL On 8/04/2014 20:18 pm, tpb-cry...@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? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL
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 bitsbobs, 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., N0. 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL
On 8/04/2014 21:02 pm, tpb-cry...@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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL
we should probably stop keeping secrets on the internet. (snark snark) marc On Tue, Apr 8, 2014 at 3:17 PM, ianG i...@iang.org wrote: On 8/04/2014 21:02 pm, tpb-cry...@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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [tor-talk] The Heartbleed Bug is a serious vulnerability in OpenSSL
On Tue, Apr 8, 2014 at 2:02 PM, Joe Btfsplk joebtfs...@gmx.com wrote: On 4/7/2014 6:14 PM, grarpamp wrote: http://heartbleed.com/ Patch your stuff. Comments / suggestions from those w/ in depth knowledge in this area? How users should proceed; how to check if sites used (banks, email, retail sites, etc.) were / still are affected, so one knows if when to change passwords or other data? If the number of sites potentially affected is as large as indicated on heartbleed.com, changing PW on even 60% of sites I use could take a long time - even to do it once. It would do little good to change a password on a site that hasn't patched this. Or perhaps it would do some good, to change the password before logging out of a site? Then when a site must be accessed again, change the password again. Either way, this might not provide perfect safety, but might ? be better than nothing. https://blog.torproject.org/ covers what to do for Tor things. For everything else on the net, fix the clients and servers you're responsible for. Then... You're right, there's a big gotcha in all this, users won't really know if the services they interact with have been fixed [1] because huge swaths of services simply don't publish what they do on their pages, they bury it to keep quiet and shiny happy sites. Only some banks, insurers, utilities, schools, etc will post we're fixed anywhere remotely prominent. So you have to trust they did [2], which is a reasonable assumption given regulation and liability of big institutional services. You should already have a regular password changing/logout/session management regimen, so inserting some extra instances of that along guesstimates of [2] should suffice with these classes of service. [2] Sometime during the falloff curve starting yesterday afternoon. The real user risk is likely on mid to small services, embedded things, shared platforms, legacy systems, services that didn't get the news, don't have the resources or knowledge to fix, etc. Again, consider some form of reasonable regimen. And there are all sorts of tools and site testing services coming out now for which a brave user might be completely warranted in using to determine [1 above] so they know when to utilize [regimen 2]. (Far better to use a testing service or email their help desks seeking a positive statement than risk being potentially considered an exploiter of things you don't own.) Partial list... http://s3.jspenguin.org/ssltest.py https://gist.github.com/takeshixx/10107280 https://github.com/FiloSottile/Heartbleed https://www.ssllabs.com/ssltest/index.html (Note, this is a TLS in process bug, so more than HTTP/S services are affected...) This bug will no doubt trigger some thinking, analysis and change in the services, security, infrastructure and user communites... that's a good thing. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL
On 2014-04-09 00:48, Nico Williams wrote: 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. Is there an existing idl for messages such that interface descriptions that can be compiled into parsers and encoders? (microsoft's idl is inherently function oriented, rather than message oriented, leading to disastrous results when they somehow stretched it for message passing environments) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
