Repository navigation
Conversation
This specification documents the protocols used by OpenVPN Inc. for device posture and certificate checks. It serves as a general example of an app custom control protocol in production and documentation for those implementing support for interacting with OpenVPN Inc. clients and servers. Signed-off-by: Heiko Hund <heiko@ist.eigentlich.net>
rzvncj
left a comment
rzvncj
left a comment
There was a problem hiding this comment.
Thanks for writing this down, it's very useful to have. As it stands, though, I don't think a third party could interoperate from it: the ACC protocol names, the JSON envelope and most of the CCK mechanics are missing. Details inline.
- Nit: typo in the commit subject ("specifiction").
201f7d7 to
fcfaa61
Compare
fixed |
| include both in the ACC parameters for them to become usable. A DPC request may | ||
| ask for a certificate check, which then runs over CCK, so neither protocol | ||
| is useful on its own. CCK payloads are base64-encoded, so the encodings list | ||
| MUST include the value for it. |
There was a problem hiding this comment.
Should we just say 6 here? That's the value for it.
| * ACC packets contain the cck1 protocol identifier. | ||
| * The data is binary, so ACC carries it base64-encoded. | ||
| * The payload does not carry any of the mandatory DPC JSON fields. | ||
| * Each chunk of TLS ciphertext is sent as a separate ACC message. These messages are |
There was a problem hiding this comment.
Technically this is "TLS record bytes" or something like that, since e.g. ClientHello is plaintext.
| Position in the connection negotiation | ||
| -------------------------------------------------------------------------------- | ||
| DPC and CCK run while client authentication is still pending, before | ||
| PUSH_REPLY: |
There was a problem hiding this comment.
So a reconnect into an existing session skips AUTH_PENDING, so ACC gets enabled by custom-control and DPC runs after PUSH_REPLY, which is not currently acknowledged in this spec.
| and "cck1" for CCK protocol. | ||
|
|
||
| The client MUST announce both dpc1 and cck1 in IV_ACC, and the server MUST | ||
| include both in the ACC parameters for them to become usable. A DPC request may |
There was a problem hiding this comment.
This could be just the way that I am reading this paragraph, but it seems to require that both dpc1 and cck1 must be present at the same time, but pre-existing code doesn't require that (each can be present on its own).
| extra.name /etc/os-release ID, fallback uname -s. | ||
| extra.arch uname -m. | ||
| extra.core_ver uname -r. | ||
| extra.extra_ver /etc/os-release VERSION, fallback uname -v. |
There was a problem hiding this comment.
extra_ver falls back to uname -r in the pre-existing code.
| Linux | ||
| type uname -s. | ||
| version /etc/os-release VERSION_ID, fallback uname -r. | ||
| extra.name /etc/os-release ID, fallback uname -s. |
There was a problem hiding this comment.
version and name have no fallback and come out empty.
This specification documents the protocols used by OpenVPN Inc. for device posture and certificate checks. It serves as a general example of an app custom control protocol in production and documentation for those implementing support for interacting with OpenVPN Inc. clients and servers.