feat(dgw): support vmconnect in RDCleanPath #1372
Conversation
irvingoujAtDevolution
commented
Jun 4, 2025
irvingoujAtDevolution
commented
- WIP
- works
Let maintainers know that an action is required on their side
|
CBenoit
changed the title
| // Preconnection Blob (PCB) is currently only used for Hyper-V VMs. | ||
| // | ||
| // Connection sequence with Hyper-V VMs (PCB enabled): | ||
| // ┌─────────────────────┐ ┌─────────────────────────────────────────────────────────────┐ | ||
| // │ handled by │ │ handled by IronRDP client │ | ||
| // │ Gateway │ │ │ | ||
| // └─────────────────────┘ └─────────────────────────────────────────────────────────────┘ | ||
| // │PCB → TLS handshake │ → │CredSSP → X224 connection request → X224 connection response │ | ||
| // └─────────────────────┘ └─────────────────────────────────────────────────────────────┘ | ||
| // | ||
| // Connection sequence without Hyper-V VMs (PCB disabled): | ||
| // ┌─────────────────────────────────────────────────────────────┐ ┌──────────────────────┐ | ||
| // │ handled by Gateway │ │ handled by IronRDP │ | ||
| // │ │ │ client │ | ||
| // └─────────────────────────────────────────────────────────────┘ └──────────────────────┘ | ||
| // │X224 connection request → X224 connection response → TLS hs │ → │CredSSP → ... │ | ||
| // └─────────────────────────────────────────────────────────────┘ └──────────────────────┘ | ||
| // | ||
| // Summary: | ||
| // - With PCB: Gateway handles (1) sending PCB, (2) TLS handshake, then leaves CredSSP | ||
| // and X224 connection request/response to IronRDP client | ||
| // - Without PCB: Gateway handles (1) X224 connection request, (2) X224 connection response, | ||
| // then leaves TLS handshake and CredSSP to IronRDP client |
There was a problem hiding this comment.
praise: Good summary and explanation.
issue: However, this implementation assumes that the presence of a Preconnection Blob (PCB) implies the use of the Hyper-V VMConnect flow, where X.224 messages are exchanged after the CredSSP sequence. However, this assumption is overly restrictive.
While the PCB is indeed utilized in Hyper-V scenarios, particularly with VMConnect, which employs a unique connection sequence involving CredSSP prior to X.224 negotiation, it's important to recognize that the PCB is a general-purpose mechanism that does not necessarily imply an altered connection sequence. RDP clients, such as MSTSC and FreeRDP, support specifying a PCB without altering the conventional connection sequence, where X.224 negotiation precedes CredSSP authentication.
suggestion: The implementation should not default to the Hyper-V VMConnect flow solely based on the presence of a PCB. For instance, you could verify whether cleanpath_pdu.x224_connection_pdu is Some or None. If it’s None, it seems fair to assume the Hyper-V VMConnect flow.
