-
Notifications
You must be signed in to change notification settings - Fork 825
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: src/ssl.c:ProcessBuffer() different/broken behavior for same private key depending on PEM or ASN1 format #7668
Comments
Hi, I built with the following configuration: I then made the following quick and temporary changes:
I ran I then use this change:
As expected, I got the following error message: I then used this change:
I ran I then used this change:
As expected, I got the following error message: Note, you'll need the following wolfssl-examples PR to get the keys: wolfSSL/wolfssl-examples#443 Warm regards, Anthony |
lighttpd base64-decodes the key from a .pem file into a buffer which contains the DER. Passing this value to lighttpd does not use stdio because lighttpd takes steps to wipe the memory containing sensitive keys, something that you can not do portably with internal stdio buffers unless you employ |
We have recently be moving to newer versions of the algorithm. You might need to use mldsa when generating the certificates. |
Hi @gstrauss , Have you tried with the MLDSA keys? |
@anhu Have you tested with v5.7.0-stable, as specified in my original post at the top of this page and in https://wolfssl.zendesk.com/hc/requests/18173 and in your slides? v5.7.2-stable is tagged yesterday (8 July 2024). Please test with that tag, too. |
I have tested against v5.7.2-stable and I get the same results as noted above. |
I have tested the instructions on my slides. |
And??? Did you test with the original instructions where you needed to patch lighttpd mod_wolfssl due to this bug in wolfssl? Were your slides modified? If so, how? Were your slides updated to use MLDSA keys? Were you slides updated to remove any additional patches to lighttpd? What version of lighttpd are you using? Can you confirm that you do not need any patches to lighttpd mod_wolfssl? |
Instructions on the slide remain the same. No need for changes to the slides. |
I object.
@dgarske would you please explain to @anhu that a) he did not answer my questions, and b) "If there is no objection, I will now close this ticket." and then immediately closing the ticket is rude since there were open questions (which he curtly replied vaguely, without actually answering the questions.) If you think that @anhu answered my questions clearly in this ticket, please kindly point out to me where "Can you confirm that you do not need any patches to lighttpd mod_wolfssl?" was answered. Thank you. |
Hi @gstrauss , Thanks for your report and detail. I've read through the ticket and the issue. I couldn't find an answer to your question if patches were needed for lighttpd. I have downloaded the latest slides and will attempt to reproduce and answer the question. Thanks, |
Thanks, @dgarske Is a current version of the slides available? @anhu's communications were vague and I do not know the current state of them. I filed this PR after following a (previous?) version of the slides sent to me as an attachment in https://wolfssl.zendesk.com/hc/requests/18173. Using the version of wolfssl specified in those slides, I duplicated the issue for which @anhu patched lighttpd (instead of fixing the issue in wolfssl) and traced it to the wolfssl code. The issue might already have been fixed in the recently-released wolfssl v5.7.2-stable as I see that the code in question was moved to a different file and since modified. |
Hi @gstrauss , Attached is the latest PDF of the slides I could find: pq_curl_07_2024.pdf. These can be public. I didn't see any fixes in wolfSSL yet to address this, but I could have missed this. I suspect the lighttpd patch is still required. I plan to fix properly in wolfSSL when I get some time later this week. Thanks, |
Thanks. I had given @anhu feedback about the slides and will post what I remember here:
|
Thank you @gstrauss . That is all excellent feedback. I'll make sure it is taken in. |
Some details about my testing in lighttpd before filing this issue for WolfSSL: lighttpd reads in a .der or .pem file and converts PEM to DER in an in-memory buffer which is submitted to I tested lighttpd code which reads PEM and base64-decodes into DER. Then I took the DER and base64-encoded it, manually added PEM header and footer, and passed that to wolfSSL and it worked. Therefore, the lighttpd code reading and base64-decoding the PEM file is working. (Similarly, substituting lighttpd mod_openssl for lighttpd mod_wolfssl works with the same certficates without any changes to lighttpd.) I traced the apparent difference in behavior to the code underlying |
@ColtonWilley have you had a chance to review https://wolfssl.zendesk.com/hc/requests/18173 and the notes here? |
@gstrauss Yes I have reviewed everything related to this issue. I had actually begun working on this last week but unfortunately fell ill. I was not able to reproduce this issue myself, but looking at the PEM/DER handling in wolfssl and lighttpd I see some potential issues there. I will be looking at recreating the underlying failure of |
@gstrauss I followed the process described as: I did this on 5.7.2-stable and was not able to reproduce. I also tried to reproduce the segmentation fault described here: I tried this on 5.7.2-stable and got a graceful error as expected. Can you please verify that these issues still persist for you when using 5.7.2-stable? If you are still getting an error is it possible for you to provide the failing input DER buffer and length? Thanks, |
(I hope you're feeling better.) The origin of me filing this issue was @anhu modifying lighttpd in his slide demo for dilithium keys. As noted in this bug report, I had used v5.7.0, as did @anhu. I noted that there were changes in the code between then and v5.7.2. Since you already have a working test environment, I would appreciate if you could test v5.7.0. I would have to rebuild a test environment from scratch to do so. If wolfssl v5.7.2 no longer requires patching lighttpd to use dilithium keys, then this issue can be closed. If patching lighttpd is still required, I would like to know why, so that it can be fixed. |
@gstrauss I was able to recreate the underlying failure of wolfSSL_CTX_use_PrivateKey_buffer() with v5.7.0 and the patch from the slides, a valid dilithium DER is rejected. The same calling code works for unmodified v5.7.2-stable, which lines up with the code changes. The slides have been reworked here https://docs.google.com/presentation/d/1OtVDn0JqQUmiyz2U60YS4_eKDx0KmIczcv8W4G4DbA4/edit?usp=sharing to not use liboqs anymore, use pre-generated certs, and using 5.7.2-stable. It seems 5.7.0 with the patch simply wont work as is for dilithium DER, so 5.7.2 will be required. "If wolfssl v5.7.2 no longer requires patching lighttpd to use dilithium keys, then this issue can be closed." Please let me know if you are still encountering any issues, or if this issue has been resolved for you. |
Yes, this issue is resolved and can be closed since lighttpd works unmodified with wolfssl v5.7.2. Regarding the slides:
|
Thank you for your thorough reviews of the slide materials, wolfSSL appreciates the time you spend on these issues. Special thanks for recommendation on slide 16, I definitely dont know lighttpd well enough to catch that. I will keep this issue open until I have updated the slides appropriately. |
Contact Details
No response
Version
v5.7.0-stable
Description
src/ssl.c:ProcessBuffer() fails if dilithium_level5_entity_key.pem is parsed by application into DER and passed to
wolfSSL_CTX_use_PrivateKey_buffer()
with formatWOLFSSL_FILETYPE_ASN1
, but works if the PEM buffer is passed towolfSSL_CTX_use_PrivateKey_buffer()
with formatWOLFSSL_FILETYPE_PEM
Separate bug: wolfSSL crashes with SIGSEGV if the above private key (incorrectly) is passed as PEM buffer to
wolfSSL_CTX_use_PrivateKey_buffer()
with formatWOLFSSL_FILETYPE_ASN1
. Note the mismatched format. Still, wolfSSL should not crash, as the buffer and buffer length are parameters.Reproduction steps
Ask @anhu for instructions for Post-Quantum Algorithms in cURL using lighttpd and wolfssl (and please give him feedback if the demo could be simpler)
Alternatively, generate
dilithium_level5_entity_key.pem
usingoqs/generate_dilithium_chains.sh
from wolfSSL osp repo. https://github.com/wolfSSL/ospRead the file into memory and pass to
wolfSSL_CTX_use_PrivateKey_buffer()
. Then, parse the PEM into DER and callwolfSSL_CTX_use_PrivateKey_buffer()
.Relevant log output
More details in https://wolfssl.zendesk.com/hc/requests/18173
The text was updated successfully, but these errors were encountered: