[bcschmerker4]

In several discussions offsite I noticed a trend toward securing of Websites against diverse kinds of hacks.  As of December 2016 Head-Fi™ has a "wide open" HTTP login/logout, an obvious vector for snoops.  Some otherwise "wide open" Websites such as SingSnap® have already implemented secured login using TLS 1.2, and I opened a Topic there concerning migrating TLS 1.2 across the whole site.  From a blog at Cigital®/Synopsys®, I believe the still-draft (as of December 2016) TLS 1.3 would better suit our needs, as it includes at least two less hackable handshake protocols than the Elliptic-Curve Diffie-Hellman Exchange used in 1.2 and a number of ciphers that are sans patent encumbrance.
 
From the perspective of minimizing, to the greatest reasonable extent, all of performance penalties, licensing issues, and vulnerabilities to offsite hackers, several Dan J. Bernstein component designs are in consideration.  Although TLS_X25519_ED25519_CHACHA20_POLY1305_SHA384 would be ideal, I don't yet know whether this exact ciphersuite will be a go.  Same applies to TLS_X448_ED448_CHACHA20_POLY1305_SHA384, which operates handshaking at the 223-bit level rather than the 128-bit level of X25519.  TLS_ECDHE_ECDSA_CHACHA20_POLY1305_RSA_SHA384 might be a suitable fallback in the event X25519 and X448 are excluded.  One financial unknown is the SSL certification by one of several firms such as TrustE®, GeoTrust®, Symantec®, Comodo®, &c.
 
If action to prepare for TLS is not already underway, how rapidly can it be done under best-case circumstances, once TLS 1.3 is published?

 

[bcschmerker4]

Update:  The proposed ciphers for Transport Layer Security 1.3 are for the most part already supported under 1.2, but new syntax is involved.  The Internet Engineering Task Force will support curve25519 alongside three existing United States Department of Commerce elliptic curves, viz., SECP256R1, SECP384R1,. and SECP521R1.  The Elliptic Curve Certificate is a refinement of ECDSA and EdDSA algorithms.  Probably a TLS_ECDHE_ECC_WITH_AES_128_GCM_SHA256 cipher suite (which will report as TLS_AES_128_GCM_SHA256 pursuant to the IETF draft specification, plus Key Exchange ECDHE and Certificate Algorithm ECC_256_SHA256) will best suit Head-Fi's needs.  Recommend using Twisted-Edwards Curve Diffie-Hellman Ephemeral with X25519 for the key exchange, Twisted-Edwards-Curve Certificate 256-bit with ED25519 for authentication, as these will cause fewer headaches than the unforgiving NIST curves cited for ECDHE and ECDSA.

 

[TwinQY]

​I think you might be barking up the wrong tree here. You'd have to contact Wikia about this, as they own and manage the Huddler platform that provide the infrastructure for Head-Fi. I doubt the staff here have direct control over anything technical, let alone the facilities to deploy TLS 1.3. I found a contact email on their site - publishers@wikia-inc.com. I'm not sure if it's the proper one but you could give it a try.
​
​There have been a couple of other threads asking for this in the past.
​http://www.head-fi.org/t/555454/secure-login-facilities
​http://www.head-fi.org/t/727035/no-weak-ssl-support
​http://www.head-fi.org/t/599602/ssl-for-the-forums
​http://www.head-fi.org/t/679270/the-administrators-could-you-please-start-supporting-https
​
​There is a post over on Overclock.com (their forum is also on Huddler) that addresses why Huddler has not yet implemented this.
​http://www.overclock.net/t/1550117/does-password-and-username-travel-in-plain-text#post_23786207
It looked like advertising was the limiting factor.

 

[bcschmerker4]

Thanks for the archived Threads.  It appears as though Wikia® Fandom™ has zero SSL support at all as of 2 February 2017.  That leaves Wikia®, and Head-Fi™ with it, a sitting duck for hackers.  Wikia® Community™ is preparing for Transport Layer Security, but has no estimated launch time as of 2 February 2017 - the Update on Security Measures explains the complications.  (Wikia® has already suffered attacks on several subsites as of 2016.)

 

[WraithApe]

What's with all the trademark symbols @bcschmerker4 ? Afraid of being sued for copyright infringement? 

 

[TwinQY]

Wikia® Community™ is preparing for Transport Layer Security, but has no estimated launch time as of 2 February 2017 - the Update on Security Measures explains the complications.  (Wikia® has already suffered attacks on several subsites as of 2016.)

I was under the impression Wikia Community is separate from Huddler as products - so those things would be a separate affair.
 

  What's with all the trademark symbols @bcschmerker4 ? Afraid of being sued for copyright infringement? 

I think it's just impressive that someone would go through the effort of typing out all those unicode characters like that.

 

[bcschmerker4]

Wikia® Huddler® has apparently adopted TLS_ECDHE_RSA_CHACHA20_POLY1305_SHA256 for Head-Fi™. Considering the problem RESOLVED FIXED. Checked for huddler.wikia.com and hit a 404 error. :-S New service entirely?

 

[TwinQY]

Well, the forums have just moved to Xenforo, which makes it moot. At least Xenforo implements HTTPS. Also, it appears that Huddler is to be phased out.

 

[wink]

Consider it Phased out.....

 

[bcschmerker4]

Just read the information on XenForo Limited - xenforo.com is already running TLS 1.3, which supports AES128_GCM_SHA256, CHACHA20_POLY1305_SHA256, and AES256_GCM_SHA384 under the IETF draft specification. The jump from TLS 1.2 should be straightforward enough, given ECDSA or EdDSA authentication on an ECDH/E key exchange.