From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Lukas Wagner <l.wagner@proxmox.com>,
Proxmox Datacenter Manager development discussion
<pdm-devel@lists.proxmox.com>,
Dominik Csapak <d.csapak@proxmox.com>
Subject: Re: [pdm-devel] [PATCH datacenter-manager v3 00/23] ] improve remote wizard
Date: Fri, 22 Aug 2025 10:10:17 +0200 [thread overview]
Message-ID: <5702030e-0478-49e4-9b54-8a0d54d9d340@proxmox.com> (raw)
In-Reply-To: <DC82WTUXN9TL.1ZKJOPN2XE9LA@proxmox.com>
On 21/08/2025 13:45, Lukas Wagner wrote:
> On Thu Aug 21, 2025 at 10:39 AM CEST, Dominik Csapak wrote:
>> ## Fingerprint confirmation dialogs
>>
>> Not sure if we want to be able to let the user confirm the fingerprint
>> so easily. On one hand it's very convenient, but maybe leads to users
>> simply clicking yes without understanding what's happening.
>>
>> If it's deemed too dangerous, I'd rework the series without this.
>
> As said in v2, I think it's fine to have such a dialog, but I'd like to
> hear some other opinions before we apply this.
>
> @Thomas, do you have an opinion on this?
+1, there's only so much one can do and Trust On First Use (TOFU) is a
widely established principle (e.g. SSH's host key verification).
Furthermore, having this now does not hinder us from improving it in
the future, like through some encoded "remote join info" that can be
copied from the PVE system, which would also include the fingerprint.
Note, that doing so does not really reduces the risk of a MITM attack
vector, because if an attacker can MITM the connection between
PDM and PVE, then it's equally likely that they can also MITM the one
between the admin's browser and PVE. IMO one option is not inherently
more likely/easier to happen than the other, the only bigger (security)
benefit of a "remote join info" would be of reusing the trust the
admin's (browser) has with the PVE system already, besides that it's
mostly for convenience.
FWIW, we could improve how we show the current fingerprint in general.
Currently it's viewable through the Certificate view in the node UI,
but one needs to open an extra window and one also needs to know which
cert to check, because if pveproxy-ssl.pem exists (e.g. ACME set up)
that one is used, otherwise it's pve-ssl.pem.
So just showing the fingerprint column by default is IMO not that
big of an help, maybe adding a short panel at the top detailing
the relevant TLS details for a direct API connection, which mostly
is the fingerprint though.
Anyhow, that's orthogonal to this, as said above, having such a
dialogue is certainly fine for now, it's common industry practice,
doesn't locks us in, admins that do care about security can still
ensure it's safe and for all others it's hard to rule out the MITM
vector completely, maybe some challenge response between PVE and
PDM might help, but again can still be done in the future.
>
>>
>> # Future work
>>
>
> [snip]
>
>> ui/src/remotes/wizard_page_connect.rs | 314 +++++++++++++++++---------
>> ui/src/remotes/wizard_page_info.rs | 121 +++++-----
>> ui/src/remotes/wizard_page_nodes.rs | 239 +++++++++++++++++++-
>> ui/src/remotes/wizard_page_summary.rs | 5 +-
>> ui/src/widget/mod.rs | 3 +
>> ui/src/widget/pve_realm_selector.rs | 123 ++++++++++
>> 15 files changed, 872 insertions(+), 203 deletions(-)
>> create mode 100644 ui/src/widget/pve_realm_selector.rs
>
> Gave this one another go. Code looks good to me, only two minor
> complaints about outdated doc comments and one question about the
> permissions for the tls-probe endpoint (see individual patches).
>
> Consider this:
>
> Reviewed-by: Lukas Wagner <l.wagner@proxmox.com>
>
> Also tested this again, found two small issues:
> - Seems like the realm selector is still not disabled when "Use
> existing token" is selected
> - When you modify something in the "Endpoints" tab (e.g. the IP
> address for some endpoint), go back to "Settings" and then back to
> "Endpoints", the changes are lost - I guess in this case the info is
> fetched again from the API and the changes overwritten.
>
> These could also be fixed in a follow-up, since these do not impeded the
> core functionality of the dialog, IMO.
_______________________________________________
pdm-devel mailing list
pdm-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel
next prev parent reply other threads:[~2025-08-22 8:10 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-21 8:39 Dominik Csapak
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 01/23] server/ui: pve: change 'realm list' api call to GET Dominik Csapak
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 02/23] api types: RemoteType: put default port info to the type Dominik Csapak
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 03/23] server: connection: add probe_tls_connection helper Dominik Csapak
2025-08-21 11:46 ` Lukas Wagner
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 04/23] server: add probe-tls endpoint Dominik Csapak
2025-08-21 11:46 ` Lukas Wagner
2025-08-21 11:55 ` Dominik Csapak
2025-08-21 11:58 ` Lukas Wagner
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 05/23] server: pve api: extend 'scan' so it tls-probes the nodes Dominik Csapak
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 06/23] pdm-client: add scan_remote and probe_tls methods Dominik Csapak
2025-08-21 11:46 ` Lukas Wagner
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 07/23] ui: remotes: node url list: add placeholder and clear trigger Dominik Csapak
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 08/23] ui: remotes: node url list: make column header clearer Dominik Csapak
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 09/23] ui: remotes: node url list: handle changing default Dominik Csapak
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 10/23] ui: pve wizard: rename 'realm' variable to 'info' Dominik Csapak
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 11/23] ui: pve wizard: summary: add default text for fingerprint Dominik Csapak
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 12/23] ui: pve wizard: nodes: improve info text Dominik Csapak
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 13/23] ui: pve wizard: nodes: probe hosts to verify fingerprint settings Dominik Csapak
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 14/23] ui: pve wizard: info: use pdm_client for scanning Dominik Csapak
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 15/23] ui: pve wizard: info: detect hostname and fingerprint Dominik Csapak
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 16/23] ui: pve wizard: info: remove manual scan button Dominik Csapak
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 17/23] ui: widget: add pve realm selector Dominik Csapak
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 18/23] ui: pve wizard: info: use " Dominik Csapak
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 19/23] ui: pve wizard: connect: factor out normalize_hostname Dominik Csapak
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 20/23] ui: pve wizard: connect: move connection logic to next button Dominik Csapak
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 21/23] ui: pve wizard: connect: reset later pages when form changes Dominik Csapak
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 22/23] ui: pve wizard: connect: use scan api endpoint instead of realms Dominik Csapak
2025-08-21 8:39 ` [pdm-devel] [PATCH datacenter-manager v3 23/23] ui: pve wizard: connect: add certificate confirmation dialog Dominik Csapak
2025-08-21 11:45 ` [pdm-devel] [PATCH datacenter-manager v3 00/23] ] improve remote wizard Lukas Wagner
2025-08-22 8:10 ` Thomas Lamprecht [this message]
2025-08-22 9:03 ` [pdm-devel] superseded: " Dominik Csapak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5702030e-0478-49e4-9b54-8a0d54d9d340@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=d.csapak@proxmox.com \
--cc=l.wagner@proxmox.com \
--cc=pdm-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox