Guess what, when using a single-core AMD Athlon 64, Winsdows XP and Chrome 32, there is also no lag. The site opens in a fraction of an instant. 
Conclusion: crypto-performance is not an issue for desktop-clients.
They are not waiting any more! 2013 meant a breakthrough for TLS 1.2 (server and client). Big sites like Google, the Wikimedia-projects, Facebook, Twitter etc. have enabled TLS 1.2 and AES GCM. If implementations and networks are stable enough for those sites, they are stable enough for any site.
As I said before, Chromium (and Firefox) uses the TLS-implementation NSS, which added support for TLS 1.2 in version 3.15.1 (2013-07-01), and Chromium added support for TLS 1.2 2013-05-30 (Revision 203090).
Rush? TLS 1.2 was standardised (as RFC 5246) in August 2008. Using it in 2012 is hardly to rush things. But indeed, Google is always pushing things forward, when others sit and wait for someone else to do something.
But Firefox wonât receive mainstream support until Firefox 27 (roughly next month) and Google had to temporarily disable TLS 1.2 in Chrome 29 in Late August 2013 [ Bug: 278370 ]. Just because the underlying libraries are updated to support functionality, doesnât mean theyâre available instantaneously to the vast majority of users as youâre insinuating! It does unfortunately take a little bit of time to get out to the masses.
Considering Adam Langley of Google helped finish/fix OpenSSLâs implementation of TLS 1.2 in⌠2012 (early 2013), I would say its a bit of a rush but who better than Google, a major player and contributor, to get the ball rolling. It was a welcomed push that the industry definitely needed.
I am insinuating anything. You said Chrome was late (âonly recentlyâ) to support TLS 1.2. The obvious reason it did not support it earlier is that NSS did not support it earlier. The first stable version of Chrome to support TLS 1.2 was 29.0.1547.57 (2013-08-20). The issue/bug you mentioned was reported 2013-08-23. 2013-09-03, âwtcâ says that the ânext Chrome 29 Stable update will disable TLS 1.2 to work around this bugâ, but the next stable update was 29.0.1547.76 (2013-09-17), where the issue was fixed. I never saw TLS 1.2 disabled in Chrome. Revision 219882 says âTurn off TLS 1.2â, but it was then merged in Revision 220997, whatever that means. Did Revision 219882 ever reach the stable channel?
Of course issues (as much as possible) need to be fixed before something is released to the stable channel. Firefox has had issues with TLS 1.1 and 1.2, see Bug 733647. With Firefox 27, the issues seem to finally have been fixed. (Already Firefox 24 supported TLS 1.1 and 1.2, but they were disabled by default.)
It was wise to begin experimenting with TLS 1.2 when almost no clients used it. Any issues would not affect many users. Now, when all (not outdated) browsers (I include the soon to be released Firefox 27) support TLS 1.2, implementations and configurations (server-side) need to be as flawless as they ever can be.
If thereâs a publicly demonstrated successful attack on SHA-1, itâs far too late. In this case all certificates, which are still in use are de facto broken and may not be trusted for authentication purposes.
Comodo is selling certificates for periods of one to five years. What did you do to be able to IMMEDIATELY replace MD5? Did you revoke all the valid certificates, which were signed using MD5? Did you hope your customers would throw away their valid but technically broken certificates to buy new ones?
I donât believe we had too many customers (overall) who still had MD5-backed certs so I donât believe it was all that big of a deal. For those that did, I seem to recall that we contacted them immediately to let them know what was going on and explained to them that we had to revoke, within a day or two, and re-issue their certificate with âstrongerâ security (SHA-1). It goes without saying that we didnât charge for their re-issuance. I donât ever recall, over the past 5 years or so, Comodo engaging in a practice to charge for replacement/re-issued certificates unlike some of our competitors that have done or still do!
In the event that SHA-1 is broken much like MD5 was, then I think things might get very chaotic as everyone rushes around to re-issue their certificates with a SHA-2 family signed certificate.
Infosecurity Magazine reported that a German hacker has successfully cracked a six-character implementation of the 160-bit SHA-1 crypto algorithm using a cloud computing resource. The hack was completed in 49 minutes at a cost of just $2.10.
Thank you for the insight. So âimmediatelyâ really meant immediately 
In spite of this fact I believe it would be better not to wait until thereâs evidence, that the attack on SHA-1 is not only a theoretical threat. And you admitted, it could get pretty chaotic on your side, too.
Honestly, I donât remember the time frame. I would hope we gave our customers some notice rather than no notice but I could understand if we revoked first and re-issued later due to the severity of the issue. My own personal curiosity wants to know if SHA-1 is truly broken. As the year (2014) draws on and XP dies (a painful death), you will see more and more publicly trusted CAs start supporting SHA-2 signed certs and maybe if weâre lucky some Elliptical Curve (EC) secured certs vs that of RSA. ;D
Since - as a user - I have to rely on the integrity of server certificates, from my point of view this means the earlier the better. But I understand, that you also want to take care of your customers, who need time to replace their problematic certificates and have no interest in their secure connections being flagged as not trustworthy.
Oh, Iâm sure I will, as Microsoft has announced, that certificates using SHA-1 wonât be allowed in their root store after January 2016.
As far as I am aware existing signed certificates (This includes Root & Intermediate CAs along with entity certs) will be OK until 1 Jan 2017 (~ 3 years from now) rather than 2016 as you believe. After the 2017 date any cert that expires beyond such a date, Windows will no longer accept through Internet Explorer (and other Microsoft governed areas) The only people whom I feel have anything to worry about (based on your point) are those people who presently have SHA-1 certificates that expire beyond 1 Jan 2017. I personally do not believe there to be an obscene amount that expire beyond such a date but I could be wrong. Most of the certificates I encounter on a daily basis are between 12 and 36 months and not any longer. In the event that Comodo does have customers that have certificates that expire beyond the 2017 date, I have no doubt in mind it will be as easy as contacting us with a new (fresh) CSR and re-issuing the certificate to them with a SHA-2 signed certificate. I do not foresee any hassles outside of the normal ones we may encounter on a daily basis.
It is my own personal guess (read: Not Comodoâs) that shortly after XP loses support in April of this year, you will see more and more CAs offer their customers SHA-2 signed certificates either new or re-issuances to transition. I think this is a wise times as it leaves âusâ (industry) plenty of time to transition (2.5+ years) and encounter/address any âgrowing painsâ with SHA-2 and beyond certs.
In other news another SSL/TLS certificate deadline, of note, that will soon be upon is one from the Baseline Requirements, whereby after 1 April 2015, no CA may issue a such a certificate for a period greater than 39 months (3 years + 3 months), which is a much welcomed change.
Thank you for your comprehensive answer. I didnât read Microsoftâs changed policy itself, just the linked article about the policy change. I took the date from there, I donât know if this was meant only for new certificates.
Nice to read about Comodoâs customers, but this topicâs topic is Comodoâs sites/servers.
Here is what is used when visiting some of Comodoâs sites with Chrome 32 on Ubuntu (green means good, red means bad):
https://www.ccloud.com/ TLS 1.0, CBC 256, SHA-1, RSA
https://www.comodo.com/ (mixed content (font)!) TLS 1.0, RC4 128, SHA-1, ECDHE RSA
https://help.comodo.com/ TLS 1.0, RC4 128, SHA-1, ECDHE RSA
https://dns.com/ (mixed content (Facebook)!) TLS 1.0, CBC 256, SHA-1, DHE RSA
https://www.loginpro.com/ TLS 1.0, CBC 256, SHA-1, DHE RSA
https://forums.comodo.com/ TLS 1.0, CBC 256, SHA-1, RSA, TLS-compression!š :o
https://sslanalyzer.comodoca.com/ TLS 1.2, RC4 128, SHA-1, ECDHE ECDSA
https://valkyrie.comodo.com/ TLS 1.0, CBC 128, SHA-1, RSA
https://friends.comodo.com/ TLS 1.0, RC4 128, SHA-1, ECDHE RSA
https://sslanalyzer.comodoca.com/ is the only Comodo-site I have found that supports TLS 1.2. It also supports a lot of cipher suites, including the best (AES GCM), but the stupid server prefers the worst of them: RC4, which should not be supported at all. Insane! IE11 ignores the serverâs prefered order and uses AES GCM, but Chrome lets the server decide.
AES CBC should only be used (if at all!) with TLS 1.1, 1.2 which mitigates the Beast-attack server-side. RC4 should not be used at all. Period. Itâs âfundamentally flawed and must be replacedâ (A. Langley).
Adam Langley wrote A roster of TLS cipher suites weaknesses.
Ivan RistiÄ: RC4 in TLS is Broken: Now What? | Is BEAST Still a Threat?
š Supported by the server, but not supported by Chrome.
Chrome 33 prefers ChaCha20+Poly1305 (256 bit) as cipher suite. The complete list (from https://www.ssllabs.com/ssltest/viewMyClient.html):
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc14) Forward Secrecy 256
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc13) Forward Secrecy 256
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Forward Secrecy 128
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Forward Secrecy 128
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) Forward Secrecy 128
- TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) 128
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Forward Secrecy 256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Forward Secrecy 256
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) Forward Secrecy 256
- TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
- TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007) Forward Secrecy 128
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Forward Secrecy 128
- TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Forward Secrecy 128
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Forward Secrecy 128
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) Forward Secrecy 128
- TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x32) Forward Secrecy* 128
- TLS_RSA_WITH_RC4_128_SHA (0x5) 128
- TLS_RSA_WITH_RC4_128_MD5 (0x4) 128
- TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
- TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 168
Googleâs servers support and prefer ChaCha20+Poly1305. Example
Good that AES GCM is not the only secure cipher suite.
Draft: draft-agl-tls-chacha20poly1305
Adam Langley: ChaCha20 and Poly1305 for TLS
Edit: changed version of Chrome from 34 to 33.
Wow! Thanks for the upgrade! :BNC (:CLP) :â â â â (:KWL) (:NRD) :SMLR
Just noticed. Report: SSL Server Test: forums.comodo.com (Powered by Qualys SSL Labs)
Chrome/Dragon (etc) now uses TLS_DHE_RSA_WITH_AES_128_GCM_SHA256.
And two days ago Firefox 27 with support for TLS 1.1 and 1.2 was released.
Now 28,2 % out of the 159 360 most visited sites support TLS 1.2š.
Glad to see Firefox with TLS 1.2. I am probably a little paranoid but it having the latest security never hurts. 
Using secure protocols certainly does not hurt. I think support for SSL 3 should be removed. Itâs time to leave SSL behind altogether, itâs obsolete and insecure.
DHE, however, âhurtsâ performance, much more than ECDHEš. ECDHE_ECDSA is considered to be the best forward secret key-exchange, with ESDHE_RSA being the second best option.
To boost performance even more, SPDY should be used.
Regarding security, what remains to be enabled is Strict Transport Security, and forward secrecy for IE and Safari, according to the Handshake Simulation².
š TLS & Perfect Forward Secrecy
² SSL Server Test: forums.comodo.com (Powered by Qualys SSL Labs)