bcschmerker4
That's bcschmerker4® to you!
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?
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?