Im testing a NextCloud 12.02 VM using Ubuntu 16.04.2 LTS. My LetsEncryt worked great and my temp domain works as well. Some of our corporate customers must use IE11/Win7 as company IT policy (not Chrome or Firefox on local machines) and they can not connect to the website. The IE11 display is “This Page can not be Displayed”. I receive no errors. If I use Firefox Chrome, MS Edge or even IE11/Win 10 it works fine. Using the SSL Labs test results in the following two lines for IE11/Win7:
IE 11 / Win 7 R Client does not support DH parameters > 4096 bits
RSA 4096 (SHA256) | TLS 1.2 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | DH 8192
I know that the NextCloud LetsEncrypt sets the HD at 8192. I also can get the IE11/Win7 to connect if unchecking TLS 1.2 under advanced settings. My options appear to be redoing at a DH of 4096 or changing the order presented to IE11/Win7 of connection options to the first that works?
why not contact nextcloud support about this?
It seems a software specific issue, so they should be able to advise how to get IE11 working or if its supported
https://nextcloud.com/support/
Andrei
I was not exactly sure whom to reach out to first. Apologies. I will reach out to nextcloud now. If they do resolve the issue I will post the resolution here for future reference. Many thanks!
DHE is very problematic as it doesn’t negotiate the DH size.
When used it should not be at the top of the list.
So reordering should do the trick.
Assuming that nextcloud is setting the ciphersuite policies for you in the server, you could point them to the suggestions at
https://mozilla.github.io/server-side-tls/ssl-config-generator/
which are pretty well-reasoned in terms of security and compatibility issues.
I have posted the question to the nexcloud forums. I did find a solution but maybe its best to ask here as follows:
I found this as the main link for the letsencrypt script:
I can alter the DHPARAMS to 4096 instead of 8192. That shoud theoretically allow for IE11/Wini7 to connect.
My nextcloud question was for this was: Is does this file get replaced during a upgrade? If I change the file I could make it read only if needed. If the script stays the same I should be ok. My only other concern is either early expiring the current certs now and running the script again to renew with the new DHPARMS. I read the revoke process is more trouble then its worth.
The IE11/Win7 DH > 4096 issue should be solved by this. From a letsencrypt point of view any suggestions or thoughts would be appreciated.
create_config() {
local method="$1"
if [ -d “$CERTFILES” ]
then
if [ ! -f “$DHPARAMS” ]
then
openssl dhparam -dsaparam -out “$DHPARAMS” 8192 <-- change to 4096
fi
check_command bash “$SCRIPTS/test-new-config.sh” "$domain.conf"
exit
fi
}
Probably. I would suggest sending your fix to them as a pull request, since you're probably not the only one having this problem. Then it won't matter when it is upgraded. 
There is no need for 8192-bit Diffie-Hellman unless you also have a 8192-bit RSA certificate, which I don't think any CA will issue, so there really is no reason for them to be making them so large. They set the keylength in the certificate to 4096 bits in the same script so the dhparams really should match.
Thanks for the recommendation. I opened a pull request but I think I pooched it. So I also added it to the Issues on its Github page. A bit new to this part of the process.
I have altered my script and want to test. Is there a way to early expire a cert and let the script just renew with the new DH value or is it better to revoke. In my google fu and referring to your forums revoking seems to be frowned on for this kind of goal. The script will see the current dh perm file and just renew with the same parameters. I would like to either start from scratch so to speak or remove the dh perm and just renew. Any links or suggestions would be helpful. I want to test my suggestion myself and take any foobars I create myself first. If the script is changed as per my pull request/issue I may need to suggest some extra code to alter a existing 8192 DH value down to 4096. Again please just point me in a decent direction and I will research/test. Many thanks for the help so far!
Hi @sync,
You can modify the renewal conf file for your domain so certbot renew command will try to renew it.
The conf file should be here:
/etc/letsencrypt/renewal/yourdomain.conf
And you can edit it, uncomment the first line and change the days:
You will see this:
# renew_before_expiry = 30 days
And you can change it to this (certbot renew will try to renew if certificate will expire in 89 days)
renew_before_expiry = 89 days
so nextime certbot renew command runs, it will try to renew your cert.
Note 1: Remember to change this value to its default or you could reach the rate limits.
Note 2: Revoking a certificate has no effect in this situation and revoking it should only be done if your private key has been compromised or publicly exposed.
You don't need to renew your cert to change the dhparam file, just create a new dhparam file with 4096 bits instead of 8192.
The script you are using to install nextcloud, creates the dhparam file here:
/etc/letsencrypt/live/yourdomain/dhparam.pem
So, backup this file (as root):
cp /etc/letsencrypt/live/yourdomain/dhparam.pem /etc/letsencrypt/live/yourdomain/dhparam8192.pem
And create a new one (as root):
openssl dhparam -dsaparam -out /etc/letsencrypt/live/yourdomain/dhparam.pem 4096
Note: In above commands you will need to change yourdomain by your real domain 
Reload apache and you are done
systemctl reload apache2
Your site will use this new DH file (4096 bits) and you could access using IE11/Windows 7.
I had no time to review the nextcloud update script but I don't know why this update script should try to generate a new dhparam file, it shouldn't because you have already one defined.
Cheers,
sahsanu
Your suggestions/instructions were excellent and worked. As for the script it uses a if [ ! -f ] statement so if the dh perm file exists already it will not be overwritten. I will follow up with the NextCloud VM team with the results you helped me achieve. Thank you!
I’m the Nextcloud VM dev, thank you for good pointers.
By the way, there might be ciphersuite settings that would still allow using larger DH parameters, by placing a different forward-secret ciphersuite that’s supported by IE11 (specifically, some ECDHE ciphersuite) earlier in the ciphersuite list so that it will be preferred.
To schoen and All:
For reference, here are the IE11 results from DH 4096:
IE 11 / Win 7 R RSA 4096 (SHA256) TLS 1.2 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 DH 4096 FS
IE 11 / Win 8.1 R RSA 4096 (SHA256) TLS 1.2 > http/1.1 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 DH 4096 FS
IE 11 / Win 10 R RSA 4096 (SHA256) TLS 1.2 > http/1.1 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
To schoen and All:
Again for reference, here are the IE11 results for DH 8192:
IE 11 / Win 7 R Client does not support DH parameters > 4096 bits
RSA 4096 (SHA256) | TLS 1.2 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | DH 8192
IE 11 / Win 8.1 R Client does not support DH parameters > 4096 bits
RSA 4096 (SHA256) | TLS 1.2 > http/1.1 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | DH 8192
IE 11 / Win 10 R RSA 4096 (SHA256) TLS 1.2 > http/1.1 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
To schoen and All:
If there is a better ordering of the ciphersuite settings hopefully this will help select it.
SECURE CIPHER ORDERING TIPS:
- SHA2+ then SHA1 then 3DES then RC4 then MD5 (as needed)
- DH then NON-DH
- GCM then CBC
- SHA384 then SHA256
- AES256 then AES128
- EC then NON-EC (ECDHE before DHE)
- Wherever possible use only TLSv1.2 (or higher)
Here is an ordered list based on recent openssl ciphers:
(OpenSSL 1.1.0 25 Aug 2016)
Again, use only the ciphers that you need.
SHA2+:
++DH:
++++GCM/POLY:
++++++SHA384:
++++++++NON-EC:
++++++++++ECDHE-ECDSA-AES256-GCM-SHA384
++++++++++ECDHE-RSA-AES256-GCM-SHA384
++++++++NON-EC:
++++++++++DHE-RSA-AES256-GCM-SHA384
++++++++++DHE-PSK-AES256-GCM-SHA384
++++++POLY:
++++++++EC:
++++++++++ECDHE-ECDSA-CHACHA20-POLY1305
++++++++++ECDHE-RSA-CHACHA20-POLY1305
++++++++++ECDHE-PSK-CHACHA20-POLY1305
++++++++NON-EC:
++++++++++DHE-RSA-CHACHA20-POLY1305
++++++++++DHE-PSK-CHACHA20-POLY1305
++++++SHA256:
++++++++EC:
++++++++++ECDHE-ECDSA-AES128-GCM-SHA256
++++++++++ECDHE-RSA-AES128-GCM-SHA256
++++++++NON-EC:
++++++++++DHE-RSA-AES128-GCM-SHA256
++++++++++DHE-PSK-AES128-GCM-SHA256
++++CBC:
++++++SHA384:
++++++++NON-EC:
++++++++++ECDHE-ECDSA-AES256-SHA384
++++++++++ECDHE-RSA-AES256-SHA384
++++++++++ECDHE-PSK-AES256-CBC-SHA384
++++++++NON-EC:
++++++++++DHE-PSK-AES256-CBC-SHA384
++++++SHA256:
++++++++AES256:
++++++++++DHE-RSA-AES256-SHA256
++++++++AES128:
++++++++++EC:
++++++++++++ECDHE-ECDSA-AES128-SHA256
++++++++++++ECDHE-RSA-AES128-SHA256
++++++++++++ECDHE-PSK-AES128-CBC-SHA256
++++++++++NON-EC:
++++++++++++DHE-RSA-AES128-SHA256
++++++++++++DHE-PSK-AES128-CBC-SHA256
++NON-DH:
++++GCM/POLY:
++++++SHA384:
++++++++AES256-GCM-SHA384
++++++++RSA-PSK-AES256-GCM-SHA384
++++++++PSK-AES256-GCM-SHA384
++++++POLY:
++++++++RSA-PSK-CHACHA20-POLY1305
++++++++PSK-CHACHA20-POLY1305
++++++SHA256:
++++++++AES128-GCM-SHA256
++++++++RSA-PSK-AES128-GCM-SHA256
++++++++PSK-AES128-GCM-SHA256
++++CBC:
++++++SHA384:
++++++++RSA-PSK-AES256-CBC-SHA384
++++++++PSK-AES256-CBC-SHA384
++++++SHA256:
++++++++AES256:
++++++++++AES256-SHA256
++++++++AES128:
++++++++++AES128-SHA256
++++++++++RSA-PSK-AES128-CBC-SHA256
++++++++++PSK-AES128-CBC-SHA256
SHA1:
++DH:
++++AES256:
++++++EC:
++++++++ECDHE-ECDSA-AES256-SHA
++++++++ECDHE-RSA-AES256-SHA
++++++++ECDHE-PSK-AES256-CBC-SHA
++++++NON-EC:
++++++++DHE-RSA-AES256-SHA
++++++++DHE-PSK-AES256-CBC-SHA
++++AES128:
++++++EC:
++++++++ECDHE-ECDSA-AES128-SHA
++++++++ECDHE-RSA-AES128-SHA
++++++++ECDHE-PSK-AES128-CBC-SHA
++++++NON-EC:
++++++++DHE-RSA-AES128-SHA
++++++++DHE-PSK-AES128-CBC-SHA
++NON-DH:
++++AES256:
++++++AES256-SHA
++++++RSA-PSK-AES256-CBC-SHA
++++++PSK-AES256-CBC-SHA
++++++SRP-RSA-AES-256-CBC-SHA
++++++SRP-AES-256-CBC-SHA
++++AES128:
++++++AES128-SHA
++++++SRP-RSA-AES-128-CBC-SHA
++++++SRP-AES-128-CBC-SHA
++++++RSA-PSK-AES128-CBC-SHA
++++++PSK-AES128-CBC-SHA
This doesn't really make sense. These things are not comparable (SHA and MD5 are hash functions, while 3DES and RC4 are cipher).
In general, we would recommend following the advice at
https://wiki.mozilla.org/Security/Server_Side_TLS
This was produced by comparative experts after careful study and includes rationales for many of the decisions.
It’s not meant to order them by equalities; only to order their uses based on their strengths and weaknesses.
And, I’m certainly NOT recommending that anyone use SHA1 nor 3DES nor RC4 nor MD5.
If and only when needed, they should NOT prefer them.
And here is the rational in case anyone has still missed it:
“SHA2+ then SHA1 then 3DES then RC4 then MD5 (as needed)” explained:
(I do realize this sounds like it’s comparing apples and oranges to pickles - but if you understand that a weak link in a chain makes a weak chain, then you can see that the gauge is in the lever of overall strength/weakness)
So that one line breaks down to these individual overall statements:
And as “weaker” here is understood as “easier to break” (in general), so:
SHA1 is easier to break than SHA2
3DES is easier to break than SHA1
RC4 is easier to break than 3DES
MD5 is easier to break than RC4
And thus they should be preferred (or NOT) in such an order.
I'm not at all sure that's correct in HTTPS attack settings. Remember that there are different kinds of attacks on cryptographic primitives. In the MD5 case we now have a collision attack which makes it easier for an attacker to find P₁ and P₂ such that MD5(P₁)=MD5(P₂). The attacker can have some control over the structure of P₁ and P₂, for example so that both of them can start with the same substring and only differ in a particular region. In the RC4 case, attacks were demonstrated that can decrypt portions of actual TLS sessions using RC4 ciphersuites
under relatively favorable conditions for the attacker (where the same data is being encrypted a considerable number of times at the same location in the encrypted session).
Even though the MD5 vulnerability is catastrophic for the use of MD5 to authenticate file downloads and in digital signatures (because it allows a publisher or author of a document to equivocate about what the content of the document was, showing different versions to different audiences or on different occasions), I haven't seen a paper or demonstration that shows that this MD5 vulnerability can be exploited against TLS in any way. I don't know to what extent the security arguments for TLS rely at all on the collision-resistance property of hash primitives, as opposed to preimage or second-preimage resistance.
In any case, we should not use RC4 or MD5 ciphersuites anymore. The Firefox "Intermediate" profile with compatibility back to
Oldest compatible clients: Firefox 1, Chrome 1, IE 7, Opera 5, Safari 1, Windows XP IE8, Android 2.3, Java 7
does not use them, and neither does the "Old" profile with compatibility back to
Oldest compatible clients: Windows XP IE6, Java 6
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.