Switch to a fixed set of DH parameters compatible with older OpenSSL. #2026
Conversation
|
Is this really necessary if we link to OpenSSL 1.1 on CentOS 7? If the RPMs I created today work fine, I can make linking to OpenSSL 1.1 the default in the next releases. |
|
Could you please fetch at least one recent tag (i.e. v5.5.5) into your fork of xrootd? Or you could delete the |
|
OK, I think we need a test using the RPM you built first, right? |
There was a problem hiding this comment.
OK, I added my 2 cents. I see the problem and am asking a) can we come up with a better solution than downgrading everything, and b) if we can't the original code needs to be kept in comment form so that anyone looking at it can see what was done without resorting to git history to make it painfully apparent.
No -- but replacing all clients is not an option. For example, we cannot ask experiments to stop using the Run 2 / 3 releases and replace them.
You can read through the OpenSSL ticket for why they made the change. The existing DH code we use leaks a single bit of the session key. Mind you, the existing DH code we use also leaks all bits of the session key because 512 bit DH was broken in the 1990's.
Why? Fixed DH parameters are done everywhere, on almost every webserver on the planet and IPSec. I don't understand the emphasis on dynamically generating the DH parameters when there's no strong cryptographic motivation or risk reduction. |
To be clear -- this moves everything from 512-bit DH (broken) to 2048-bit DH (OK for now). Because of the DH parameter selection, the session key has 127 bits of security currently and remains at 127 bits. If we drop support for RHEL7 (e.g., LHC Run2), we get the session key back to 128 bits of security. The difference between 127 and 128 for the session key is pretty minimal (it's something like the difference between being broken in 250 billion years and 500 billion years). The difference between 512-bit DH and 2048-bit DH is a huge step forward: it's the difference between "broken in the 90's" and "considered secure for now". |
|
OK, thanks for he explanation. While agree about the part that using dynamic DH parameters might not provide you better security I am always amazed that some one at some point will actually point out that fixed parameters allow a security breach even as unlikely it appeared at the time the decision to use fixed parameters was made.So, could you just comment out the deleted code and make it obvious what was changed. I know this is being pedantic and somewhat paranoid but you know how security works. After that I have no problems with the patch subject to testing. |
|
Ok - fixed up the branch so the commit came with much more in-line context about why this is being done. |
|
I've tested this on an Alma9 machine, it works. I can connect with an existing client from CentOS 7 linked to OpenSSL 1.0. Linking the client with OpenSSL 1.1 also lets it connect to the Alma9 server, so I am considering updating the spec file to do that from next release onwards. @abh, I leave it to you to decide on merging this. |
OpenSSL 3 started generating DH parameters that are not considered valid by `DH_check` for older OpenSSL 1.0.2. Since we can't change clients in the wild, I generated a set of DH params (`openssl dhparam 2048`) on an older OpenSSL 1.0.2 which appears to be considered acceptable by both versions of OpenSSL. This fixes the set of DH parameters (instead of generating them each time), which is fairly typical, and also increases the size from 512 (insecure) to 2048.
|
Looks good now, thanks! |
(This may be more of a conversation for the ticket, not the PR but...) If we're going to have to support OpenSSL 1.0.2, I think it's better to ship against 1.0.2. I'd worry about downstream folks who link against OpenSSL 1.0.2 on RHEL7: what's the implication of having both OpenSSL 1.0.2 and 1.1.1 inside the same process? Therefore, I would propose we drop support for OpenSSL 1.0.2 for XRootD 6 and change to OpenSSL 1.1.1 then (even on RHEL7). Seems quite strange to have a major change in OpenSSL versions in a minor or patch release. At a major release boundary, I don't mind making the downstream plugins review their linking. |
|
I wanted to note the latest rebase to fix up the nice inputs from @amadio also changed the DH parameters to increase to a 3072-bit size. This is because, in further reading, 2048 bit DH only provides 112 bits of security for the session key yet the default session key is 128 bits. Despite anything over 100 bits being seen as secure, 112 is not perceived to be as bulletproof as it used to. Accordingly, I decided to increase the DH security to 128-bits by using the 3,072 bit parameters. This way, despite the lack of a KDF, that part of the handshake isn't introducing weaknesses.. |
|
@abh3 - got a few requests this afternoon to rush a build out to test sites. Would prefer to only do that with the final patch. Any thoughts here? |
|
OK, I'll merge this with the notion that @amadio dio can rerun the test with this current fix. He ran a test prior to your change and it worked. Says nothing about it now. |
|
OSG now has a build of XRootD 5.5.5 with this patch in the osg-testing repos if people are interested in testing. (https://opensciencegrid.atlassian.net/browse/SOFTWARE-5594) |
|
Thank you, we did test it before merging. The new settings work to allow old clients connect to Alma9 servers. Please do let us know, however, if you have any problems with this patch on top of v5.5.5. |
|
[PLEASE IGNORE this comment, see next comment for explanation] At UCSD we are deploying some XRootD servers with Alma8 and XRootd-5.5.5 and noticed that when updating from 5.5.5-1.1 to 5.5.5-1.2 TLS stopped working for the client I use for testing. This PR seems to be the culprit. My client is running 5.4.3-1.1.osg36.el7.x86_64 and Auth with both GSI and Scitokens (ztn) seem broken, I keep being asked for my pem key: "Enter PEM pass phrase:" The same client works just fine with a server running 5.5.5-1.1 |
|
My previous comment refers to an old weird behavior that gets triggered by setting: For some reason and only in very specific combinations of client/server versions, when I try to access an XRootD server via the 'xroot' protocol and the above env vars are set, even if I have a valid proxy in the default location and/or pointed by X509_USER_PROXY the client will try to use my cert and key files instead which triggers a password request. Unsetting the above env vars fixes the issue. |
OpenSSL 3 started generating DH parameters that are not considered valid by
DH_checkfor older OpenSSL 1.0.2.Since we can't change clients in the wild, I generated a set of DH params (
openssl dhparam 2048) on an older OpenSSL 1.0.2 which appears to be considered acceptable by both versions of OpenSSL.This fixes the set of DH parameters (instead of generating them each time), which is fairly typical, and also increases the size from 512 (insecure) to 2048.
Fixes #2014