Elliptic Curve Cryptography (ECC) Support

But resubmitting your cert to a log will get you your CTS. As Let's Encrypt currently doesn't have a method of retreiving the CTS of your cert, the resubmit-method is the only way I know..

2 Likes

Exactly. Then, I provide the SCTs with Apache TLS Extension. So, how can I provide two “batches” of SCTs based on the certificate used?

1 Like

I tried to add another SSLOpenSSLConfCmd ServerInfoFile in the virtualhost, but i get some ssl errors from apache. There maybe some context problem i guess.

So after some tries, i “merged” with cts-cat.php the two tls extention in one and it seems to work. The downside is that as the extention provides signed logs for the two certificates, the client will get extra responses that are considered invalid.

But strangely chrome does not seems to be unhappy.

Does someone has the correct way to do this with apache ? (besides mod_ssl_ct)

1 Like

Thanks a lot for supporting ECDSA certificates! Now I can use authenticated ciphers (AES_GCM) on IIS (WinSvr2012R2) and on the IE11 clients on Win7/8.1.

For my own sites, I took the opportunity of using a ECDSA certificate to disable TLS 1.0 and 1.1 and all non-AEAD ciphers like AES_CBC (as, according to Adam Langley, "everything less than TLS 1.2 with an AEAD cipher suite is cryptographically broken’). This means some older clients cannot connect to it (e.g. Safari on OSX 10.10), however IE11 on Win7 can connect, so this is OK for me.

Because browsers like Firefox and Chrome don’t use AES256_GCM (as the security benefits of AES256 are not to be worth the performance tradeoff, as stated on a chromium bug entry) and a P-256 ECC key only provides ~128 bit symmtric key strength, I also disabled AES256, and because Chacha20_Poly1305 is not yet supported on SChannel, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 remains as the only available cipher. :smile:

Here is the Ssllabs report for one of my sites. :slightly_smiling:

2 Likes

@T917820981726, just OCSP Stapling doesn’t seem to work for the site you refer. Everything else looks good (however, you just issued a 256-bit ECDSA key and not a 384-bit one … would have gained extra points in the SSL Labs test. (100/100/100/80), and offering AES256_GCM in addition would have brought you a 100/100/100/90. Just for the scoring nerds. :wink:

1 Like

Exactly. And FYI this config is better than the one of suche.org by @tlussnig. Do not mind that you do not get 100% everywhere, that’s not what you want.
FYI Firefox chooses a SHA-1 HMAC on suche.org, which is not really secure. That is why you should not follow such 100% guides…

BTW the more important reason to use AES with 128bit than 265bit is that the 256bit version may in fact be less secure than the 128bit version, because timing attacks are probably possible.

@ecdsa-chacha20 No, not “gain extra points”. 384bit ECDSA key is unnecessary and as explained above AES256_GCM may be less secure than AES128_GCM.
But I agree that OCSP stapling could be enabled and possibly certificate transparency.

2 Likes

As far as I know, those attacks on 256 bit AES were with variants of AES with less rounds than the officially used cipher.. So yes, there are attacks possible on AES, but those shortcomings aren't usable in the wild, because the variants used in the attacks were artificially weakened.

1 Like

Do you have any sources, which support your claim?

My is this: Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
It is old but as @jvehent said in the GitHub issue:

it doesn't seem like the state of the art has changed since [two years]

Obviously you may always suggest a change of the prioritisation in this issue or in Mozillas repo.
And if your comment is valid it even does only mean that AES 265bit is not less secure than 128bit, which still means that there is no advantage of AES 265bit.
And as you see there was already a discussion there.

1 Like

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..

1 Like

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.

1 Like

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…

1 Like

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…

1 Like

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 :slight_smile:

2 Likes

What “trick”?

20 chars…

1 Like

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.

1 Like

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”

1 Like

This looks obscure. What’s the point? Just to get 100%?

How are you doing it?

1 Like

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.

1 Like

There are two goals:

  1. To show that not only RSA / EC (incl curve) can be selected based on client hello.
  2. To get an feeling how the so called LV certificates should work.
1 Like

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.

2 Likes