• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

OpenSSL 1.0.1g available on Axivo repository

Floren

Well-known member
#3
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.
 

Tracy Perry

Well-known member
#4
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. ;)
 

Tracy Perry

Well-known member
#6
: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.
 

Tracy Perry

Well-known member
#12
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".
 

euantor

Well-known member
#13
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.
 

Brent W

Well-known member
#15
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?
 

p4guru

Well-known member
#16
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
 
#17
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.