mirror of
https://github.com/certbot/certbot.git
synced 2026-02-20 00:10:12 -05:00
Certificats Let's Encrypt
this pr is in response to https://words.filippo.io/compromise-survey/. ohemorange and i read this late on a friday to (speaking for myself at least) much panic as it has some very strong words to say about the github actions trigger pull_request_target which we use. looking into the issue more, i also found that the popular static analysis tool [zizmor](https://github.com/zizmorcore/zizmor) flags any github actions workflow that uses the pull_request_target trigger with the message: ``` error[dangerous-triggers]: use of fundamentally insecure workflow trigger pull_request_target is almost always used insecurely ``` this only added to my concern the general problem with pull_request_target is that it runs with additional privileges (e.g. potential write access, access to secrets) in an environment containing values that can be set by an attacker. these values include things such as references to the arbitrary code contained in the triggering pr and pr titles which have been used to perform shell injection attacks. not carefully treating these values like the untrusted data it is while executing code in the privileged environment given to pull_request_target has resulted in many supply chain attacks that's not to say that pull_request_target CAN'T be used securely. zizmor even has [an issue](https://github.com/zizmorcore/zizmor/issues/1168) brainstorming how to not warn about all uses of the trigger as some are clearly fine and the only way to accomplish what the user wants. i'm going to argue that our uses of the trigger are ok looking through the links provided by filippo's blog and [zizmor's docs](https://docs.zizmor.sh/audits/#dangerous-triggers), i think we can break down attacks used against pull_request_target into roughly 2 categories: 1. shell injection: "Nx S1ingularity" and "Ultralytics" from filippo's blog 2. checking out and running a PR's code: "Kong Ingress Controller" and "Rspack" from filippo's blog and https://ptrpa.ws/nixpkgs-actions-abuse from zizmor docs i think none of our pull_request_target workflows have these problems. none of them use a shell (the [zizmor issue](https://github.com/zizmorcore/zizmor/issues/1168) i linked earlier suggests that any pull_request_target workflow that uses a run block should always be flagged as insecure). instead, our workflows just call action-mattermost-notify which can be [pretty easily audited](https://github.com/mattermost/action-mattermost-notify/blob/2.0.0/src/main.js) (as all the other files in the repo are boilerplate). passing possible attacker controlled values directly to an action written in another language is one of the approaches for mitigating script injection [recommended by github](https://docs.github.com/en/actions/reference/security/secure-use#use-an-action-instead-of-an-inline-script). our workflows also do not check out the triggering pr's code despite all that, i took this opportunity to cleanup and harden things a bit. i reduced the permissions for each workflow and confirmed they each still work on my fork. i also pinned the mattermost action to an exact version and added some inline documentation with these changes, our github workflows trigger few to no warnings/errors when checked with zizmor, [octoscan](https://github.com/synacktiv/octoscan), and [openssf scorecard](https://github.com/ossf/scorecard) if this pr is approved, i'll make similar changes to our josepy repo |
||
|---|---|---|
| .azure-pipelines | ||
| .github | ||
| acme | ||
| certbot | ||
| certbot-apache | ||
| certbot-ci | ||
| certbot-compatibility-test | ||
| certbot-dns-cloudflare | ||
| certbot-dns-digitalocean | ||
| certbot-dns-dnsimple | ||
| certbot-dns-dnsmadeeasy | ||
| certbot-dns-gehirn | ||
| certbot-dns-google | ||
| certbot-dns-linode | ||
| certbot-dns-luadns | ||
| certbot-dns-nsone | ||
| certbot-dns-ovh | ||
| certbot-dns-rfc2136 | ||
| certbot-dns-route53 | ||
| certbot-dns-sakuracloud | ||
| certbot-nginx | ||
| letsencrypt-auto-source | ||
| letstest | ||
| newsfragments | ||
| snap | ||
| tests | ||
| tools | ||
| .coveragerc | ||
| .dockerignore | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .isort.cfg | ||
| .pylintrc | ||
| AUTHORS.md | ||
| CHANGELOG.md | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| LICENSE.txt | ||
| linter_plugin.py | ||
| mypy.ini | ||
| pytest.ini | ||
| README.rst | ||
| ruff.toml | ||
| SECURITY.md | ||
| towncrier.toml | ||
| tox.ini | ||
.. This file contains a series of comments that are used to include sections of this README in other files. Do not modify these comments unless you know what you are doing. tag:intro-begin |build-status| .. |build-status| image:: https://img.shields.io/azure-devops/build/certbot/ba534f81-a483-4b9b-9b4e-a60bec8fee72/5/main :target: https://dev.azure.com/certbot/certbot/_build?definitionId=5 :alt: Azure Pipelines CI status .. image:: https://raw.githubusercontent.com/EFForg/design/master/logos/certbot/eff-certbot-lockup.png :width: 200 :alt: EFF Certbot Logo Certbot is part of EFF’s effort to encrypt the entire Internet. Secure communication over the Web relies on HTTPS, which requires the use of a digital certificate that lets browsers verify the identity of web servers (e.g., is that really google.com?). Web servers obtain their certificates from trusted third parties called certificate authorities (CAs). Certbot is an easy-to-use client that fetches a certificate from Let’s Encrypt—an open certificate authority launched by the EFF, Mozilla, and others—and deploys it to a web server. Anyone who has gone through the trouble of setting up a secure website knows what a hassle getting and maintaining a certificate is. Certbot and Let’s Encrypt can automate away the pain and let you turn on and manage HTTPS with simple commands. Using Certbot and Let's Encrypt is free. .. _installation: Getting Started --------------- The best way to get started is to use our `interactive guide <https://certbot.eff.org>`_. It generates instructions based on your configuration settings. In most cases, you’ll need `root or administrator access <https://certbot.eff.org/faq/#does-certbot-require-root-administrator-privileges>`_ to your web server to run Certbot. Certbot is meant to be run directly on your web server on the command line, not on your personal computer. If you’re using a hosted service and don’t have direct access to your web server, you might not be able to use Certbot. Check with your hosting provider for documentation about uploading certificates or using certificates issued by Let’s Encrypt. Contributing ------------ If you'd like to contribute to this project please read `Developer Guide <https://certbot.eff.org/docs/contributing.html>`_. This project is governed by `EFF's Public Projects Code of Conduct <https://www.eff.org/pages/eppcode>`_. Links ===== .. Do not modify this comment unless you know what you're doing. tag:links-begin Documentation: https://certbot.eff.org/docs Software project: https://github.com/certbot/certbot Changelog: https://github.com/certbot/certbot/blob/main/certbot/CHANGELOG.md For Contributors: https://certbot.eff.org/docs/contributing.html For Users: https://certbot.eff.org/docs/using.html Main Website: https://certbot.eff.org Let's Encrypt Website: https://letsencrypt.org Community: https://community.letsencrypt.org ACME spec: `RFC 8555 <https://tools.ietf.org/html/rfc8555>`_ ACME working area in github (archived): https://github.com/ietf-wg-acme/acme .. Do not modify this comment unless you know what you're doing. tag:links-end .. Do not modify this comment unless you know what you're doing. tag:intro-end .. Do not modify this comment unless you know what you're doing. tag:features-begin Current Features ===================== * Supports multiple web servers: - Apache 2.4+ - nginx/0.8.48+ - webroot (adds files to webroot directories in order to prove control of domains and obtain certificates) - standalone (runs its own simple webserver to prove you control a domain) - other server software via `third party plugins <https://certbot.eff.org/docs/using.html#third-party-plugins>`_ * The private key is generated locally on your system. * Can talk to the Let's Encrypt CA or optionally to other ACME compliant services. * Can get domain-validated (DV) certificates. * Can revoke certificates. * Supports ECDSA (default) and RSA certificate private keys. * Can optionally install a http -> https redirect, so your site effectively runs https only. * Fully automated. * Configuration changes are logged and can be reverted. .. Do not modify this comment unless you know what you're doing. tag:features-end