It seems the https:// has broken on the Forum Server. Sunday 12 October 2014 @16:42 WAST. My K-Meleon74 raised the alarm with the red URL bar, but couldn’t tell me what was wrong, Opera 12.01 doesn’t have the glaring colours, but does have the Security Info pop-down…
See the attachments in https://forum.avast.com/index.php?topic=52252.msg1133876#msg1133876.
FWIW, it’s still broken.
Gordon.
Hi gordon451,
Prefix handling is not required for subdomains, according to the certificate, so all is for avast dot com.
So same results also for “forum-02.avast.com”.
A Status given here: https://www.ssllabs.com/ssltest/analyze.html?d=forum.avast.com
Only issue there is OCSP status is not available.
Chain issues Extra certs, Contains anchor
Signature algorithm SHA1withRSA WEAK
What I get is
80/tcp open http nginxIs that what you mean, that is not related to the SSL-Certification.
|_http-generator: ERROR: Script execution failed (use -d to debug)
|_http-title: Did not follow redirect to https://forum.avast.com/What you claim could be:
In trust store DigiCert High Assurance EV Root CA
SHA1: 5fb7ee0633e259dbad0c4c9ae6d38f1a61c7dc25
RSA 2048 bits / SHA1withRSA
Weak or insecure signature, but no impact on root certificates
http-title: 400 The plain HTTP request was sent to HTTPS portNo problems, as far as I can see.
| ssl-cert: Subject: commonName=*.avast.com/organizationName=AVAST Software a.s./countryName=CZ
| Not valid before: 2013-10-22T12:00:01+00:00
|_Not valid after: 2016-11-03T12:00:00+00:00
|ssl-date: 2014-10-13T12:14:02+00:00; 0s from local time.
| tls-nextprotoneg:
| http/1.1
See attached scan results.
polonus
@gordon451,
Explaining on what I reported for the error:
|_http-generator: ERROR: Script execution failed (use -d to debug)
Presence of this error positively identifies the device as a BACNet device, but no enumeration is possible. banner … Root privileges on UNIX are required to run this script since it uses raw sockets. … http-generator … When run in debug mode, the script also returns the protocols and ciphers that fail and any errors that were encountered. But there is also the possibility there is none. Displays the contents of the “generator” meta tag of a web page (default: /) if there is one.
With Calomel extension in firefox I get an all green: Security very Strong - Verified Domain Validation -
PFS Yes - 20/20 Issues by DigiCert US valid until 3-11-2026.
Another issue: This domain name is not secured by DNSSEC, therefore it is not possible to verify the validity of remote server certifcate by DANE protocol.
Damian
Hi polonus -
(I’m waiting for mchain to come back to me.)
I never said this was a Certificate error. In fact neither Opera or K-Meleon said that. The exact message, viewable at https://forum.avast.com/index.php?action=dlattach;topic=52252.0;attach=144192 is:
The server attempted to apply security measures, but failed.Since no problems are visible in Certificate reports by both K-Meleon and Opera, then some other non-certificate difficulty is happening. My thinking is that the sever software, nginx, is compromised as I don't think SSL is a hardware thing.
The other screeshots are viewable at https://forum.avast.com/index.php?action=dlattach;topic=52252.0;attach=144194 (Opera pop-down, “Unencrypted connection”) and https://forum.avast.com/index.php?action=dlattach;topic=52252.0;attach=144190 (K-Meleon “Something’s wrong–red URLbar–and it’s not the Certificate”).
Gordon.
Hi gordon451,
This could be a cross-browser related issue or could be a bug in the particular browser that quicks up the error. Are you on the latest version?
In a particular online forum, a user, by the name of “bybe”, came up with this possibility:
This is most likely happening because your not rendering all elements on the page as SSL. (mixed content).Sometimes I also get this yellow triangle initially on the webforum page, but then later I will get the green padlock. Now I get a green constantly.= my quote, pol.Check the source of your page and ensure that local javascripts are loading via /path/script.js and not http://domain/js/script.js.
Also ensure images and every other element is secure. Simply search for “http://” in the source, this includes external scripts/images.
Do you recognize this in any way? In that case the problem was caused by “a to an external font file in the header”. So look for the bug and the proverbial needle in the hay-stack here.
Damian
Just come back to the forum, and would you believe
Sometimes I also get this yellow triangle initially on the webforum page, but then later I will get the green padlock.???
Erm, it’s not the “latest” Opera, v12.17 is the “last supported legacy build” (yes really!), and I’m currently on 12.01… I think I’ll update, I’ve downloaded the binaries. (Opera actually has an update service which installs 12.17 on-demand from v12 editions 8)) K-Meleon can in no sense be regarded as “current”, the *74 release is still not as stable as it should be, but given the 3 and a half developers working on it, and the fact that it is the lightest, fastest and most configurable browser out there… It was and still is the best browser I’ve ever used! (BACK ON TOPIC)
I think you may be right about “http://” content. It used to be a huge problem on https://wikipedia, because they were taking so long to migrate content.
Oddly enough, see this attachment, of the login screen!
OTOH, even the odd page with insecure content is still something to be chased down, as it could conceivably be used as an attack vector. Although “attack” is variable, this would more likely be surveillance-related.
Still, it’s disturbing to find these “weaknesses” in a security-app public forum, especially one that was recently taken down for rebuild after a major breach. As has been heavily promoted on this forum, eternal vigilance is required, no relaxation is permitted!!!
Gordon.
You find security glitches everywhere for protocols and not always best policies are being followened.
For instance where SQL attacks lure all code that is not code with prepared statements is insecure crap.
The idea behind prepared statements is defense against the root of the SQL injection problem is mixing of the code and the data. The idea is very simple - the query and the data are sent to the SQL server separately.
That’s all. (info credits go to rtesh from stack-overflow.
In this case we see secure header policies with issues.
For this forum site you see now: HTTP security headers
Name Value Setting secure
access-control-allow-origin *
x-content-type-options Header not returned
x-xss-protection Header not returned
x-frame-options Header not returned
content-security-policy Header not returned
cache-control Header not returned
Page meta security headers Name Value Setting secure
content-security-policy N/A
cache-control N/A
IForm autocomplete settings Name Type Setting secure
_search_form
HTML form
search
Form element of type ‘text’, child of ‘_search_form’
pmFolder
HTML form
pms
Form element of type ‘checkbox’, child of ‘pmFolder’
pms
Form element of type ‘checkbox’, child of ‘pmFolder’
I
pms
Form element of type ‘checkbox’, child of ‘pmFolder’
Insecure Icon
pms
Form element of type ‘checkbox’, child of ‘pmFolder’
pms
Form element of type ‘checkbox’, child of ‘pmFolder’
pms
Form element of type ‘checkbox’, child of ‘pmFolder’
pms
Form element of type ‘checkbox’, child of ‘pmFolder’
pms
Form element of type ‘checkbox’, child of ‘pmFolder’
pms
Form element of type ‘checkbox’, child of ‘pmFolder’
pms
Form element of type ‘checkbox’, child of ‘pmFolder’
Insecure Icon
pms
Form element of type ‘checkbox’, child of ‘pmFolder’
pms
Form element of type ‘checkbox’, child of ‘pmFolder’
Security Headers for the HTTP content - Summary
Number of Happy Findings: 5
Number of Not As Happy Findings: 5
Percentage Happy Findings: 50%
X-Frame-Options
Good news! X-Frame-Options was found in this site’s HTTP header so the site is safer from clickjacking attacks!
Strict-Transport-Security
Uh oh! Strict-Transport-Security does not appear to be found in the site’s HTTP header, so browsers will not try to access your pages over SSL first.
Nosniff
Good news! nosniff was found in this site’s HTTP header so IE is prevented from trying to sniff MIME types!
X-XSS-Protection
Good news! X-XSS-Protection: 1 was found in this site’s HTTP header so if a cross-site scripting attack is detected, Internet Explorer 8 and 9 will attempt to make the smallest possible modification to the returned web page in order to block the attack!
Promiscuous CORS Support
Uh oh! Access-Control-Allow-Origin: * was found in forum.avast.com’s HTTP headers so your server is allowing any site to request content from forum.avast.com, possibly making sensitive content available to others.
Content Security Policy
Uh oh! We did not detect Content-Security-Policy , x-webkit-csp, or even x-webkit-csp-report-only in the site’s HTTP header, making XSS attacks more likely to succeed.
UTF-8 Character Encoding
Good news! utf-8 was found in this site’s HTTP header, minimizing the likelihood that malicious character conversion could happen.
Server Information
Uh oh! Server: was found in this site’s HTTP header, possibly making it easier for attackers to know about potential vulnerabilities that may exist on your site!
X-Powered-By
Good news! X-Powered-By was not found in this site’s HTTP header, making it harder for attackers to know about potential vulnerabilities that may exist on your site!
Cross Domain Meta Policy
Uh oh! Permitted-Cross-Domain-Policies does not appear to be found in the site’s HTTP header, so it’s possible that cross domain policies can be set by other users on your site and be obeyed by Adobe Flash and pdf. files…
So security and security practices aren’t optimal as you can see from the above results,
polonus
Hi polonus -
Thanks for your reply, it’s nailed the problem completely in my opinion.
I think the best we can do now is leave it here as a forum bug so maybe Avast! management can look at it.
I’m still thinking
it’s disturbing to find these “weaknesses” in a security-app public forum, especially one that was recently taken down for rebuild after a major breach.
So I really do expect Avast! admin to do something about it. User security does after all include defenses against tracking, that’s why we use “https://”.
Gordon.
Hi gordon451,
Appreciate it that you are so security concerned. I’d wish a lot of users would be, but for a lot of them you should understand that these matters are “way over their heads”. In general I have experienced that website and website server security still has a long way to go before it is any safer and so it could be optimized to a great extent (also here). Outdated and not fully patched software is one, not optimal configuration etc. another issue (header security implementations, bad third party plug-in and themes coding and input/output validation are issues that are far from optimal or just missing in a lot of cases. Dom XSS sources and sinks galore etc. etc. are adding to the problem).
When I asking students of a Higher Institute for Commercial, Media and IT Studies what the curriculum had on secure coding, I hear that they “had something on that subject the previous year” but “from the wrong textbook”. At these moments I feel proud to know guys like you here. ;). Keep up asking the right questions to urge towards a better digital security environment.
Damian
P.S. This scan could help a lot of folks: https://www.howsmyssl.com/
pol
That “howsmyssl” site is impressive! Very direct!
If it’s of any help, site admins may want to visit https://forums.whirlpool.net.au/, which is in the process of migrating everything to https. At the moment there are two sections still operating on http, I expect they will be migrated soon, I think they were oversights.
One of the problems with migrating to higher security is that admins must remember to keep the old site, stripped down to a redirect, or some way of intercepting insecure requests and diverting them. This is because many browsers keep complete histories which may not be readily edited; and other apps–like AVs–may have hardcoded IP addresses.
When I asking students of a Higher Institute for Commercial, Media and IT Studies what the curriculum had on secure coding
Yes. I was amazed to discover recently that my ISP is the only one in Western Australia (and probably one of only a very few in Oz generally) to offer TLS on emails… And I think that is only because it has two divisions, one is corporate/business, and it’s simpler to have home users go through the corporate servers. 
Oh well, at least my email is secure up to the ISP. 8)
Gordon.
Hi gordon451,
Good initiatives to change slowly but surely to https-only. Only hick-up here many av solutions are not ready for that situation yet and won’t scan anything but a http site :o. When is decent malware scanning brought to https? That is a situation that some users here do not want to switch to https only because they miss the security of Avast Webshield scanning.
polonus
Supported in V10 (2015). 
Hi Asyn,
O.K. Now only look-out for this holed SSLv3: https://www.openssl.org/~bodo/ssl-poodle.pdf
Google advises to support TLS_FALLBACK_SCSV.
This is important for those users that make a connection whenevr they see WiFi access,
for normal cable users this should a less urgent issue.
polonus
As you understand German, read here: http://www.heise.de/security/meldung/So-wehren-Sie-Poodle-Angriffe-ab-2424327.html
I’m tempted :-\
Gordon.
Go ahead Gordon, it won’t bite.
Did not know we were so "in the flow"with actuality of the “Poodle” hole.
Last night I spread the news on the Avast forums that we expected breaking news via Brian Krebs expecting this.
Now we know that the Google testers stumbled upon this fallback gaping hole exploit in SSLv3.
Disable SSLv3 in Chrome via this Command line flag “–ssl-version-min=tls1” (without “”) if you already want to do this now.
This is what Google plans for the future considering the Poodle hole:
re; https://www.imperialviolet.org/2014/10/14/poodle.html
For firefox give in about:config and look for security.tls.version.min
Change the value for this to 1 to disable SSLv3.
Firefox will support SCSV-mechanisme from version 36 onwards…
Tor browsers are secure by desigm.
In IE go to Extra → Internet Options → Tab -Advanced .-> at Security untick SSL 3.0 and then tick to use TLS 1.0, TLS 1.1 en TLS 1.2
whenever this has not been enabled yet.
polonus
Just for a laugh, set “security.ssl.require_safe_negotiation;true” and maybe also “security.ssl.treat_unsafe_negotiation_as_broken;true”, then go to https://www.howsmyssl.com/.
KM gives me this:
Secure Connection FailedAn error occurred during a connection to www.howsmyssl.com. Peer attempted old style (potentially vulnerable) handshake. (Error code: ssl_error_unsafe_negotiation)
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.</blockquote>I did try (not very hard, you’ll see) to contact them, using Opera.
Have feedback? Leave it on the howsmyssl-upkeep mailing list. Notice a bug? Create an issue on the Github repository.Feedback is very welcome.
The mailing list is maintained by Google Groups, and I do have an account. They want me to join a group before posting. So GitHub… wants me to make a new account… Why? I do that for things I care about, like JIRA at ReactOS. Not to tell someone the hard way his product has a problem. Maybe he doesn’t want to know? Even Open Hardware Monitor doesn’t do this sort of rubbish, you just go there and post.
ReactOS should be ready about the time W7 dies of old age
BTW, I’m using the exact same config settings on this forum. Amazing.
Anyway,
Gordon.
Security header configuration on https://forum-02.avast.com (and recommendations)
http://www.uploady.com/#!/download/wu2ajyxLvBV/7FpuOEXwvGoLr6nk
polonus
Polonus, ahaha.
This thread is nearly 3 months old now… ???