Does HeartBleed affect Amigas?

Does the heartbleed bug exist in AmiSSL, Amiga OpenSSL and precompiled Amiga versions of libopenSSL??

@xenic
Even, and if, that bug is a bit over-feared. To say truth the real affecting is web servers / nginx and all that "server side" stuff. And even , when let's say your openssl are affected, and you run let's say apache with that ssl and offer stuff on www, then , all you can is to dump memory and find out something, but for real use you should know what exactly you want to find. Memory are big, lot of blocks , all in mess.

Probably, sshd daemons can be somehow affected, but that all make no big worry for amigas for sure. All our server-side software much older than that, and have milions of bugs which no one want to explore and hack (i laugh a bit when find out lately news on aw.net, how piru find out some "bugs" in our network SW, while there is thousands of them of course, enough just to go through any security BZ from year 2000 , and half of them we have).

In other words, imho if to worry about that much, we should care then to update all our server's sw , those old apaches, aamp, and whatever we have as all of this have bunch of hardcore security holes 101%. just no one want or will hack us :)

And aniway a fixed version was already ported:

http://os4depot.net/?function=showfil ... brary/misc/libopenssl.lha

@xenic

Quote:The bug is only in OpenSSL versions 1.0.1-1.0.1f and 1.0.2-beta1. AmiSSL is much older (IIRC 0.9.7), and the libssl I used in OWB is older than 1.0.1 as well.

A fixed version of the OpenSSL libssl.so is on os4dept.net already: http://os4depot.net/?function=showfil ... brary/misc/libopenssl.lha
Everything using shared objects can be fixed by installing this version.

Currently affected AmigaOS software is probably NetSurf (replace the included libssl.so by the 1.0.1g one), and definitely the statically linked curl executable on os4depot.net (don't use the statically linked "curl" until it's fixed but "curl-shared" instead with the 1.0.1g libssl.so).

This is a web site to check an https url to see if its safe. The link was given in a news report on heartbleed a few days ago.

http://filippo.io/Heartbleed/

@sundown

Quote:That's for testing servers, for testing clients you have to use for example https://reverseheartbleed.com/ instead.

A list of a few broken servers, only the top 10000 are tested, is on https://github.com/musalbas/heartbleed-masstest
If you use any of them which were in the initial list (Yahoo, etc.) change your passwords there, but only after checking that they are fixed now and no longer in the current list.

@joerg

Quote:

I don't remember which version of openssl that used, but v3.1 will be released in a couple of weeks and that will use 1.0.1g.

The current CI builds will use it soon too, looks like one of the patches is broken so it didn't build when the version was updated recently.

BTW, if anybody is still wondering what the problem really is, XKCD (as usual) has made a simple and clear explanation: http://xkcd.com/1354/

As you can probably see, the main concern (for most of us) isn't whether the bug exists in AmigaOS implementations, but whether any of your vital information could have been readable in the excess memory returned when someone exploited the hole. For instance, would you call it probable that your submitted username and password were sitting close enough to each other in working memory on a server when you just logged in? Or your credit card number and its expiry date and security code when you are making a payment?

And even if that memory block will normally not be quite as easy to read and understand as XKCD illustrates, it wouldn't take many examples before patterns would be found showing which data are where.

Best regards,

Niels

There is also the issue that in the likely/unlikely (take you pick) event
that some one or organization has been able to obtain the server's
private key in the two years a server has been vulnerable, it will
probably be very easy for them to create very effective mimic sites or
man-in-the-middle attacks.

So, the general recommendation of security experts seems to be
that the vulnerable server certificates be "revoked" as well as new ones
installed.

Is there any way to configure Odyssey to do some sort of checking
for cert revocation?

As a test, try site https://revoked.grc.com, which has a revoked
certificate, but the revocation is not noticed in Odyssey.

TimberWolf, on the other hand, does catch this.

Tom

Thanks to everyone for the information. I thought it would be useful to bring the problem to everyone's attention even if we are unlikely to be affected.

@tbreeden
Quote:

Maybe you have activated the Odyssey option to ignore SSL errors?

@abalaban
Quote:

Nope that's not it.

It seems that the "revoke" feature of SSL Certificates is not widely liked
by browser writers - for performance reasons and also lack of confidence
in its effectiveness. I saw a claim the Chrome just turns it off by default.

I guess no one expected something like HeartBleed and there was
foot-dragging.

Tom