OpenSSL 1.0.1g available on Axivo repository

And for Debian it's a simple apt-get update then apt-get safe-upgrade. :p
 
Last edited:
We are talking about Linux, they are always slow. And Debian don't have ChaCha20 and Poly1305 ciphers implemented, which are worth gold for security. I was going to release it included but I need to do more testing and see if Google developers have something new worked on.
 
We are talking about Linux, they are always slow. And Debian don't have ChaCha20 and Poly1305 ciphers implemented, which are worth gold for security. I was going to release it included but I need to do more testing and see if Google developers have something new worked on.
The original post did not refer to additional ciphers.... just a vulnerability. ;)
 
:p
And spoil the fun?
Point was that it is important for any Debian users also to grab the latest updates and was just a heads up for them to do it also.
 

According to that page:
According to the currently available information, private keys should be considered as compromised and regenerated as soon as possible. More details will be communicated at a later time.

If keys need to be regenerated then I'm pretty sure you are going to have to create a new certificate to go with it.... but I'm just getting into the SSL biz so @Floren or someone else would have a definitive answer. My theory is "When in doubt, regenerate".
 
Yes, regenerating your certificate with a new set of private keys would be sensible. Updating your passwords across sites is never a bad idea after an issue like this either.
 
So one thing I am curious about... with this exploit and the way it is... are sites that were not using OpenSSL (https) more secure over these last 2 years or so that this existed?
 
So one thing I am curious about... with this exploit and the way it is... are sites that were not using OpenSSL (https) more secure over these last 2 years or so that this existed?
Doubt it, that's like saying processing payment transactions via non-SSL was more secure than with SSL
 
Doubt it, that's like saying processing payment transactions via non-SSL was more secure than with SSL
Well, in this particular case, it's actually true that sites not using SSL were better off.

The entry point into shared memory in this case was directly tied to running an exploitable version of openssl. Any site running the versions effected, could easily be entered into and have their memory scanned.

That's right there in all the overviews of this exploit. That's what makes it so bad.

Bama is right when he suggests not running SSL at all, in this case, was better. Sure, the session they ran without SSL had no encryption, but, they also had no entry point allowing shared memory to be directly read.

There is good reason why the security experts are saying this one is the biggest exploit they've seen in a while... because it is. The old rules don't apply. If you had SSL enable on any of the exploitable versions, you have the risk that someone not only read your certificate, but, also scan memory containing any and all authentication credentials of anyone who signed on during the period they were scanning.

No SSL running means no entry point exploit to run those memory scans.
 
To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.
 
Top Bottom