-
Notifications
You must be signed in to change notification settings - Fork 124
Add optional mTLS support to the tang pin #566
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
Open
liyue32
wants to merge
1
commit into
latchset:master
Choose a base branch
from
liyue32:tang-mtls-support
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,81 @@ | ||
| #!/bin/bash -xe | ||
| # vim: set tabstop=8 shiftwidth=4 softtabstop=4 expandtab smarttab colorcolumn=80: | ||
| # | ||
| # Copyright (c) Meta Platforms, Inc. and affiliates. | ||
| # | ||
| # This program is free software: you can redistribute it and/or modify | ||
| # it under the terms of the GNU General Public License as published by | ||
| # the Free Software Foundation, either version 3 of the License, or | ||
| # (at your option) any later version. | ||
| # | ||
| # This program is distributed in the hope that it will be useful, | ||
| # but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
| # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
| # GNU General Public License for more details. | ||
| # | ||
| # You should have received a copy of the GNU General Public License | ||
| # along with this program. If not, see <http://www.gnu.org/licenses/>. | ||
| # | ||
|
|
||
| . tang-common-test-functions | ||
|
|
||
| on_exit() { | ||
| exit_status=$? | ||
| [ -n "${TMP}" ] && tang_stop "${TMP}" | ||
| [ -d "${TMP}" ] && rm -rf "$TMP" | ||
| exit "${exit_status}" | ||
| } | ||
|
liyue32 marked this conversation as resolved.
|
||
|
|
||
| trap 'on_exit' EXIT | ||
|
|
||
| # Bail out early (as a skip) if the environment cannot do mTLS. | ||
| tang_mtls_sanity_check | ||
|
|
||
| TMP="$(mktemp -d)" | ||
|
|
||
| # Generate CA, server and client certificates. | ||
| tang_generate_certs "${TMP}" | ||
|
|
||
| # Start a TLS tang server that *requires* a client certificate (mutual TLS). | ||
| tang_run_mtls "${TMP}" sig exc | ||
| port=$(tang_get_port "${TMP}") | ||
|
|
||
| url="https://localhost:${port}" | ||
| cacert="${TMP}/ca.crt" | ||
| cert="${TMP}/client.crt" | ||
| key="${TMP}/client.key" | ||
|
|
||
| # 1. Positive case: with a valid client certificate, encryption (which fetches | ||
| # the advertisement via GET /adv) and decryption (POST /rec) must both work | ||
| # over mutual TLS. '-y' skips the interactive trust check. | ||
| cfg="$(printf '{"url":"%s","cacert":"%s","cert":"%s","key":"%s"}' \ | ||
| "$url" "$cacert" "$cert" "$key")" | ||
| enc="$(echo -n "hi" | clevis encrypt tang "$cfg" -y)" | ||
| dec="$(echo -n "$enc" | clevis decrypt)" | ||
| test "$dec" == "hi" | ||
|
|
||
| # 2. The (m)TLS parameters must have been persisted into the JWE protected | ||
| # header so that decryption can reuse them without any extra configuration. | ||
| hdr="$(echo -n "${enc}" | cut -d. -f1)" | ||
| jhd="$(jose b64 dec -i- <<< "${hdr}")" | ||
| test "$(jose fmt -j- -Og clevis -g tang -g cacert -Su- <<< "$jhd")" == "${cacert}" | ||
| test "$(jose fmt -j- -Og clevis -g tang -g cert -Su- <<< "$jhd")" == "${cert}" | ||
| test "$(jose fmt -j- -Og clevis -g tang -g key -Su- <<< "$jhd")" == "${key}" | ||
|
|
||
| # 3. Negative case: mutual TLS must actually be enforced. Without a client | ||
| # certificate the TLS handshake fails, so fetching the advertisement (and | ||
| # therefore encryption) must fail. | ||
| cfg_noclient="$(printf '{"url":"%s","cacert":"%s"}' "$url" "$cacert")" | ||
| ! echo -n "hi" | clevis encrypt tang "${cfg_noclient}" -y | ||
|
|
||
| # 4. Negative case: 'key' without 'cert' is a no-op for curl, so encryption | ||
| # must be rejected up front rather than silently dropping the client key. | ||
| cfg_keynocert="$(printf '{"url":"%s","cacert":"%s","key":"%s"}' \ | ||
| "$url" "$cacert" "$key")" | ||
| ! echo -n "hi" | clevis encrypt tang "${cfg_keynocert}" -y | ||
|
|
||
| # 5. Negative case: a referenced (m)TLS file that does not exist must be | ||
| # reported at encrypt time instead of being baked into the JWE. | ||
| cfg_badcert="$(printf '{"url":"%s","cacert":"%s","cert":"%s","key":"%s"}' \ | ||
| "$url" "$cacert" "${TMP}/does-not-exist.crt" "$key")" | ||
| ! echo -n "hi" | clevis encrypt tang "${cfg_badcert}" -y | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
During decryption,
cacert,cert,key(andurl) are all extracted from the JWE protected header and fed to curl (line 115) before the AEAD integrity check at line 128 (jose jwe dec). Theurlfield was already consumed unauthenticated before this patch, so this is a pre-existing design property of clevis-tang. However,cacertqualitatively extends the attack surface: an attacker who can modify the stored JWE can now also override which CA curl trusts, enabling MITM against the legitimate tang server with a self-signed cert planted on disk. Previously, modifyingurlalone still required a certificate trusted by the system CA store.The practical exploitability is limited (requires disk write access + network position, and the ECMR exchange value alone does not reveal the decryption key), so this may be acceptable as a known trade-off.
Worth considering: validate that cert/key/cacert paths are under an expected prefix (e.g.,
/etc/clevis/), or use indirection (store a profile name, resolve to paths at runtime from a fixed directory). At minimum, document the trust model explicitly so users understand the implication.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for your review! In my understanding, if attacker could modify JWE header, they could probably also modify the ca trust store in /etc/pki. If this is correct, cacert does not add more security risk here (correct me if my understanding is wrong). I also thought about adding validation for cert/key/cacert paths, but considering this aims to be used generically, it is hard to add any specific cacert path validation so I feel path-prefix validation felt too restrictive here.
I added one section named "mTLS SECURITY MODEL" in clevis-encrypt-tang.1.adoc to describe the potential risk of
cacertand recommende that the CA be installed in the system trust store (with cacert omitted) where possible