-
Notifications
You must be signed in to change notification settings - Fork 701
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
webgui: ocsp staple support #5567
base: master
Are you sure you want to change the base?
Conversation
update script is based on lighty cert-staple.sh
Is there a better alternative to copying the lighttpd Before enabling OCSP Must-Staple, there should be a scheduled job to periodically (once a day) run
|
3d3319d
to
0b040dc
Compare
@gstrauss
Is that possible?
Is it better with the latest commit? ;) |
Thanks @kulikov-a
Looks better! However, I have only visually reviewed the PR. I defer to @fichtner to review if this PR fits opnsense patterns.
Should be. That was my intention when I wrote |
b2181ed
to
a1f9381
Compare
@gstrauss Hi )
Obviously, the point here is my lack of knowledge: I don’t fully understand what you mean. some make options to include and if you allow a couple of questions on the |
lighttpd development occurs on git.lighttpd.net, not here. You're welcome to submit a PR to https://github.com/lighttpd/lighttpd1.4/
I prefer using source control to compare changes. I am not going to pull your cut-n-paste, and then modified cert-staple.sh from this PR. Separately, in lighttpd development -- and not in this PR -- I will take a look at |
@kulikov-a I appreciate the effort that you have put into this PR. That said, since we are dealing with certificates and security, my code review comments will be strict.
You appear to have deleted the code from the script which calculates ocsp_expire. A future version of lighttpd will address the different FreeBSD
|
This comment was marked as abuse.
This comment was marked as abuse.
@gstrauss Thanks!
I would really like to know how to do this. and to know @fichtner opinion on this: what if it becomes necessary to make changes specific to the opnsense (verbose output or some..)? it may be more correct in this case (the impossibility of using the source file) to change the name of the script to eliminate confusion (and indicate the origin of the file in the comments)? the rest of the comments are also correct: the request was made for discussion (and in no case did I want to offend by using the file without your consent, if that's the case)
yes and wanted to discuss it in pr: as far as I noticed, this variable is then used only for naming the file (besides i'm not sure if nextUpdate can be required - I thought that the absence of this field is allowed). therefore, I thought that I could save the code and not adapt the calculation for different OSes, but simply switch to the current time. or am I missing something? @ThePowerofDreamS |
The code review criticism is not about offense. It is about ongoing ownership and maintenance.
Package maintenance is an important concept. If lighttpd maintains and distributes cert-staple.sh (I do), then if opnsense needed a modification for the opnsense lighttpd package, then opnsense would have a small patch together with the opnsense lighttpd package. This would use the maintained upstream lighttpd cert-staple.sh while reducing the maintenance burden for the opnsense lighttpd package maintainer (not me) to making sure the small patch made sense. Where feasible, proposing patches upstream is a good way to improve open source for everyone and to reduce the maintenance burden of extra patches for specific distributions such as opnsense. Please do not continue repeating your suggestion to fork the script. Look for better options. |
You missed carefully documenting your intent in the code, as well as your changes and why. In upstream lighttpd, I have a not-yet-released enhancement to cert-staple.sh which short-circuits and does not attempt to retrieve a new staple.der if the current staple.der is still valid for at least 25 hours, quickly checking the generated filename rather than re-parsing the der. This will speed up daily cron jobs and put less burden on upstream CAs which issue staples for 1 week. tl;dr: if you do not intend to take over development and ongoing maintenance, you probably should not be copying or modifying that code. |
I'd say for a draft this is a good discussion, but eventually the only sane way is to move cert-staple.sh out of the docs directory in order to be visible to packaging systems. I'm sure maintainers will notice the change and pick it up. I'd also suggest a copyright header for such scripts. It adds an aura of professionalism around it so it's easier to discuss on the required terms given here. Cheers, |
@gstrauss i think i got your point and iiuc you are not interested in arguments why lighty-side script maintanance can be inconvenient for opnsense-specific use.
would you be ok if i create a script from scratch and stop using the lighty script as an example\template? |
Not my call for opnsense. I am sharing my (hopefully qualified) opinions as a lighttpd developer.
I think you may have missed my point: there should be no opnsense-specific use if it can be avoided. If there is something incompatible with opnsense and you report the issue upstream, then the issue will likely be addressed upstream. I happened to be part of the thread here where you noted that cert-staple.sh from upstream lighttpd uses
Same as above, I think you missed the point about ownership and maintenance by domain experts. kulikov-a I would recommend learning more about package maintenance and looking into submitting a PR to add one or both of the above patches to the cert-staple.sh script in lighttpd in the opnsense lighttpd package, and modifying the opnsense lighttpd package to include cert-staple.sh. @fichtner wrote:
Adding a copyright makes sense. I'll add that upstream. Regarding moving the script out of docs/scripts/, I disagree that "maintainers will notice" as a general statement. While you do a great job with opnsense, that is not the case with many other distros. It is frequently difficult to get a volunteer to find the time to merely update the source code binary hash and rebuild the package for the distro. Currently, the lighttpd source code doc/ directory contains man pages, example scripts, systemd config, and others that package maintainers can optionally choose to install in a variety of locations. For example, some distros take doc/scripts/create-mime.conf.pl from the lighttpd source and package it to be installed into a location where it can be called from lighttpd.conf to generate mime assignments from /etc/mime.types. The same was intended for cert-staple.sh. Since the lighttpd binary and shared objects are extracted and packaged from the build, why does the location of cert-staple.sh under doc/scripts/ in the source tree matter? (Please help me to understand the restriction.) cert-staple.sh can be extracted from that location and installed where desired. (I have not looked specifically at opnsense package management, so I might be misunderstanding some limitations.) Why must the script not be under doc/scripts/ to be visible to the opnsense packaging system? Are there other locations it should not be under, such as contrib/...? |
@gstrauss Thanks!
fair enough. long wanted.. |
@kulikov-a I would consider discussing feature requests. And I will always seriously consider requested changes to 'usage' and 'help'. However, and please try not to take this the wrong way: thus far, I have had to repeat myself to educate you on basic best practices on security software ownership and maintenance by domain experts. Absent evidence, I do not take very seriously any of your thoughts or expectations of what others need or want. One example of your blind spots:
The can already be controlled with |
test ver. for opnsense/core#5567
@gstrauss changed the code, lighty example/template script is no longer used |
cd2a9cf
to
417438f
Compare
The code contains the comment Scripts refreshing OCSP stapling responses are generally recommended to be run once per day. e.g. once per day is more than sufficient for Let's Encrypt; OCSP stapling responses from Let's Encrypt are good for one week. |
78845fc
to
8ba454a
Compare
For example both Apache and Nginx cache the response for 1 hour per default. While 5 minutes is overkill for "too short" reasons, kinda so is 1 day for the opposite end of what OSCP tries to achieve (and the stapling then improves performance wise). Most OSCP responders do update their databases for any particular domain once a day, while expiration is often 1 week... The catch and thus whole point in OCSP is that if certificate is revoked, then the whole point is to deliver the status as fast as possible to clients. On revocations OCSP responder gets updated quite promptly, and this is the reason web-server side stapling shouldn't be cached too long and why most web-servers default is 1h. Some more better explanation in old but still as relevant gist: https://gist.github.com/mholt/3b4910c802b2ed7e92294e26a1ae8551 Now I don't say which value should be used in this context, nonetheless some food for the thought :) |
@olmari you seem to be missing the forest for the trees. If the certificate was revoked, then do you have a process to detect that and to replace the certificate? If you replace the certificate, wouldn't it make sense to replace the OCSP response at the same time, referring to the new certificate? (FYI: when you replace a certificate, currently you need to restart lighttpd, which can be a graceful restart. This is an area where lighttpd could be improved, but certificate revocation is not a situation which occurs frequently in common web server use cases.) Internet Security Research Group (ISRG) In Dec 2015, jsha, Let's Encrypt engineer, posted
https://gist.github.com/sleevi/5efe9ef98961ecfb4da8 has lots of good info, and concludes:
That is what lighttpd does. For typical use with one week OCSP lifetimes, updating OCSP responses once a day is fine and the recommended interval when there is an on-disk cache of OCSP responses, as is the case in lighttpd. (See more details in the gist above.) You should run the script to update your OCSP responses as your risk profile and company security policy dictates. Every five minutes for updates is obnoxiously wrong and unnecessarily loads OCSP responders. As I said above, if you detect that a certificate has been revoked -- which you need to do outside lighttpd in whatever ways are appropriate for your organization -- then you need to replace the certificate as well as the OCSP response. |
@gstrauss You're not wrong in the basics of "certificate replacement procedures", but OCSP is not even catering to that part... Replacing cert is not the same thing as revoking the old-to-be cert... Its main function is to revoke cert when for some reason adversary part got the server under control... Stapling is then performance optimization for the 99.9999% good times there is and it doesn't do any good to cache the response too long. EDIT/ADD: Like I also said, 5 minutes is very excessive, some servers do it hourly, some daily, or such... |
I'm sorry. Would you please explain the point you are trying to make? (... you edited your response multiple times as I wrote this) I still do not see where you are disagreeing with what I stated (and for which I have provided links). You seem to be making a simple point that Apache and Nginx use an hour. Ok? So what? You agree with my point that 5 mins is very excessive. That was my point and my assessment of the person who modified the script and who clearly lacks security qualifications. I do not feel that you have added much to this conversation. Go ahead and update your OCSP as often as you see fit. If you do it excessively, public OCSP may rate limit or block you on a (very) large number of OCSP requests. As I said multiple times, updating OCSP daily via a script is fine. If your web server does it for you on a slightly different time frame, that is fine, too. |
Hi!
ref. https://forum.opnsense.org/index.php?topic=26812.msg130038#msg130038 )
had some time and decided to try:
update script is based on lighty cert-staple.sh examplemarked as draft for discussion:
although the idea of using the OCSP stapling is absolutely technically correct and it has been tested with a LE certificate and seems to work:
it seems to me that there will be quite a lot of questions due to possible misuse (use of "must staple" certs) ..
Thanks!