See the "There are three reasons not to panic" part of Another New AES Attack - Schneier on Security the same site and paper which the Mozilla thread referes to.
It's all very interesting, but also theoretical and not very important in the real world..
And there you can read:
And for new applications I suggest that people don't use AES-256.
AES-128 provides more than enough security margin for the forseeable
future.
So yes possibly the attack on AES 265 is theoretical (yet). But you should better use AES 128.
I guess it’s a matter of personal preference, but a lot of time I hear things that I think are kind of a overreaction. People who think AES256 is really broken in practice, that sort of things…
Yeah, I understand.
That’s why I always said it “may be less secure” and there is “probably” an attack.
So I would say that AES-256 is completely okay as a fallback, but AES-128 should be preferred.
However this is already quite off-topic from this thread, so back to topic…
Hi i already explained in the 100% thread that there is an big discussion between AES 128/256.
And yes suche.org it definitely not as secure as A+ 4*100% would tell, because with an trick
i managed to support also clients that would eliminate 100% since they use TLSv1.
But the hint with SHA1 and FF is good 
What “trick”?
20 chars…
If you look at the result you will see that the cipher suite report only list AES236 or CHACHA with TLSv1.2.
But if you look at the client information you will see that there are also TLSv1 connections and AES128.
You can see it under https://www.ssllabs.com/ssltest/analyze.html?d=suche.org
This i call an trick.
Hi, only to get some hard facts about AES 128/256 discussion.
https://www.schneier.com/blog/archives/2009/07/another_new_aes.html
-> Here only AES with fewer round are compared.
https://www.schneier.com/blog/archives/2011/08/new_attack_on_a_1.html
-> Here the full version is compared.
AES-128 => 2^126.1 complexity
AES-192 => 2^189.7 complexity
AES-256 => 2^254.4 complexity
So AES-265 is still the strongest version.
NOTE: Further discussion about this point should go into an “Reply as linked Topic”
This looks obscure. What’s the point? Just to get 100%?
How are you doing it?
as far as I can think it’s the clientHello.
before the server gives away any info (serverhello) the client gives away his, along with data about itself and @tlussnig uses that data to see if it’s an IE for example and chooses the ciphers that are “available” from that.
There are two goals:
to anyone who doesnt know.
Cloudflare allegedly proposed those so called "legacy verified" certificates which could use SHA1 but only for older clients.
to quote:
We propose a new Legacy Verified (LV) certificate. These certificates
would allow legacy signature protocols, such as SHA-1, and only be
issued to organizations that can confirm they properly only issue certs
based on modern protocols to modern browsers while falling back for
legacy browsers.
Finally, the organizations that provide SHA-1 fallback support should
commit that if a vulnerability is discovered which allows some form of
downgrade attack — where a modern browser can be tricked into receiving a
certificate signed with an insecure protocol — and the vulnerability
cannot be patched then they will withdraw fallback support. The CA/B
Forum should make this a requirement of an organization being issued LV
certificates.
CloudFlare has worked to ensure that we can continue to responsibly
provide SHA-1 support for all our paid customers even after the new
year. We believe this is critical for ensuring that we don't cut off the
world's most vulnerable populations from access to encrypted content
online. If you’re not a CloudFlare customer and you are worried about
supporting legacy browsers, make sure you get yourself a SHA-1
certificate before the end of the year. After that, unless our proposal
for LV certificates is adopted, if you want to enable encryption for all
Internet users it will be too late.
Maybe interesting the chrome dev introduce an new curve (29)
So i found that there are some new defined:
case 29: return("ecdh_x25519"); // https://tlswg.github.io/tls13-spec/
case 30: return("ecdh_x448"); // https://tlswg.github.io/tls13-spec/
case 31: return("eddsa_ed25519"); // (Signature Only) https://tlswg.github.io/tls13-spec/
case 32: return("eddsa_ed448"); // (Signature Only) https://tlswg.github.io/tls13-spec/
case 256: return("ffdhe2048"); // (Finite Field Groups) https://tlswg.github.io/tls13-spec/
case 257: return("ffdhe3072"); // (Finite Field Groups) https://tlswg.github.io/tls13-spec/
case 258: return("ffdhe4096"); // (Finite Field Groups) https://tlswg.github.io/tls13-spec/
case 259: return("ffdhe6144"); // (Finite Field Groups) https://tlswg.github.io/tls13-spec/
case 260: return("ffdhe8192"); // (Finite Field Groups) https://tlswg.github.io/tls13-spec/Can you post a link to the source code’s file? Can’t find it anywhere with Google itself 
Already noticed x25519 on SSL Labs client test (development) a long time ago. Catch up! 
Hi Osiris, it is from my client hello analysis. After i found an new unknown elliptical curve in my logs i could assign it to chrome. After that i verified that it is from chrome canary. Then i searched for curve type 29 (0x001D). And i found
an thread discussing ED25519 inclusion in chrome. After that i found https://tlswg.github.io/tls13-spec/ but sadly
i did not found the chrome source the inclusion.
what is x25519? I just know ed25519
ecdh_x25519 and ecdh_x448
-> Indicates support of the corresponding ECDH functions X25519 and X448.
-> http://tools.ietf.org/html/draft-irtf-cfrg-curves-11#section-5