[gentoo-user] 'Heartbleed' bug

[gentoo-user] 'Heartbleed' bug

[Joseph]

Is gentoo effected by this new 'Heartbleed' bug?

"The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library...."

http://heartbleed.com/

-- 
Joseph

Re: [gentoo-user] 'Heartbleed' bug

[Ralf]

Hello Joseph,
On 04/10/2014 02:06 AM, Joseph wrote:
> Is gentoo effected by this new 'Heartbleed' bug? 
yes it is, as all OpenSSL versions > 0.9.8 were affected.
And Gentoo supported those versions.

So Gentoo also was affected but it supports the new
"heartbleed-bug-fixed" version 1.0.1g.

I *think* that you could also use an older version disabling the
"tls-heartbeat" USE flag.

Regards
  Ralf

Re: [gentoo-user] 'Heartbleed' bug

[Michael Orlitzky]

On 04/09/2014 08:06 PM, Joseph wrote:
> Is gentoo effected by this new 'Heartbleed' bug?
> 
> "The Heartbleed Bug is a serious vulnerability in the popular OpenSSL
> cryptographic software library...."
> 
> http://heartbleed.com/
> 

Yes, upgrade your OpenSSL to the latest stable version, and if 1.0.1g
isn't stable on your arch (it should be unless it's a weird one), unset
USE=tls-heartbeat like Ralf said.

But that's not your big problem. If you operate any servers, the private
keys to any OpenSSL-backed service may have been compromised. So the old
certificates all need to be revoked and new ones issued. That includes
Apache, OpenVPN, Postfix, Dovecot -- all the big ones. Even if you don't
run servers, other people do, and they were probably vulnerable. So any
passwords you've used on the web in the past two years should be changed.

Re: [gentoo-user] 'Heartbleed' bug

[Pavel Volkov]

On Thursday, 10 April 2014 04:32:34 MSK, Michael Orlitzky wrote:
> Yes, upgrade your OpenSSL to the latest stable version, and if 1.0.1g
> isn't stable on your arch (it should be unless it's a weird one), unset
> USE=tls-heartbeat like Ralf said.
>
> But that's not your big problem. If you operate any servers, the private
> keys to any OpenSSL-backed service may have been compromised. So the old
> certificates all need to be revoked and new ones issued. That includes
> Apache, OpenVPN, Postfix, Dovecot -- all the big ones. Even if you don't
> run servers, other people do, and they were probably vulnerable. So any
> passwords you've used on the web in the past two years should be changed.

What surprises me here is OpenSSH. It's not supposed to use OpenSSL but 
Debian update process suggests to restart it after updating OpenSSL to a 
fixed version. Is it an overkill on their part? It might confuse admins.

Re: [gentoo-user] 'Heartbleed' bug

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]

> What surprises me here is OpenSSH. It's not supposed to use OpenSSL but
> Debian update process suggests to restart it after updating OpenSSL to a
> fixed version. Is it an overkill on their part? It might confuse admins.
>
>
> adam@proxy ~ $ ldd /usr/sbin/sshd
    linux-vdso.so.1 (0x00007fffb068e000)
    libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f68db1e6000)
    libpam.so.0 => /lib64/libpam.so.0 (0x00007f68dafd8000)
    libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00007f68dabf5000)
    libutil.so.1 => /lib64/libutil.so.1 (0x00007f68da9f2000)
    libz.so.1 => /lib64/libz.so.1 (0x00007f68da7db000)
    libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f68da5a4000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f68da387000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f68d9fd7000)
    libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1
(0x00007f68d9dc0000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f68d9bbc000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f68db3f1000)
adam@proxy ~ $ qfile /usr/lib64/libcrypto.so.1.0.0
dev-libs/openssl (/usr/lib64/libcrypto.so.1.0.0)
adam@proxy ~ $

So OpenSSH clearly IS using OpenSSL, and you need to restart sshd after
upgrading OpenSSL.

[-- Attachment #2: Type: text/html, Size: 1575 bytes --]

Re: [gentoo-user] 'Heartbleed' bug

[Ján Zahornadský]

On 04/10/2014 05:03 PM, Adam Carter wrote:
> 
>     What surprises me here is OpenSSH. It's not supposed to use OpenSSL
>     but Debian update process suggests to restart it after updating
>     OpenSSL to a fixed version. Is it an overkill on their part? It
>     might confuse admins.
> 
> 
> adam@proxy ~ $ ldd /usr/sbin/sshd
>     linux-vdso.so.1 (0x00007fffb068e000)
>     libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f68db1e6000)
>     libpam.so.0 => /lib64/libpam.so.0 (0x00007f68dafd8000)
>     libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00007f68dabf5000)
>     libutil.so.1 => /lib64/libutil.so.1 (0x00007f68da9f2000)
>     libz.so.1 => /lib64/libz.so.1 (0x00007f68da7db000)
>     libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f68da5a4000)
>     libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f68da387000)
>     libc.so.6 => /lib64/libc.so.6 (0x00007f68d9fd7000)
>     libgcc_s.so.1 =>
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1 (0x00007f68d9dc0000)
>     libdl.so.2 => /lib64/libdl.so.2 (0x00007f68d9bbc000)
>     /lib64/ld-linux-x86-64.so.2 (0x00007f68db3f1000)
> adam@proxy ~ $ qfile /usr/lib64/libcrypto.so.1.0.0
> dev-libs/openssl (/usr/lib64/libcrypto.so.1.0.0)
> adam@proxy ~ $
> 
> So OpenSSH clearly IS using OpenSSL, and you need to restart sshd after
> upgrading OpenSSL.

As far as I know, it doesn't use it for the communication itself, just
some key generations, so it shouldn't be affected by this bug. But I
guess better safe than sorry...

Re: [gentoo-user] 'Heartbleed' bug

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

Am Wed, 9 Apr 2014 18:06:35 -0600
schrieb Joseph <syscon780@gmail.com>:

> Is gentoo effected by this new 'Heartbleed' bug?
> 
> "The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library...."
> 
> http://heartbleed.com/

Just FYI: security issues such as this get announced on the gentoo-announce ML
("heartbleed" was announced on the 8th of April).

-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-user] 'Heartbleed' bug

[Nilesh Govindrajan]

On Thu, Apr 10, 2014 at 4:22 PM, Matthew Finkel
<matthew.finkel@gmail.com> wrote:
> On Thu, Apr 10, 2014 at 05:53:44PM +0800, J?n Zahornadsk? wrote:
>> On 04/10/2014 05:03 PM, Adam Carter wrote:
>> >
>> >     What surprises me here is OpenSSH. It's not supposed to use OpenSSL
>> >     but Debian update process suggests to restart it after updating
>> >     OpenSSL to a fixed version. Is it an overkill on their part? It
>> >     might confuse admins.
>> >
>> >
>> > adam@proxy ~ $ ldd /usr/sbin/sshd
>> >     linux-vdso.so.1 (0x00007fffb068e000)
>> >     libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f68db1e6000)
>> >     libpam.so.0 => /lib64/libpam.so.0 (0x00007f68dafd8000)
>> >     libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00007f68dabf5000)
>> >     libutil.so.1 => /lib64/libutil.so.1 (0x00007f68da9f2000)
>> >     libz.so.1 => /lib64/libz.so.1 (0x00007f68da7db000)
>> >     libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f68da5a4000)
>> >     libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f68da387000)
>> >     libc.so.6 => /lib64/libc.so.6 (0x00007f68d9fd7000)
>> >     libgcc_s.so.1 =>
>> > /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1 (0x00007f68d9dc0000)
>> >     libdl.so.2 => /lib64/libdl.so.2 (0x00007f68d9bbc000)
>> >     /lib64/ld-linux-x86-64.so.2 (0x00007f68db3f1000)
>> > adam@proxy ~ $ qfile /usr/lib64/libcrypto.so.1.0.0
>> > dev-libs/openssl (/usr/lib64/libcrypto.so.1.0.0)
>> > adam@proxy ~ $
>> >
>> > So OpenSSH clearly IS using OpenSSL, and you need to restart sshd after
>> > upgrading OpenSSL.
>>
>> As far as I know, it doesn't use it for the communication itself, just
>> some key generations, so it shouldn't be affected by this bug. But I
>> guess better safe than sorry...
>>
>
> Right. heartbleed does not directly affect openssh, but openssh uses
> openssl and it's good practice to keep the shared libraries on-disk and
> the shared libraries in-memory in sync.
>


How is OpenSSH not affected?

Re: [gentoo-user] 'Heartbleed' bug

[Matthew Finkel]

On Thu, Apr 10, 2014 at 05:53:44PM +0800, J?n Zahornadsk? wrote:
> On 04/10/2014 05:03 PM, Adam Carter wrote:
> > 
> >     What surprises me here is OpenSSH. It's not supposed to use OpenSSL
> >     but Debian update process suggests to restart it after updating
> >     OpenSSL to a fixed version. Is it an overkill on their part? It
> >     might confuse admins.
> > 
> > 
> > adam@proxy ~ $ ldd /usr/sbin/sshd
> >     linux-vdso.so.1 (0x00007fffb068e000)
> >     libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f68db1e6000)
> >     libpam.so.0 => /lib64/libpam.so.0 (0x00007f68dafd8000)
> >     libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00007f68dabf5000)
> >     libutil.so.1 => /lib64/libutil.so.1 (0x00007f68da9f2000)
> >     libz.so.1 => /lib64/libz.so.1 (0x00007f68da7db000)
> >     libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f68da5a4000)
> >     libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f68da387000)
> >     libc.so.6 => /lib64/libc.so.6 (0x00007f68d9fd7000)
> >     libgcc_s.so.1 =>
> > /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1 (0x00007f68d9dc0000)
> >     libdl.so.2 => /lib64/libdl.so.2 (0x00007f68d9bbc000)
> >     /lib64/ld-linux-x86-64.so.2 (0x00007f68db3f1000)
> > adam@proxy ~ $ qfile /usr/lib64/libcrypto.so.1.0.0
> > dev-libs/openssl (/usr/lib64/libcrypto.so.1.0.0)
> > adam@proxy ~ $
> > 
> > So OpenSSH clearly IS using OpenSSL, and you need to restart sshd after
> > upgrading OpenSSL.
> 
> As far as I know, it doesn't use it for the communication itself, just
> some key generations, so it shouldn't be affected by this bug. But I
> guess better safe than sorry...
>

Right. heartbleed does not directly affect openssh, but openssh uses
openssl and it's good practice to keep the shared libraries on-disk and
the shared libraries in-memory in sync.

Re: [gentoo-user] 'Heartbleed' bug

[Randolph Maaßen]

The Heartbleed bug is in the Heartbeat function of TSL (a second keep
alive). OpenSSL does not use TLS for transport security, it uses its
own Protokoll for security.

2014-04-10 12:51 GMT+02:00 Nilesh Govindrajan <me@nileshgr.com>:
> On Thu, Apr 10, 2014 at 4:22 PM, Matthew Finkel
> <matthew.finkel@gmail.com> wrote:
>> On Thu, Apr 10, 2014 at 05:53:44PM +0800, J?n Zahornadsk? wrote:
>>> On 04/10/2014 05:03 PM, Adam Carter wrote:
>>> >
>>> >     What surprises me here is OpenSSH. It's not supposed to use OpenSSL
>>> >     but Debian update process suggests to restart it after updating
>>> >     OpenSSL to a fixed version. Is it an overkill on their part? It
>>> >     might confuse admins.
>>> >
>>> >
>>> > adam@proxy ~ $ ldd /usr/sbin/sshd
>>> >     linux-vdso.so.1 (0x00007fffb068e000)
>>> >     libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f68db1e6000)
>>> >     libpam.so.0 => /lib64/libpam.so.0 (0x00007f68dafd8000)
>>> >     libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00007f68dabf5000)
>>> >     libutil.so.1 => /lib64/libutil.so.1 (0x00007f68da9f2000)
>>> >     libz.so.1 => /lib64/libz.so.1 (0x00007f68da7db000)
>>> >     libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f68da5a4000)
>>> >     libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f68da387000)
>>> >     libc.so.6 => /lib64/libc.so.6 (0x00007f68d9fd7000)
>>> >     libgcc_s.so.1 =>
>>> > /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1 (0x00007f68d9dc0000)
>>> >     libdl.so.2 => /lib64/libdl.so.2 (0x00007f68d9bbc000)
>>> >     /lib64/ld-linux-x86-64.so.2 (0x00007f68db3f1000)
>>> > adam@proxy ~ $ qfile /usr/lib64/libcrypto.so.1.0.0
>>> > dev-libs/openssl (/usr/lib64/libcrypto.so.1.0.0)
>>> > adam@proxy ~ $
>>> >
>>> > So OpenSSH clearly IS using OpenSSL, and you need to restart sshd after
>>> > upgrading OpenSSL.
>>>
>>> As far as I know, it doesn't use it for the communication itself, just
>>> some key generations, so it shouldn't be affected by this bug. But I
>>> guess better safe than sorry...
>>>
>>
>> Right. heartbleed does not directly affect openssh, but openssh uses
>> openssl and it's good practice to keep the shared libraries on-disk and
>> the shared libraries in-memory in sync.
>>
>
>
> How is OpenSSH not affected?
>



-- 
Mit freundlichen Grüßen / Best regards

Randolph Maaßen

Re: [gentoo-user] 'Heartbleed' bug

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 378 bytes --]

On Thu, 10 Apr 2014 10:52:21 +0000, Matthew Finkel wrote:

> Right. heartbleed does not directly affect openssh, but openssh uses
> openssl and it's good practice to keep the shared libraries on-disk and
> the shared libraries in-memory in sync.

The easiest way to do that is with app-admin/checkrestart.


-- 
Neil Bothwick

Invertebrates make no bones about it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] 'Heartbleed' bug

[Ján Zahornadský]

Exactly, OpenSSH depends on OpenSSL, but should never use the buggy code.

Some details in the answer here:
http://superuser.com/questions/739349/does-heartbleed-affect-ssh-keys


On 04/10/2014 07:00 PM, Randolph Maaßen wrote:
> The Heartbleed bug is in the Heartbeat function of TSL (a second keep
> alive). OpenSSL does not use TLS for transport security, it uses its
> own Protokoll for security.
> 
> 2014-04-10 12:51 GMT+02:00 Nilesh Govindrajan <me@nileshgr.com>:
>> On Thu, Apr 10, 2014 at 4:22 PM, Matthew Finkel
>> <matthew.finkel@gmail.com> wrote:
>>> On Thu, Apr 10, 2014 at 05:53:44PM +0800, J?n Zahornadsk? wrote:
>>>> On 04/10/2014 05:03 PM, Adam Carter wrote:
>>>>>
>>>>>     What surprises me here is OpenSSH. It's not supposed to use OpenSSL
>>>>>     but Debian update process suggests to restart it after updating
>>>>>     OpenSSL to a fixed version. Is it an overkill on their part? It
>>>>>     might confuse admins.
>>>>>
>>>>>
>>>>> adam@proxy ~ $ ldd /usr/sbin/sshd
>>>>>     linux-vdso.so.1 (0x00007fffb068e000)
>>>>>     libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f68db1e6000)
>>>>>     libpam.so.0 => /lib64/libpam.so.0 (0x00007f68dafd8000)
>>>>>     libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00007f68dabf5000)
>>>>>     libutil.so.1 => /lib64/libutil.so.1 (0x00007f68da9f2000)
>>>>>     libz.so.1 => /lib64/libz.so.1 (0x00007f68da7db000)
>>>>>     libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f68da5a4000)
>>>>>     libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f68da387000)
>>>>>     libc.so.6 => /lib64/libc.so.6 (0x00007f68d9fd7000)
>>>>>     libgcc_s.so.1 =>
>>>>> /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1 (0x00007f68d9dc0000)
>>>>>     libdl.so.2 => /lib64/libdl.so.2 (0x00007f68d9bbc000)
>>>>>     /lib64/ld-linux-x86-64.so.2 (0x00007f68db3f1000)
>>>>> adam@proxy ~ $ qfile /usr/lib64/libcrypto.so.1.0.0
>>>>> dev-libs/openssl (/usr/lib64/libcrypto.so.1.0.0)
>>>>> adam@proxy ~ $
>>>>>
>>>>> So OpenSSH clearly IS using OpenSSL, and you need to restart sshd after
>>>>> upgrading OpenSSL.
>>>>
>>>> As far as I know, it doesn't use it for the communication itself, just
>>>> some key generations, so it shouldn't be affected by this bug. But I
>>>> guess better safe than sorry...
>>>>
>>>
>>> Right. heartbleed does not directly affect openssh, but openssh uses
>>> openssl and it's good practice to keep the shared libraries on-disk and
>>> the shared libraries in-memory in sync.
>>>
>>
>>
>> How is OpenSSH not affected?
>>
> 
> 
> 

[gentoo-user] Re: 'Heartbleed' bug

[walt]

On 04/09/2014 05:06 PM, Joseph wrote:
> Is gentoo effected by this new 'Heartbleed' bug?
> 
> "The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library...."
> 
> http://heartbleed.com/

This topic was discussed in my favorite podcast, http://twit.tv/sn

Steve Gibson explained that the heartbeat feature was introduced in openssl to
allow *UDP* connections to mimic the 'keepalive' function of the TCP protocol.

IIRC Steve didn't explain how UDP bugs can compromise TCP connections.

Anyone here really understand the underlying principles?  If so, please explain!

Thanks.

Re: [gentoo-user] Re: 'Heartbleed' bug

[Alan McKinnon]

On 11/04/2014 00:55, walt wrote:
> On 04/09/2014 05:06 PM, Joseph wrote:
>> Is gentoo effected by this new 'Heartbleed' bug?
>>
>> "The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library...."
>>
>> http://heartbleed.com/
> 
> This topic was discussed in my favorite podcast, http://twit.tv/sn
> 
> Steve Gibson explained that the heartbeat feature was introduced in openssl to
> allow *UDP* connections to mimic the 'keepalive' function of the TCP protocol.
> 
> IIRC Steve didn't explain how UDP bugs can compromise TCP connections.
> 
> Anyone here really understand the underlying principles?  If so, please explain!
> 
> Thanks.
> 
> 
> 
> 
> 


UDP is not compromising TCP connections.
The software bug allows malicious connecting code to determine the
contents of memory, which is in use by sshd. How that memory got to be
there is irrelevant.

There are many lengthy discussions on the internet on how this vuln
works. You should read them.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: 'Heartbleed' bug

[Matthew Finkel]

On Thu, Apr 10, 2014 at 03:55:47PM -0700, walt wrote:
> On 04/09/2014 05:06 PM, Joseph wrote:
> > Is gentoo effected by this new 'Heartbleed' bug?
> > 
> > "The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library...."
> > 
> > http://heartbleed.com/
> 
> This topic was discussed in my favorite podcast, http://twit.tv/sn
> 
> Steve Gibson explained that the heartbeat feature was introduced in openssl to
> allow *UDP* connections to mimic the 'keepalive' function of the TCP protocol.
> 
> IIRC Steve didn't explain how UDP bugs can compromise TCP connections.
> 
> Anyone here really understand the underlying principles?  If so, please explain!
> 
> Thanks.

Yes, but no, actually. It's main use is in DTLS, over UDP and similar
protocols, however it is also supported in TLS (over TCP). From the RFC
[0]:

   DTLS is designed to secure traffic running on top of unreliable
   transport protocols.  Usually, such protocols have no session
   management.  The only mechanism available at the DTLS layer to figure
   out if a peer is still alive is a costly renegotiation, particularly
   when the application uses unidirectional traffic[...]

   TLS is based on reliable protocols, but there is not necessarily a
   feature available to keep the connection alive without continuous
   data transfer.

   The Heartbeat Extension as described in this document overcomes these
   limitations.

So the heartbeat in [D]TLS, as implemented in OpenSSL, is
standard-compliant. It's more useful in datagram communication (i.e. UDP,
connectionless) but it is available for connection-oriented protocols
(i.e. TCP), as well. It was the TLS heartbeat-implementation that
suffered from this vulnerability. You can see the patch-fix here[1], if
you're interested.

[0] https://tools.ietf.org/html/rfc6520
[1]
https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=96db9023b881d7cd9f379b0c154650d6c108e9a3

Re: [gentoo-user] Re: 'Heartbleed' bug

[Chris Walters]

On 4/10/2014 6:59 PM, Alan McKinnon wrote:
>> Steve Gibson explained that the heartbeat feature was introduced in openssl to
>> allow *UDP* connections to mimic the 'keepalive' function of the TCP protocol.
>>
>> IIRC Steve didn't explain how UDP bugs can compromise TCP connections.
>>
>> Anyone here really understand the underlying principles?  If so, please explain!
>>
>> Thanks.
>
> UDP is not compromising TCP connections.
> The software bug allows malicious connecting code to determine the
> contents of memory, which is in use by sshd. How that memory got to be
> there is irrelevant.
>
> There are many lengthy discussions on the internet on how this vuln
> works. You should read them.

While there may be many OpenSSL experts on this list, I believe that the BEST 
source of information on this bug, how it works, what it does, and so forth 
would be the OpenSSL mailing lists.  The official Heartbleed web page has some 
information on it that is a good beginning for researching this bug, the the 
lists I mentioned above are probably the best source of information, after you 
understand the basics from the web page.

Chris Walters

Re: [gentoo-user] Re: 'Heartbleed' bug

[Ralf]

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]

Hi,

On 04/11/2014 12:55 AM, walt wrote:
> Steve Gibson explained that the heartbeat feature was introduced in openssl to
> allow *UDP* connections to mimic the 'keepalive' function of the TCP protocol.
>
> IIRC Steve didn't explain how UDP bugs can compromise TCP connections.
>
> Anyone here really understand the underlying principles?  If so, please explain!
yes, a TCP connection is stateful, so imho heartbeat is not necessary.

But you don't always speak "UDP" or "TCP".
Imagine some sort of direct connection without any type of
transportation layer.

As a generic cryptographic library, OpenSSL is designed to be adaptable
and universal. That broke OpenSSL's neck.

We only can hope, that the heartbeat exploit was not widely used before
they published that zero-day.
But we can be sure, that this is not going to be the last vulnerability
of this kind.

Regards
  Ralf

[-- Attachment #2: Type: text/html, Size: 1416 bytes --]

Re: [gentoo-user] Re: 'Heartbleed' bug

[Philip Webb]

140410 walt wrote:
> Anyone here really understand the underlying principles?

There's an excellent description of the bug + the fix here :

http://blog.cryptographyengineering.com/2014/04/attack-of-week-openssl-heartbleed.html

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca