This was announced on the blog and Twitter a few minutes ago: Let’s Encrypt’s CA certificate is now cross-signed and thus trusted!
Blog post: https://letsencrypt.org/2015/10/19/lets-encrypt-is-trusted.html
Never been so happy to see a green padlock in my browser.
6 Likes
SSLLabs is showing a specific OSCP warning for the intermediate cert when looking at the helloworld.letsencrypt.org results at https://dev.ssllabs.com/ssltest/analyze.html?d=helloworld.letsencrypt.org&hideResults=on
Let’s Encrypt Authority X1
Fingerprint SHA1: 3eae91937ec85d74483ff4b77b07b43e2af36bf4
Pin SHA256: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
RSA 2048 bits (e 65537) / SHA256withRSA
OCSP ERROR: Next update not provided
And, of course, the ‘main’ certificate path is warned about due to the Root CA not being trusted yet.
Edit: The following are server setup issues/suggestions. IMHO, a new service demo page like helloworld.letsencrypt.org showing off LE should follow TLS best practices.
First issue is the main Intermediate CA. Let’s Encrypt Authority X1 is not properly sent with the certificate and is indicated as ‘Extra download’. Even if the Root CA has no trust at browsers yet, the official Intermediate/Signing CA cert should be sent with the cert, I think:
Let’s Encrypt Authority X1
Fingerprint SHA1: e045a5a959f42780fa5bd7623512af276cf42f20
Pin SHA256: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
RSA 2048 bits (e 65537) / SHA256withRSA
Second issue is keeping TLS 1.1 enabled. The choice is whether TLS 1.0 is supported or just TLS 1.2 which leaves out a lot of legacy stock Android browsers and old libraries already. TLS 1.1 doesn’t add anything to the list of supported devices nor has other benefit in client support like power saving on mobile devices.
Third issue is the long list of enabled ciphers. There are ciphers on it which no current browser will pick anyway. Perhaps it’s be better to limit the number of ciphers to 2 or 3 of them which are actually used.
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)
By personal taste, I would favor the ECDHE CBC cipher (but only in TLS 1.2) over the DHE and just take the first two on the list. Actually I would enable AES256 ciphers but they should be listed before their AES128 counterparts, not behind, so that they can actually be chosen by the browsers. Too many options are always questionable on security services, and options which require complicated cipher pinning on browser side should be avoided.
1 Like
It's following the Mozilla recommendations. Security/Server Side TLS - MozillaWiki
1 Like
Congratulations!!! Very exciting! Excellent you’re using Mozilla’s recommendations. The way to get an A+ on SSL Labs seems to be adding an HTTP Strict Transport Security with a long max age. Here’s our configuration for https://www.fashion.net:
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
SSLEngine on
SSLProtocol all -SSLv3 -SSLv2
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
Well … the problem is that nobody really understands this long list of includes, excludes, ordering and pattern matching proposed by Mozilla here. The only reason for applying pattern matching is to be upwards compatible, but this list cannot offer that anyway: Once a TLS 1.3 compatible SSL/TLS stack is installed, its added benefits are not automatically considered. That’s why I say: The shorter and more explicit the list is, the better.
But you’re right, I should have labeled that a recommendation, not an issue.
Time has come that admins fully understand what they’re configuring, especially regarding security.
If you’re running a burger shop it wouldn’t be wise to have oysters on the menu. First, it won’t be ordered often. Second, it’s very likely someone who did actually order it will feel sick afterwards. Were the oysters fresh? Did you prepare them properly? Perhaps the customer just fakes and wants you to pay him a reparation?
A modern admin definitely wants to avoid any discussions and surprises in security, not after FREAK, Logjam, BREACH, Heartbleed and BEAST (in any order). For all current browsers the list of ciphers needed for a fixed certificate doesn’t have to be longer than 3 entries for maximum security.
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256
Note that ECDHE-RSA-AES256-SHA384 is missing from the list even if it has better properties than the last on the list, ECDHE-RSA-AES128-SHA256 because, again, no browser would choose it.
For supporting older Android/Java/OpenSSL the following cipher can be added:
ECDHE-RSA-AES128-SHA
and for really ancient browsers another entry would make use of DHE. Remember that in this case you should definitely tweak your DH parameters (primes).
DHE-RSA-AES128-SHA
Those who run LibreSSL could make their Chrome users happy by prepending the list with
ECDHE-RSA-CHACHA20-POLY1305
And if you’re modern and have ECDSA keys, just replace RSA by ECDSA, improving security on some browsers which support stronger ciphers with ECDSA keys than with RSA keys.
Best thing: All of these are supporting Forwand Secrecy. The list of ciphers you’re actually offering with your cryptic SSLCipherSuite string contains a total of 9 ciphers that don’t provide FS but only a single ancient browser (IE8/XP) would actually use one of these (DES-CBC3-SHA), and to me it’s highly questionable to offer non-FS at all.
For example, what would you do if it turned out that the very, very rarely used CAMELLIA has a flaw? You are actually offering it right now for nobody than for hackers and users who explicitly request it for some fraudulent or academic reason. No browser is supporting it, why leave it activated? The same applies to more common ciphers which are actually supported by some browsers but are never used because there are ‘better’ ciphers on the browser’s support list and the server is enforcing stronger ciphers anyway. Drop those ciphers and have a better sleep.
EDIT: You’re sending the Root CA certificate together with your own and the Intermediate CAs’ which is not right. You should only supply all certificates in the certificate path(s) except the self-signed Root CA certificate.
2 Likes
The problem with preferring AES256 is that it's not as resistant to timing attacks as AES128, so in fact AES128 can be more secure.
See Security/Server Side TLS - MozillaWiki
This was already discussed in this community too BTW:
Cipher Suite Order - Apache - #13 by harder
Also here:
I authored the AES 128 vs 256 part 2 years ago and it doesn't seem like
the state of the art has changed since. While the performance difference
is probably not the highest concern, there has been some research that
suggest that attacks on AES256 are easier to achieve than on the 128
variant. The reasoning is that most attack on AES do not directly target
the rounds or the key length, but focus more on side channels like
timing attacks. If AES 128 is more resistant to those than 256, then 128
should be preferred. This thread has more information: Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
by jvehent at Review all cryptographic algorithm and parameter defaults · Issue #555 · certbot/certbot · GitHub
2 Likes
Thanks for the links, rugk. These attacks are very theoretical and far from really affecting current connections. Especially using AES in hardware (AES-NI), whatever its performance may be, should save you from the timing attacks. And as far as I understand it, the other attacks released by Bruce Schneier in 2009 don’t apply at all to regular TLS connections and make very specific assumptions about nonstandard round length, known plaintext and related-key knowledge.
However, I don’t want to go into a debate about the presence or absence of AES256 security qualities. What I wanted say is that it is useless to enforce server-side cipher order (SSLHonorCipherOrder On) and list the AES256 ciphers behind their AES128 counterparts if all browsers which implement AES256 also implement AES128. So only those clients who tweak the ClientHello disallowing AES128 and only offering AES256 would actually ‘benefit’ from supporting this said-to-be weaker encryption based on AES256. Then, why have it on the list at all?
So, presuming “SSLHonorCipherOrder On”, if someone still feels safe with these discovered AES256 weaknesses he should actually put the AES256 ciphers in front of the respective AES128 ciphers – otherwise they’re never used at all. On the other hand, if he doesn’t trust AES256 for some reason, he should just throw these ciphers off the list instead of just moving them to lower priority.
Point is: Don’t use magical pattern matching in the SSLCipherSuite entry. Keep the list explicit and as short as possible. Understand (and possibly document) each used cipher’s strengths and weaknesses and which cipher is used by which browsers and what you think would be an appropriate time to drop it. Use SSL Labs tests early, use them often. Keep an eye on security mailing lists, and check your settings whenever you do an upgrade of any of your SSL/TLS related components (e.g., Apache/nginx, OpenSSL/LibreSSL, CPU with/without AES-NI, certificate renewal, key family upgrade RSA/ECDSA).
1 Like
I’d highly recommend you to continue this discussion at https://github.com/letsencrypt/letsencrypt/issues/555.
There are the real experts, so it might help more to discuss it there.
Currently I have mirrored your post there.
Thanks. In fact, I think it’s something one should discuss with the rule makers who, in this case, might be some guys at Mozilla proposing some ‘best practices’. In fact, I think it’s quite different task to choose a cipher suite offered by a client (and the limited value of the cipher order in times of SSLHonorCipherOrder On) versus a cipher suite for a server.
[quote=“ecdsa-chacha20, post:6, topic:1638”]
For all current browsers
[/quote]Could you clarify, please, what “current browsers” exactly are?
Seems like our sales and security teams understand it completely differently…
Authoritative quite is needed…
In the linked GitHub issues some people from Mozilla are active. Don't forget Mozilla is a main sponsor of LE. 
But I see you already wrote there, so let's discuss it there.
First: Please remember that my statement was made at a time when https://helloworld.letsencrypt.org was just offering TLS 1.1 and TLS 1.2, so this already set the bar quite high. In the meantime, the site’s security bar was lowered significantly by enabling support for TLS 1.0.
Of course, sales teams don’t care about security concerns. And security teams don’t care if the door is locked for everybody. 
I think, there are two ways to define the term: Currently used browsers, or currently maintained browsers. However, a line in between these two should be drawn for defining a sustainable security border.
A lot of people still use their old XP computer or Android 4.1 smartphone to browse the web, and they expect that to work till the dawn of time. And the expectation of marketing people is that no-one is locked out just because he cannot afford a new OS or even new hardware.
OTOH, all major platforms can be upgraded with a modern, a maintained browser. This applies to Android, XP and even OS X, but AFAIK not to all versions of iOS. Just download Firefox or Chrome and you can browse even with your buggy and lousy XP securely. I think, on the transition to TLS 1.3 next year we will see that more and more servers drop support for TLS 1.0, suggesting that their users either upgrade their OS or at least their browser. This will put a significant shift towards maintained browsers.
Here is a list of users:
-
Users browsing with up-to-date browsers. The browsers are actively maintained by auto-update from either the OS or the browser itself. They deserve the best support, and they can use the highest standard in cryptography.
-
Users browsing with yesterday’s browsers. The browsers are not maintained and might not support the latest bells and whistles but this group of people is big, and they have never seen a problem on other sites, so they’d suspect the site’s admin to be in error if your homepage cannot be reached anymore. Just be nice, support them as the security they’re requesting is still good enough.
-
Users browsing with ancient browsers. They are in fact used to getting an error message here and there, and if not for their TLS support, then for their lack of the most recent http/js features. They are like people with dermatophyte who get used to scratching their toes and take a long time to finally seek medical help.
-
Users forced to browse with ancient browsers. They are not free to upgrade due to a requirement for backward compatibility of some old website or plugin (Active X).
-
Users using CLI-based or language-embedded TLS engines, e.g. PHP scripts calling a web API on an ancient OS. They might have invested some money into bringing up the system that time and don’t want to afford the upgrade for some reason.
I think every admin has to choose the list of users he wants to catch, and of course, to honor their security concerns (which might differ from the admin’s concerns, depending on data direction).
IMO, group (5) has a scalability problem already, and since they’re running some business on that, it will hurt one day. It should be clear by now that security has a limited period of time for ROI and has to be rolled out freshly every now and then. Only those who have learned to handle that in a scaling way will survive.
Group (4) is typically aware of the limits they are enforced to handle. They most likely have an alternative browser on their computer which they do for anything else than handling this f*cking old intranet web app. So in fact, their public identity might be more from type (1).
Group (3) is the one who is really in danger. If you really care for your valued users, you could put a filter on the website right now, detecting the cipher they connected with and redirecting them based on the result to a website telling them that you’re happy to have them as a user and that you’re really sorry about the change you have to apply in … whatever, 6 months from now, where it seems you won’t be able to serve them anymore as expected. You could put some hints about solutions they could apply on their side, like suggesting to upgrade their browser or changing to something that handles upgrades better. But one final day, you will disable support for them, either just by your declared schedule or just because of this new TRICKSSL, or FISTLS, or what ever the next successful security breach will be called. The better prepared you and your users are, the easier the migration is.
Group (2) should definitely be supported for as long as possible, until they fall into group (3) one after the other.
I’d suggest to support groups 1 and 2, and offer time-limited support for group 3. These would be the current browsers which should be considered a moving target. Now and always. Everything stays different.
6 Likes
The logic I used in determining my ciphers -
All ciphers MUST support proper Forward Secrecy. ECDHE take priority over DHE
Withing those cipher, first TLS 1.2 AEAD ciphers take priority.
SSLCipherSuite “EECDH+CHACHA20 EECDH+AESGCM EECDH+AES+SHA384 EECDH+AES+SHA256”
That results in 5 ciphers (chacha 20 only for LibreSSL)
Then I add added a single directive for ECDHE capable TLS 1.0 clients.
SSLCipherSuite “EECDH+CHACHA20 EECDH+AESGCM EECDH+AES+SHA384 EECDH+AES+SHA256 EECDH+AES”
Then on servers with RSA certificates where I want to support OpenSSL 0.9.8 or libcurl based clients, I add the following
SSLCipherSuite “EECDH+CHACHA20 EECDH+AESGCM EECDH+AES+SHA384 EECDH+AES+SHA256 EECDH+AES EDH+AES256 !EDH+AESGCM !EDH+SHA256”
That adds a single DHE cipher for compatibility with those crusty clients, and I make sure to generate a unique 2048 DH group for Apache.
My apache build itself already disables weak and RC4.
Anyway that results a small easy to understand SSLCipherSuite declaration that results in a small list of ciphers that works with every browser except some very old browsers that also do not support NSI and thus could not connect to most of my sites anyway, as I tend to run multiple secure hosts on a single IP address.
As far as things like Netscapes list - when I first started looking at TLS security, I looked at their list, and it did not look easy to understand. I like KISS.
KISS logic says Forward Secrecy required, TLS 1.2 priority, AEAD priority within that. Then if needed, add ECDHE for TLS 1.0 clients. Then if really needed, DHE for crusty utility clients that really need to be rebuilt.
Big long declarations like what Mozilla has, they are confusing to read and confusion is bad in configuration files.
1 Like
[quote=“AliceWonder, post:14, topic:1638”]
some very old browsers that also do not support NSI
[/quote]I guess, you meant [SNI][1] (Server Name Indication) 
[1]: https://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
Yes. Sorry, I have hit my head numerous times due to epilepsy and it results in things like abbreviations coming out in the wrong order or wrong words coming out sometimes. Same thing that happens with some football players.
SNI is indeed what I was referring to.
Now, fine, Issue https://github.com/letsencrypt/letsencrypt/issues/555 has been closed by Pull Request https://github.com/letsencrypt/letsencrypt/pull/1261, and guess what, nothing has changed. They’re not improving on the cipher list at all, just stick on the bloated default Mozilla list. Of course, the docs mention possible future changes of either the Mozilla recommendations or LE’s choice, only mentioning future choice of CHACHA20 and not the actually bloating of the cipher list in Mozilla’s recommendations.
As I said, to move things forward (if possible at all), one would have to directly approach Mozilla for their recommendations, not LE. LE will most likely (and for not too bad reason) always refer to Mozilla’s recommendations instead of creating just another set of ciphers.
For the record, here are the remaining topics:
- For modern compatibility, TLS 1.2 is sufficient. There is no modern browser which does support TLS 1.1 but not TLS 1.2, except when support for TLS 1.2 was manually disabled. I don’t think it’s worth supporting this case at all.
- Don’t support such bloated lists of ciphers. Any currently used browser can be approached with much shorter and better understandable lists that can simply rely on whitelisting single ciphers instead of blacklisting the old and bad ones. Pattern matching is understood by less than 5 % of the admins, overestimated. Cipher suites are not the right place to show off ‘mine is longer’.
- In times of
SSLHonorCipherOrder on, it’s completely useless to order stronger ciphers behind weaker ones. Either order AES256 in front of the respective AES128 ciphers or just don’t list them at all. - Don’t offer ciphers nobody uses and for which any target browser will choose a better cipher already on the list. DSS (DSA) keys were phased out from the major browsers, listing the respective ciphers at least in the ‘modern browsers’ scenario is completely unnecessary.
LE has explained in detail why they use the ciphers they use in the doc:
https://letsencrypt.readthedocs.org/en/latest/ciphers.html
That’s the only thing I can say about it. As always you can comment on GitHub and - obviously - use the cipher suite you want for your own server. For other things I’m the wrong contact person and you may better comment on GitHub or Mozilla’s security mailing list or somewhere like this.
Hi @ecdsa-chacha20, I appreciate your efforts to get people to think about these topics and I’m sorry to disappoint you by taking such mainstream existing recommendations as our initial defaults.
As the author of PR #1261, I would like to suggest that you indeed approach Mozilla, and/or let us know about another source of recommendations that will be maintained that we can offer people the ability to track. This is in a sense a logistical problem about how the LE client developers can best keep up with changing recommendations, and trying to evaluate whether an appreciable number of users of our software would be interested in following a particular set of recommendations.
We don’t mean to shut down discussion or fail to acknowledge the usefulness of alternatives to Mozilla’s recommendations for many people. The biggest issue for us is probably, again, maintainability (and transparency).
3 Likes
A post was split to a new topic: Video about TLS 1.3