feat(connector): add opt-in standard RDP security support#1201
feat(connector): add opt-in standard RDP security support#1201Dietmar Maurer (maurerdietmar) wants to merge 2 commits intoDevolutions:masterfrom
Conversation
Allow connections using standard RDP security (no TLS, no CredSSP) by adding `enable_standard_rdp_security` to `Config`. When enabled and the server selects standard RDP security, the connector skips the enhanced security upgrade and proceeds directly to basic settings exchange. This is useful when the transport is already secured by other means (e.g., a TLS WebSocket proxy or SSH tunnel). Signed-off-by: Dietmar Maurer <dietmar@proxmox.com>
|
Hello! I’m surprised by the simplicity of this. The documentation / spec about the RDP Standard Security does not mention a non-encrypted mode like described in this PR: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpbcgr/f1c7c93b-94cc-4551-bb90-532a0185246a It is my understanding that the RDP Standard Security uses an old, broken encryption algorithm called RC4. Maybe the intention here is to support something completely different that is not the RDP Standard Security, but rather a custom, non standard transport? |
|
Interesting PR. I face the exact same topology problem: RDP server behind a hypervisor's TLS WebSocket proxy, where the last hop is already secured by the infrastructure. I agree with Benoît Cortier (@CBenoit) that the naming needs a closer look. Per [MS-RDPBCGR] Section 5.3, Standard RDP Security is actually a specific protocol with RC4 encryption and RSA key exchange. It is not "no security." PROTOCOL_RDP (0x00000000) selects that RC4-based mechanism, not an unencrypted mode. So enable_standard_rdp_security reads like it is enabling a security protocol when it is actually bypassing one. Even setting the naming aside, Standard RDP Security (the actual RC4-based protocol) exists in the spec mainly for backward compatibility with very old deployments. Implementing it fully would mean adding RC4 key exchange, which is a lot of work for a mechanism the industry has been moving away from. I am not sure adding either version of this path to the library is the best long-term investment. For what it is worth, I solved this use case differently in my own Proxmox RDP console stack (lamco-qemu-rdp and related components, currently in alpha). The guest-to-host hop uses vsock, which is hypervisor-local and never hits a network. RDP with full TLS/CredSSP is spoken only on the client-facing side. This way the library's security model stays untouched and the deployment topology handles the trust boundary instead. |
It is in section 5.3.2:
This PR does not implement RC4 encryption. Instead, it allows the connector to accept PROTOCOL_RDP (0x0) during X.224 negotiation and proceed with ENCRYPTION_METHOD_NONE / ENCRYPTION_LEVEL_NONE - meaning no encryption at the RDP protocol layer at all. The spec defines this as a valid combination (when both fields are 0, the server random and certificate are absent, and no security exchange occurs).
no. The confusing part in the specs is the last sentence of section 5.3.2:
IMHO, the zero/zero path is there for use cases where data is already encrypted. I tested this and it works with mstsc.exe and xfreerdp3. |
…ryption_level_none Use spec terminology (MS-RDPBCGR 5.3.2) to clarify that this option permits ENCRYPTION_LEVEL_NONE / ENCRYPTION_METHOD_NONE, rather than implying full Standard RDP Security (RC4) support.
|
Thanks for the response, and the rename to The two passages in Section 5.3.2 look contradictory but actually serve different purposes. The passage you cited describes the wire mechanics: what happens IF the server sends zero/zero. The protocol machinery is defined: Security Commencement is skipped, no Security Exchange PDU, no server random or certificate, no security headers on regular PDUs. But the very next sentence is a normative constraint: "To protect the confidentiality of client-to-server user data, an RDP server ensures that the negotiated Encryption Level is always greater than zero when using Standard RDP Security mechanisms." Microsoft's Open Specifications Support Team blog post "Encryption Negotiation in RDP connection" (December 7, 2011) goes further: "It seems that theoretically it is possible to get the unencrypted traffic from client to server if the Encryption Level is set to zero. But in order to protect the confidentiality of client-to-server user data, an RDP server MUST set the Encryption Level to be greater than zero as specified in 5.3.2 of MS-RDPBCGR." The spec defines the zero/zero mechanics because that combination is mandatory under Enhanced RDP Security (Section 5.4.1): when TLS or CredSSP provides the encryption, the RDP layer sets both fields to zero to avoid double-encryption. That is the intended and only spec-conformant use of ENCRYPTION_LEVEL_NONE. Under bare PROTOCOL_RDP with no external security protocol, zero/zero is mechanically parseable but normatively prohibited. Regarding the interop testing: xfreerdp3 does accept ENCRYPTION_LEVEL_NONE from a server. FreeRDP's For mstsc.exe, I'd be curious about the exact topology you tested. Windows has no Group Policy or registry setting that allows encryption level zero under Standard RDP Security. The minimum configurable value is Low (1). If mstsc is connecting through a TLS WebSocket proxy, then from its perspective the connection is Enhanced RDP Security via the proxy's TLS layer, and ENCRYPTION_LEVEL_NONE in the GCC data is the expected, correct behavior. That is a different code path from what this PR enables on the IronRDP client side, which is accepting bare PROTOCOL_RDP with no external security at the RDP protocol level. For this kind of deployment topology, there are ways to get there without the spec-violating combination. The proxy or infrastructure could present the connection as Enhanced RDP Security to the client. If the client negotiates TLS with the proxy endpoint, the server-side ENCRYPTION_LEVEL_NONE becomes the correct, spec-conformant response. The proxy handles the security boundary, and the client and server both follow the spec. Alternatively, the client could negotiate TLS/CredSSP at the RDP layer even behind the proxy. This is defense-in-depth with a slight performance cost, but the library's security model stays completely intact regardless of the transport. One of IronRDP's real strengths compared to FreeRDP is that it's a clean, spec-conformant implementation without years of accumulated workarounds for non-conforming servers. There's real value in preserving that. FreeRDP accepts this path because it's a monolithic client that has to interoperate with everything, but IronRDP has the opportunity to be more principled about what it accepts. I think it's worth exploring whether the infrastructure layer can solve the security boundary problem rather than relaxing the library's protocol conformance. |
|
Following up on the spec discussion. I've been looking at this from the server side too, and I think there's a cleaner path for both sides.
Rather than relaxing the client to accept the spec violation, I think the better fix is on the server side. I've prototyped a PreSecured advertises From the client's perspective, a PreSecured server looks like a normal TLS connection. No client-side changes needed. The zero/zero in the GCC data is expected and correct because the client believes an External Security Protocol is in effect. This covers the WebSocket proxy topology, vsock, SSH tunnels, and any other pre-secured transport without exposing a plaintext PROTOCOL_RDP path. I'll submit it as a separate PR shortly. |
|
First, many thanks for you help. I tested your pre-secured patch, but xfreerdp3 fails now: when UNIX-CONNECT:/var/run/test.rdp is the rdp server using pre-secured: And when I tunnel the connection with: socat reports:
Seems I miss-understand something? |
|
Thanks for testing this. You're right, PreSecured doesn't work. Advertising PROTOCOL_SSL triggers a mandatory TLS handshake per MS-RDPBCGR, and there's no mechanism to signal "TLS is already done" at the protocol level. I was wrong about this approach. Please accept my heartiest apologies for the wild goose chase. Looking at it more carefully, the spec constraint I cited ("ensures > 0") uses softer language than I initially presented. The zero/zero wire mechanics are fully specified and all major clients handle them. FreeRDP has shipped the same pattern for years via the LocalConnection flag with the same rationale (local sockets, SSH tunnels, port forwarding). I thought I was fixing a longstanding problem, but I've just been confusing the isse. I'll close PR #1210. Your approach with the opt-in flag and security warning is the right answer for this use case. Thanks. |
|
I uploaded a new version in PR #1214 (merged both patches, better naming, no functional changes) |
3 participants
Allow connections using standard RDP security (no TLS, no CredSSP) by adding
enable_standard_rdp_securitytoConfig. When enabled and the server selects standard RDP security, the connector skips the enhanced security upgrade and proceeds directly to basic settings exchange.This is useful when the transport is already secured by other means (e.g., a TLS WebSocket proxy or SSH tunnel).