From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 border1.nntp.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Natasha Kerensikova <lithiumcat@instinctive.eu>
Newsgroups: comp.lang.ada
Subject: Re: OpenSSL development (Heartbleed)
Date: Wed, 23 Apr 2014 07:40:44 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <slrnllerjr.i0l.lithiumcat@nat.rebma.instinctive.eu>
References: <-OGdnezdYpRWFc_OnZ2dnUVZ_vednZ2d@giganews.com>
 <535297f1$0$6715$9b4e6d93@newsspool3.arcor-online.net>
 <op.xekmrhmiule2fv@cardamome>
 <5352a585$0$6707$9b4e6d93@newsspool3.arcor-online.net>
 <lj4ath$c6i$1@loke.gir.dk>
 <535688a0$0$6721$9b4e6d93@newsspool3.arcor-online.net>
 <19mxjybev4fc9.1fkxznem326v8$.dlg@40tude.net> <lj671n$bj6$1@dont-email.me>
 <1ottu3pw9hxl1.i1h7v3r51vk0.dlg@40tude.net>
 <slrnlleked.i0l.lithiumcat@nat.rebma.instinctive.eu>
 <6xpjk44lobfz.fctt93m75u47$.dlg@40tude.net>
Injection-Date: Wed, 23 Apr 2014 07:40:44 +0000 (UTC)
Injection-Info: mx05.eternal-september.org;
 posting-host="76a49b86bc3e16725b7cfca3d85cb4c8";
 logging-data="410"; mail-complaints-to="abuse@eternal-september.org";
 posting-account="U2FsdGVkX19BD7QVDS3NZT31qBd5wIYT"
User-Agent: slrn/1.0.1 (FreeBSD)
Cancel-Lock: sha1:4rxFW9jY9lB5BAy6ARHolpd3YiI=
X-Original-Bytes: 2755
Xref: number.nntp.dca.giganews.com comp.lang.ada:186010
Date: 2014-04-23T07:40:44+00:00
List-Id: <comp.lang.ada>

On 2014-04-23, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Wed, 23 Apr 2014 05:38:21 +0000 (UTC), Natasha Kerensikova wrote:
>
>> On 2014-04-22, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>> Boundary checks or not, the transport layer shall have no access to the
>>> server data.
>>>
>>> A tightly coupled system is vulnerable. If compromising just one component
>>> opens all gates wide, that is a bad standard and bad design. The effects of
>>> errors and faults must be bounded per design. 
>> 
>> How would you design a transport layer that has no access to whatever is
>> supposed to be transported?
>> 
>> "Heartbleed" didn't leak any data that ins't legitimataly needed by
>> OpenSSL (i.e. transported data and/or transport parameters (like keys))
>
> I heard it leaked user data, I didn't go into details. I hope user data are
> not transported, because otherwise that would be even an greater design
> fault.

Actually it leaked session cookies, that are legitimately part of any
HTTP payload, and login/passwords, that are legitimately part of the
HTTP payload of the authentication request.

At that point the remaining of the user data is considered compromised
as well, because of the possibility of session/credential hijacking,
but that's only an indirect result of heartbleed, and requires a
separate attack.