Page 1 of 2

OpenSSL software risk

Posted: Tue 08 Apr 2014, 21:10
by cthisbear
Newly discovered encryption flaw a 'big deal', say security experts.

http://www.smh.com.au/it-pro/security-i ... zqsb0.html

" With access to the private key, an attacker is able to impersonate a
web server, while still showing a user their connection is encrypted by displaying a golden padlock in their web browser.

The padlock, together with the letters https in a web address, are the indications web users look for to be assured a site is safe and transmitting their data securely. "

Chris.

heartbleed bug

Posted: Wed 09 Apr 2014, 02:30
by version2013

Posted: Wed 09 Apr 2014, 04:00
by ThoriumBlvd
After doing basic reading here including the software site, it appears that there is a weaving of versions 1.0.1 and 1.0.0. I am not consoled by the fact that my own usr/bin/openssl reports when properties are checked that its version 1 (SYSV). The date of record in this Puppy is Mar.4 '13, which does not exclude certain veersions of either 101 or 100.

is there another way to verify the version?

*** Thanks for code mine is 101e... I need the update. ***

PPM has 101g in Package Updates-Slackware

Posted: Wed 09 Apr 2014, 06:22
by Semme
:wink: Couldn't be easier.

Code: Select all

openssl version

Posted: Wed 09 Apr 2014, 20:56
by mcewanw
Yes, a serious bug - people are being advised to change passwords (assuming openssl has been patched to fix the vulnerability) - some banks use openssl...

http://news.netcraft.com/archives/2014/ ... d-bug.html

http://heartbleed.com/

Posted: Thu 10 Apr 2014, 07:27
by ThoriumBlvd
The following site will check for vunerability

http://possible.lv/tools/hb/

Posted: Thu 10 Apr 2014, 14:57
by Terryphi
Versions of openssl before 1.0.1 do not have the heartbleed vulnerability.

Racy and Wary use version 0.9.8 and definitely do not suffer from this vulnerability. :)

Beyond that it is hard to clarify the facts from the media hysteria. Linux servers using openssl 1.0.1 were in danger of leaking usernames and passwords from memory. Whether this is relevant to openssl on home computers running Linux I do not know. Does anyone?

Posted: Thu 10 Apr 2014, 19:43
by ThoriumBlvd
I'd rather be safe than sorry. delta-version here.

BTW this got me looking at the certs in FF23. All the server certs were NG, and a couple of google-related were expired and tossed.

Posted: Thu 10 Apr 2014, 21:02
by Sylvander
http://possible.lv/tools/hb/

Load your SSL site into the page loaded at the above link to test.

What you want to see:
"TLS extension 15 (heartbeat) seems disabled, so your server is probably unaffected."

My banking website tested OK. :D

Posted: Fri 11 Apr 2014, 03:57
by Terryphi
This test site gives lots of data:

https://www.ssllabs.com/ssltest/analyze.html

Posted: Fri 11 Apr 2014, 05:03
by 8-bit
If I have updated openssl on Puppy and I connect to a site whose server is still using an older version, which takes priority?
In other words, would I still be at risk to the heartbleed problem?

Posted: Fri 11 Apr 2014, 06:30
by Terryphi
8-bit wrote:If I have updated openssl on Puppy and I connect to a site whose server is still using an older version, which takes priority?
In other words, would I still be at risk to the heartbleed problem?
Quote from openssl developers:

A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server.


As far as I can see the problem is mainly at the server so that is the openssl version that matters - but I may be wrong! What if you have an insecure version of openssl on your PC? Well, even if it is possible to read your (very) recently used passwords from 64K of memory on your PC you would have to be persuaded to connect to a secure https site containing specially constructed malware to read it. Check any https site using https://www.ssllabs.com/ssltest/analyze.html before you visit it. Most reputable sites have now been fixed.

Posted: Fri 11 Apr 2014, 12:17
by mikeb
Are you telling me my crusty old distros and rusty software are actually SAFER in this respect?!!!

Old devs never die but they do retire. The bunnies writing today's code are not necessarily as sharp as their predecessors or fully realise the implications of techniques that have been previously used.
I suppose that applies generally not only in software... but mozilla does come to mind.

mike

Posted: Fri 11 Apr 2014, 16:12
by 8-bit
Just for curiosity, I checked the server that hosts this forum which I think is GoDaddy.com.
It showed two different addresses with one getting a "B" grade and the other showing a red "F" for fail!
So.... Are our passwords at risk on this forum?

Posted: Sat 12 Apr 2014, 05:52
by Terryphi
8-bit wrote:Just for curiosity, I checked the server that hosts this forum which I think is GoDaddy.com.
It showed two different addresses with one getting a "B" grade and the other showing a red "F" for fail!
So.... Are our passwords at risk on this forum?
Do you connect via https? Usual address quoted is unencrypted (http).

Quotes from SSL Report: ip-208-109-22-214.ip.secureserver.net :

This server is not vulnerable to the Heartbleed attack.

This server does not mitigate the CRIME attack. See https://community.qualys.com/blogs/secu ... nst-ssltls

It fails other tests because the certificates expired 5 years ago.


I would not choose Go Daddy as a host if I needed a secure server!

Posted: Sat 12 Apr 2014, 10:30
by ThoriumBlvd
8-bit wrote:If I have updated openssl on Puppy and I connect to a site whose server is still using an older version, which takes priority?
In other words, would I still be at risk to the heartbleed problem?
Consider the situation as a secure transaction. If EITHER side is vunerable, then BOTH sides are at risk. IOW, If the client is vunerable then the passwd and Client ID are at risk. As you might suspect this can be a major problem doing business on-line, banking, etc. If the server is vunerable ALL CLIENT data submitted is vunerable. As one can see BOTH parties need protection or the link itself is vunerable.

BTW anyone using Slacko-55XL needs the update, the version included is 101e.

Puppy Button --> System --> Updates Manager (from Slackware)

Posted: Sun 13 Apr 2014, 19:32
by solo
Yes hello!

I may not know a lot about this stuff, but as a computer user I have to say the way this Heartbleed stuff is playing out does not exactly instill confidence on my end.
How can this 'just' be a server-side problem if we are talking about a way of establishing a secure connection between the server AND the client?
How is that things are all fixed when we only patch the servers, while every regular computer user who has this software running should do....nothing?

No. My common sense tells me that is not good enough.

Now, I run Precise Puppy 5.7.1, so I need an OpenSSL update for Ubuntu Precise. And I found it here:
https://launchpad.net/ubuntu/+source/op ... ubuntu5.12
Am I correct in assuming that the only thing I have to download from this page is the openssl_1.0.1-4ubuntu5.12.debian.tar.gz, unpack it and install it?
My current OpenSSl version is 1.0.1. from March 2012.

Thank you in advance for any advice.

Posted: Sun 13 Apr 2014, 20:02
by mikeb
You are as likely to need an update to keep software like curl and pidgin happy when servers change their openSSL and gnuTLS arrangements breaking existing software.

MIke

Posted: Sun 13 Apr 2014, 20:12
by solo
Well there you go.

Took a peek in those update packages and understood immediately that an easy update would not be as clean cut as replacing one executable with another.
Oh well....

Posted: Sun 13 Apr 2014, 21:41
by Moat
Hey Solo - FWIW...

As per baloon's info for Precise 5.7.1 posted in this thread - http://murga-linux.com/puppy/viewtopic. ... 6&start=15 - I updated my 5.7.1's PPM and re-installed, right over the top of the old, openssl_1.0.1 and libssl1.0.0_1.0.1 from the PPM.

Then entering 'openssl version -a' in a terminal displays the following, likely indicating it's the same "version", but fixed/updated on April 7th 2014 -

sh-4.1# openssl version -a
OpenSSL 1.0.1 14 Mar 2012
built on: Mon Apr 7 20:31:55 UTC 2014
platform: debian-i386
etc...

I'm just going to assume that's the case, as I'm not too worried about it from a home-user's end, anyways.

Bob