Tests and other Media topics

It’s actually the cyber crook that caused this problem. It’s their exploitation of this ‘weakness’ that’s the problem. :slight_smile: (I’m being sarcastic.)

Hi bob3160,

And did not government promise recently they would no longer sit on these hacks, but to reveal them to us? ;D

All your weakened encrypted traffic could be easily siphoned and decrypted by design, alas large parts of that traffic.
Read: http://www.dailydot.com/politics/logjam-vpn-top-sites-vulnerability/

UC Browser, very popular in China was deliberately being infested by NSA etc.: https://citizenlab.org/2015/05/a-chatty-squirrel-privacy-and-security-issues-with-uc-browser/

Intelligence services “helped” general internet security big time during recent years with their paranoia (ironic and sarcastic remark) :()

polonus

I think the key (excuse the pun) here is might and being broken by a nation-state. When it comes to nation states, they might have the resources to break it, but you would have to wonder, would they want to I’m sure this type of stuff would have to be attractive enough to make it worthwhile.

Hi DavidR,

That is not the point here, whether government had the might to decrypt weakened encryption for global surveillance purposes. I understand we normally don’t do that in our homes. The point is that it was done deliberately by having stronger encryption restrictions for everyone abroad and downgrading the initial encryption strenght to be able to decrypt.
Particular governments and big corporation entities worked hand in foot to achieve such a situation.

Who was asking for normal secure encryption strength to be deliberately and secretely lowered to an extent so that eavesdropping mode could be reached. Those with strong encryption were not endangered in the first place (cybercriminals etc.), the security of the normal law-abiding citizen was endangered big time and these citizens weren’t aware.

Now webmail and webserver admins all over the world have to clear up the mess after some parties could realize their global surveillance wet dreams. and parts of the internet will stay inherently insecure and dangerous in the aftermath.
Big Brother has arrived and he will never go away again.

polonus

Big Brother has arrived and he will never go away again.
Big Brother has been there since 2007 so this certainly isn't new. Almost all the surveys I've read also confirm that most people don't care. It's only some of the Geeks that seem to get their feathers ruffled any time one of theses articles comes out. :)

Hi bob3160,

Geeks or no geeks, it seems general security awareness is at an ever low ebb to-day. As you said it right, bob3160, the common user isn’t interested that much. However some parties could do a much better job… Education is where to start - we let toddlers have a smartphone or tablet very early in life. They can work it before they have even learnt to ride a little bike.

But we have also to eduate others. Users to better protect themselves and website owners and hosters and server- and CMS-admins to better implement with security at heart. Our modern society as a whole and our very cybersecurity depends on it.

We should not want to tolerate insecure scripting anymore, not tolerate excessive header version info spreading to the world and hackers and attackers alike. No longer tolerate parties not to run latest updates and patches, configure the available header security in a way that is called best practices, not offer encryption from the weak end up, so cybercriminals and government entities can do their self-assigned deals.

Isn’t there a better or more noble task for avast support, then to educate with security at heart for a safer and more secure internet. I like to be part of such a benevolent mission and has been in the past years thanks to Avast creating an opportunity to do so and add to user security. Yes and I am a proud Avast user and I have the best deals for Avast and Avast’s friends at heart. Let us stand together and on the good side always.

polonus (volunteer website security analyst and website error hunter).

Education is where to start
I'm now in my 5th year of doing exactly that through the [b][url=https://forum.avast.com/index.php?topic=78426.msg647360#msg647360]Avast sponsored security presentations[/url][/b]. :) Another way Avast is helping keep computer users secure and a bit more educated. :) The service is also totally free.

We all thank you for that, bob3160!
Users should have such pitch days!
These forums brought us a lot.
I am grateful.

polonus

Logjam workaround for firefox:
Until patched you can:

Disable the insecure ciphers here:

(1) In a new tab, type or paste about:config in the address bar and press Enter. Click the button promising to be careful.

(2) In the search box above the list, type or paste ssl3 and pause while the list is filtered

(3) Double-click the security.ssl3.dhe_rsa_aes_128_sha preference to switch it from true to false (this usually would be the first item on the list)

(4) Double-click the security.ssl3.dhe_rsa_aes_256_sha preference to switch it from true to false (this usually would be the second item on the list)

That’s it, you can test using: https://www.ssllabs.com/ssltest/viewMyClient.html

Credits go to MozillaZine’s jscher2000

polonus

Always surf encrypted via: https://encrypted.google.com/
See: http://toolbar.netcraft.com/site_report?url=https://encrypted.google.com
Issues: https://foundeo.com/products/iis-weak-ssl-ciphers/test.cfm?test_domain=encrypted.google.com
Good News! This site is safe from the Logjam attack. It supports ECDHE, and does not use DHE.
IP Connected TLS Insecure DHE_EXPORT DHE Chrome
216.58.216.238 No
Not Supported

ECDHE
2607:f8b0:4009:809::200e

But vulnerable to Poodle: Scan results
GOOGLE.COM:443 (216.58.219.206) - VULNERABLE

Startpage SSL xpi can no longer be installed under Firefox (ESR) 38 : broken .

pol

HSTS Preloading: https://scotthelme.co.uk/hsts-preloading/
link article author -= Scott Helme.
https://blog.nvisium.com/2014/04/is-your-site-hsts-enabled.html
It being a double-edged sword: https://www.leviathansecurity.com/blog/the-double-edged-sword-of-hsts-persistence-and-privacy/
Also read here: http://stackoverflow.com/questions/10629397/how-to-disable-http-strict-transport-security
Already included: http://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json
Included there is no guarantee for security: -braintreegateway.com → Warning! This site uses a commonly-shared 1024-bit Diffie-Hellman group, and might be in range of being broken by a nation-state. It might be a good idea to generate a unique, 2048-bit group for the site.
IP Connected TLS Insecure DHE_EXPORT DHE Chrome
204.109.13.100 No Common 1024-bit Prime ECDHE
The security header configuration for this site also has a lot of issues, see attached.

polonus

Another test site and another test to take:
Safe.

We have examined your OS and browser version information and determined that an active vulnerability test was appropriate. Fortunately, your browser correctly aborted loading our test image upon seeing an invalid ServerKeyExchange message.

https://gotofail.com/#
And here: https://www.howsmyssl.com/
Verdict probably OK - (not tested here: Logjam Vulnerability (Experimental)
Your user agent is vulnerable. Upgrade as soon as possible.
But we do not have an update yet, hurry up Google developers,
because criminals on coffee-shop Wi-Fi networks are also abusing Logjam and not only state actors!

polonus

Logjam mitigating efforts and tests: https://news.ycombinator.com/item?id=9574408
Is avast VPN patched? Update your VPN Server: VPN servers that support IKEv1 protocol for encryption should be updated to disable any keysize less than 1024 bits – or better yet, use elliptical curve keys. Organizations should also consider using SSL VPN technology, which is better supported as its underlying OpenSSL is updated regularly against various encryption protocol vulnerabilities.
Read about affected Cloud Services: https://www.skyhighnetworks.com/cloud-security-blog/logjam-exposed-575-cloud-services-potentially-vulnerable-to-man-in-the-middle-attacks/

polonus

In the light of all the recent data breaches it is a good thing to test here:
https://haveibeenpwned.com/
Sometimes one can/could get a “Oh.no catastrophic failure!”.

polonus

Still around Freak vulnerability
However, even if your browser is safe, certain third-party software, including some anti-virus products and adware programs, can expose you to the attack by intercepting TLS connections from the browser. If you are using a safe browser but our client test says you’re vulnerable, this is a likely cause.
Test here: https://freakattack.com/clienttest.html
Read: https://freakattack.com/
You can also test here (freak test included) - all not on IE are vulnerable to logjam: https://www.ssllabs.com/ssltest/viewMyClient.html

pol

Check your client against FREAK: https://freakattack.com/clienttest.html
Mozilla config recommendations: https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations
Server test: https://www.ssllabs.com/ssltest/

polonus

Must have learned something over the years. :slight_smile:

http://www.screencast-o-matic.com/screenshots/u/Lh/1432640423513-4078.png

Mine passed too. I must have learned from Bob :smiley:

I haven’t changed a thing and mine doesn’t fail nor does it pass as the site can’t even run the test unless I allow NoScript for the site and allow RequestPolicy (continued) for the three other sites.

Only when I give implicit permission does the test run and complete and record "Good News! Your browser appears to be safe from the FREAK attack. "

This is why I rarely bother with these types of tests because of my locked down setup with NoScript and RequestPolicy it isn’t going anywhere to test. The same should be correct for a live incident.

Hi DavidR,

Only minus here is that for logjam and freak NoScript and RequestPolicy do not protect.
You cannot be protected by neither NoScript nor RequestPolicy against RSA vulnerabilities.
You should be glad that you have checked the test that was provided here, seen in the line of SSL-weakening that is brought about by many a AV https-scan, read from someone who is concerned and where AV https scanning made users vulnerable to FREAK attack as we test: https://blog.hboeck.de/archives/869-How-Kaspersky-makes-you-vulnerable-to-the-FREAK-attack-and-other-ways-Antivirus-software-lowers-your-HTTPS-security.html link article author = Hanno Bock
Why AV https scanning does not perform certifcate-pinning - why? Read here: https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning

polonus (trust what you test yourself)

To read Avast’s official reaction from Deborah Salmi: https://blog.avast.com/2015/05/25/explaining-avasts-https-scanning-feature/

D