I checked https://forums.comodo.com with Calomel SSL Validation Firefox add-on and found that add-on scores SSL protection as very weak (red colored shield). Why a seasoned security company like Comodo uses a weak SSL protection for its own site?
[attachment deleted by admin]
maybe you can expand about what is “weak” pls?
The certificate isn’t weak, as far as I can tell (100/100 from SSL Labs). But there are some weaknesses, such as limited protocol-support (TLS 1.1 and 1.2 not supported), key-exchange is not forward secret etc.
See analysis here:
https://www.ssllabs.com/ssltest/analyze.html?d=forums.comodo.com
https://sslanalyzer.comodoca.com/?url=forums.comodo.com
From 3 type of encryption algorithms RSA, Digital Signature Algorithm (DSA), and Elliptic Curve Cryptography (ECC), COMODO supports only one (RSA).
Calomel SSL Validation Firefox add-on scores the SSL connection and change the color of the icon in the URL bar. The color of the URL button is currently red (none or weakest security) to orange, to yellow, to blue and finally green (strongest security).
The score of a site is currently made by:
Perfect Forward Secrecy [PFS] = 20%
Key Exchange = 25%
Bulk Cipher = 15%
Message Authentication Code (MAC) = 20%
Certificate Hash Type and Key Length = 20%
Currently, security score of https://forums.comodo.com is very weak (red 42%). You can check Calomel SSL Validation Firefox Add-on @ Calomel.org to know more about their score methodology.
If you check SSL Server Test: forums.comodo.com (Powered by Qualys SSL Labs) you can observe following results -
I like the concept of this Firefox Add-on but it seems to me that in order to use such an add-on you kind of need to put on your “tinfoil hat”. (aka paranoid) For starters, this is a Community Forum and not some eCommerce/eBanking site and ultra high “security” (encryption) is not always necessary. The “grade” Calomel provides the Comodo Public forums is 42/100, which if we were in school would be a failure! I think their assessment of certificates is a little rough around the edges and here’s why:
Calomel deducts 16 out of 40 points for using a SHA-1 signed entity and CA certificates and this is why they’re at 84% on their site instead of a 100%. At the present moment, SHA-1 is the defacto hashing algorithm on publicly trusted digital certificates (SHA2 family/EC signed certificates have yet to take off) but it is the process of being deprecated. 16pts off for that alone leaves me scratching my head as to why. No publicly DEMONSTRATED attacks against SHA-1 exist (to my knowledge) much like MD4/MD5 do. Why treat it as if were broken? SHA2 and EC simply do not have the ubiquity that SHA-1 presently has but that’s also changing as we speak.
Calomel deducts 42 points of 45 points for not making use/supporting Perfect Forward Secrecy (PFS) with TLS 1.1/1.2. (Note: TLS 1.0 is “vulnerable” to other attacks, e.g. CRIME/BEAST, and SSLv3 can not make use of it.) PFS also requires roughly 10-20% more processing power for TLS over other cipher suites so there is a slight performance trade-off that must be explored.
Furthermore, keep in mind for PFS to truly work, the CLIENT (browser) also needs to support it. I don’t know many clients (outside of Chrome) that make use of TLS 1.1/1.2 (by default) to truly take advantage of PFS. What good is PFS if the CLIENT (browser) doesn’t support such a technology? The average person will not know to change this bit for that bit, they usually use what is set at by default or they will ask their “tech guy”, whom I doubt would readily know which bits to change.
In the end, I think (read: my own, not Comodo’s thoughts) such a “grading” system such as the one Calomel is presently using will end up causing confusion among its users as it appears to broadcasts the wrong message. A few popular online banking sites in the US such as: PayPal, BankOfAmerica.com and HSBC ALL show up in red and at a lower “score” than the Comodo forums. What does the score truly say about each of the sites and this test? It appears to be a project in its infancy so it does have time to grow and I will give it a chance but it hasn’t impressed me yet! (I’m hard to please though!)
This is exactly the point browser vendors make, if one asks, why TLS 1.1/1.2 isn’t enabled by default, but vice versa: “there are few servers supporting it”. Support for TLS 1.1/1.2 has been available on both sides for years. Nice to hear, that Google decided to change this.
I don’t know the intention behind this addon, nor am I using it (or Firefox…). But probably it has its focus on encryption and not on authentication. The encryption part is mainly about the used configuration of the server and the provided cryptographic features of the certificate (key length, algorithm for the fingerprint). It is independent of the criteria for the validation level.
Only IE on Windows XP does not support FS. See “Handshake Simulation” for eff.org, for example: SSL Server Test: eff.org (Powered by Qualys SSL Labs)
All current browsers support and use (meaning it’s enabled by default) TLS 1.2. Well actually Firefox lags slightly behind, but TLS 1.2 is enabled by default (and AES_GCM is supported) in Firefox 27 (currently beta).
TLS 1.2 is the most secure cryptographic protocol available. The specification includes the cipher suite AES_GCM, which currently has no known vulnerabilities.
At least Intel-CPUs have instructions (Advanced Encryption Standard New Instructions (AES-NI)) that make encryption and decryption really fast, so no performance-problems. (See ChaCha20 and Poly1305 for TLS) And if performance is a concern, it helps to enable SPDY. 
That makes it hard for me to respect arguments against using TLS 1.2 and AES_GCM. Note: NSS, used by Firefox and Chromium, currently supports AES_128_GCM_SHA256 but not AES_256_GCM_SHA384.
The number of servers that use TLS 1.2 has increased a lot during 2013: SSL Pulse
A good read: SSL/TLS Deployment Best Practices :-TU
Anything less than IE 11 on Vista/7/XP DO NOT have TLS 1.2 enabled by default. The current version of IE for Windows Vista (IE 9) doesn’t support TLS 1.2 by default. 
Not all Intel/AMD CPUs support AES acceleration (or AES-NI) as its mostly chips since 2010. My i7 (quad-core laptop) from late 2009 does not support such capabilities. 
What percentage of devices in service today could take advantage of such enhancements? I doubt its all that much in the grand scheme of things.
SPDY has at least 3 different versions and support for it is not quite there across ALL browsers (notably missing most IE users) and platforms much like SSLv3/TLSv1 is today.
Yeah, but that does not say much for the Mom & Pop sites out there. It only accounts for “popular” sites but its still a welcomed sight to see. Some progress is better than NO progress!
Actually only IE on W7+ supports TLS 1.1 and 1.2. All versions of IE on W7 support TLS 1.1 and 1.2, but only in IE11 are they enabled by default. See Transport Layer Security - Wikipedia When the browser does not support TLS 1.2, TLS 1.1/1.0 is the fallback, so there no risk in using TLS 1.2 as the prefered protocol.
IE9, released 2011-03-14 is far from a current browser. It’s the last version of IE for Vista, but that’s a different and sad story.
You must then experience an enormous lag when visiting for example https://encrypted.google.com with Chrome/Dragon (TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256).
More on supporting CPUs: AES instruction set - Wikipedia
Microsoft is behind, as usual. Only IE11 on W8.1 supports SPDY (v. 3), but that shouldn’t stop anyone from using SPDY to speed up browsing for users using SPDY-capable browsers (Chrome, Firefox, Opera), which is the vast majority of users.
The big players lead, the small follow. Why would Comodo want to be among the late followers, rather than the leaders? Well, it’s too late for the latter, but now would be much better than much later.
And take a look at this Comodo-site: https://sslanalyzer.comodoca.com/ It has very good support, but it prefers cipher suites in the wrong order, IMO. IE11 will use TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, though. (IE11 actively avoids RC4, when possible.)
Got one 
(or better )
Bruce Schneier blogged on a collision attack on SHA-1 back in February 2005.
Therefore, NIST decided that Federal agencies should switch to after 2006 and have to use algorithms of the SHA-2 family for signature purposes after 2010.
Nothing has been publicly demonstrated against SHA-1 at this time much in the same way/speed as MD5/MD4 as from what I have seen and read, its mostly its been theory. If its been “broken” for the past 9 years, why haven’t their been any public attacks to demonstrate it being weak? I think its due to the fact that something doesn’t exist or its too impractical at this time.
With AES GCM, SHA-1 is out of the question. That’s the way to go. Now (if not before). 8)
Please check following articles.
I have not explored the performance trade-off. Perhaps Security/Server Side TLS - MozillaWiki may help to keep the discussion continue in this regard.
As of December 2013, the latest version of all major web browsers support SSL 3.0, TLS 1.0, 1.1, and 1.2.
Please check Transport Layer Security - Wikipedia
All theories, nothing has been publicly demonstrated much in the same way/practicality as MD5 has been proven to be broken back in late 2008. That’s why its being phased out rather IMMEDIATELY replaced like MD5 was. I’d love to see something to prove its broken! ;D
While they may support it, none minus IE 11 and Chrome (~v31) offer higher than TLS 1.0 by default.
For example: Firefox 26.0, Windows 7 (64-bit) does not have an easy user selectable option for TLS 1.1 or 1.2 (latest STABLE available). Presently, TLS 1.2 support in the stable version of Firefox is buggy and even TLS 1.1 has to be enabled via modifying ‘about:config’ (which is not a recommend method for a novice/joe-user to enable this in this fashion) However, the next version of Firefox (v27) should have full TLS 1.2 support according to its release notes [ Firefox Beta Notes - Desktop ] but that won’t be released until early February 2014.
What’s the point in waiting for the last browser to support TLS 1.2? Google’s servers supported TLS 1.2 before it was enabled by default in any desktop browser (see New TLS versions).
If by enormous you mean that I notice a bit of lag, I don’t notice ANY lag when navigating to the page in question. I would expect some lag from the cert if I was using a single core machine but I am not, as its a quad-core on Win7 64-bit, so I expect little noticeable lag on the site in question. >:-D
and didn’t they see some “bugs” with how networks handled TLS 1.2? I would think these bugs are why many people are waiting for implementations to mature and I think its well worth it. (Kind of a Catch-22) Google’s own browser only recently (within the last 6 months) received TLSv1.2 support and I do recall they had some issues with TLS 1.2 early on.
A leading question and an authority argument? Apparently Google is trying to rush/push things. Since when is Google the default standard for what is reasonable? :-X