[SGVLUG] OpenSSL exploit

[Eric Gillingham]

Straightforward to fix doesn't mean easy.

You will have to revoke every certificate on the machine, and reset
every single private bit of information that something linked to
libssl could have ever read into memory as it's now exposed, you also
have to write off all previously protected traffic as fully public.

This information should be repeated again and again because I don't
think people are really considering the potential impact.

- Eric

On Tue, Apr 8, 2014 at 1:44 PM, Henry B Hotz <hbhotz at oxy.edu> wrote:
> Agreed!
>
> However it's only (-:™:-) an implementation bug, so it's straightforward
> (-:™:-) to fix. |-P
>
> A couple of months ago yet another protocol error in TLS renegotiation was
> discovered. It's comparable to the one in 2008 that prompted TLS 1.1. AFAIK
> they have not yet even decided how to fix it this time and there is talk
> that the fix should be more comprehensive (and done by different people)
> than the last one. The net effect is to break the cryptographic binding
> between the cert(s) and the channel, permitting MITM attacks (even when
> client certs are used). Short-term mitigation is to disable TLS
> renegotiation. No big deal for short connections, but theoretically a bad
> idea for large data volumes.
>
> This has to be really embarrassing to all the black-funded experts who
> analyzed TLS 1.0 and pronounced it secure. They obviously didn't look at
> renegotiation, only the initial connection.
>
> On Apr 8, 2014, at 11:16 AM, Matthew Campbell <dvdmatt at gmail.com> wrote:
>
> Wow this is major.
>
> Matt
>
> On Apr 7, 2014 6:08 PM, "Rae Yip" <rae.yip at gmail.com> wrote:
>>
>> In case you haven't heard, patch your OpenSSL libraries:
>>
>> http://heartbleed.com/
>>
>> And then change your secrets.
>>
>> John K, you must be feeling pretty smug right now. ;)
>>
>> -Rae.
>>
>
> Personal email.  hbhotz at oxy.edu
>
>
>