Do you have any actual arguments for that or is it just a general statement/feeling, which might not even be true in this case? Do you even know what DHE groups do?
2 Likes
I changed the /etc/letsencrypt/ffdhe2048.txt to /etc/letsencrypt/ffdhe4096.txt and the SSLOpenSSLConfCmd DHParameters /etc/letsencrypt/ffdhe2048.txt to SSLOpenSSLConfCmd DHParameters /etc/letsencrypt/ffdhe4096.txt and restarted apache. Apache restarted and works but I don't pass the test somehow.
1 Like
Did you actually download the ffdhe4096.txt or did you just rename ffdhe2048.txt to ffdhe4096.txt?
We need A LOT more to work with. Error messages, log entries et cetera.
4 Likes
I just renamed the file. Do you know where I can download it? Sounds great with fixing error messages to me.
Thanks again!!!
I'm sorry, but I'm giving up. Hopefully someone else can help you further.
4 Likes
Sorry bout that, didn't intent to be annoying.
I found this: https://github.com/mozilla/ssl-config-generator/blob/master/docs/ffdhe4096.txt
Thanks
1 Like
Can anyone remember where the: sha256 checksum:
is located?
Thanks
1 Like
It's actually the other way around for this one. We (meaning cryptographers) used to recommend generating finite field groups per-server. The basic idea was to help prevent precomputation attacks. This is also why you still find many articles about generating random FFDHE groups. However, since then research has shifted and numerous problems have been found with randomly generated groups, such as small subgroup attacks. Basically, there's no guarantee that a random group is actually a "good" group. So, instead of generating them randomly, today's recommendation is to only use known "good" FFDHE groups.
Well, actually the recommendation is to not use FFDHE at all - ECDHE is much better. But if you have to, use only named groups.
10 Likes
How to change from FFDHE to ECDHE? 
1 Like
I guess I need to update my "textbooks"...
Wait! So, the earth isn't flat?
LOL
8 Likes
You already support it - all cipher suites starting with ECDHE use ECDHE. To disable FFDHE, just remove the cipher suite(s) starting with DHE.
9 Likes
I forgot the location of the ciphersuits on apache, can anyone remember?
Thanks 
1 Like
Ordinarily, asking for spoon-fed answers isn't the best way to learn something. If you're really trying to learn, as you say, it seems like consulting the Apache docs would be a good place to start. Perhaps you could check back here if they're unclear to you, though this isn't really an Apache support forum.
7 Likes
You have been negative and against all the way, you don't bring any good to this post. Why even bother? Why don't you just engage where stuff you're interested in is and stay away from stuff you don't like or understand is?
Well, it might be a negative answer, but Dan has a point. We're currently 54 posts into this thread and it barely has any relationship with Let's Encrypt to begin with. Now, we're not the worst people and often help with generic TLS configuration questions, but to be honest, the tendency in this thread is zero interest in the least amount of self-education. I don't want to be rude in any way, but you seem to lack the most basic skill on managing an Apache server. As already said, this is not the Apache support Community and if someone lacks the smallest amount of interest for any form of self-education (e.g.: enter a command in Google to find out what it is), well, then it's very hard to help someone, if I'm honest.
For example, you've entered the text SSLOpenSSLConfCmd a few times now on the command line with an error as a result. The second result for SSLOpenSSLConfCmd on Google links to mod_ssl - Apache HTTP Server Version 2.5, which is the Apache documentation site. There you would have found the SSLOpenSSLConfCmd directive. And with that you should also have figured out it's not a command for on the command line, but a directive in an Apache configuration file.
The utmost basic distinction between a command on the command line and a directive for the webserver configuration files is to such an extent that personally I cannot help you. That's probably mostely on me, for lacking enough patience. Although again, this is also not a "How does Linux work" or "How do I configure Apache" community.
Again, I don't want to be rude, but I do want to be honest and perhaps explain a little bit why Dan might post a post which might come across as rude.
4 Likes
Do you mean, that using the command openssl dhparam 4096 there is a chance that I will generate a group that is not good? If yes, why the necessary extra quality verification are not built into the generating code?
5 Likes
I have to second (or third) this line of thinking.
We are here to help with LE problems not any/every type of linux/web server problem.
Your questions are consistently moving further and further from what we do here.
And, to be honest, show that you are not the right person to be making these types of changes - you lack the motivation to learn and are simply asking for a solution/answer to be provided to you.
Then you are now twisting it to seem like "if you don't know the answer, then you shouldn't respond".
But you fail to see the big picture - even if we know the answer, this is NOT the place for such answers.
The sign at most national parks read: DON'T FEED THE ANIMALS
[for very good reasons]
I, for one three, will not continue to feed answers to things that are either obvious or simply unrelated to this forum.
Take it for what it's worth - I know this will likely be read very negatively (it wasn't meant to be), but the truth is the truth and I'm not into sugar-coating it.
6 Likes
Depends on your definition of good. Given the large size alone, it is pretty unlikely that you will actually generate a group that will enable practical attacks. But, as with many cryptographic systems, the goal is always to provide the best possible security, and so the question should rather be: "What is my gain by generating a group myself?".
A truly randomly generated DH group would indeed be horrible, as it is almost guaranteed to suffer from small subgroup confinement attacks. But, I've just checked, openssl dhparam isn't actually that stupid: It does have safe prime and generator checks, even though they get pretty expensive on large groups. This isn't obvious: Real life studies show that some DH parameters used by various implementations aren't even prime, let alone safe prime groups.
The issue is rather, that their is no real gain in allowing everyone to choose their own groups. It just opens the door for dozens of security vulnerabilites attacking the group parameters. It is much better to have the parameters hard-coded into the clients and not negotiate them over-the-wire. In fact, that's what we're doing with EC curves from the start, and it's in line with modern have one joint, and keep it well-oiled design principles. Generating these groups does not give you a benefit: Precomputation attacks are considered minor today, but a random group might suffer from a non-obvious weakness. The FFDHE groups were all audited in lengthy processes, trying to look for unusual things. None were found, so they were cleared. Now, that is no guarantee that these groups are free from weaknesses, but it's somewhat better than a random group that no one ever looked at.
10 Likes
I am sorry. I have enjoyed and learned a lot in here. I understand his point. I love to use lets encrypt as a free and awesome encryption on my sites. Thanks man!
2 Likes
...but I did learn.
1 Like