Skip to content
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

Initial security audit feedback #166

Closed
FragLegs opened this issue May 14, 2024 · 1 comment · Fixed by #174
Closed

Initial security audit feedback #166

FragLegs opened this issue May 14, 2024 · 1 comment · Fixed by #174
Assignees
Labels
bug Something isn't working spec:SSF v3 Address this issue before the v3 cutoff (June 15, 2024)

Comments

@FragLegs
Copy link
Contributor

The first draft of the security audit highlighted several small items that ought to be fixed before we move to a release version.

2024-04-09_WP4.1a-Report.pdf

The relevant sections have been copied below.

3. Notes on the SSF Specification

Based on our work with the SSF specification, we suggest the working group consider the following
changes. Most of these are based on (necessary) assumptions explained in Section 2 and we note
that our model reflects the specification with these changes.

Issuer Identifier Validation.

While the configuration discovery specification mandates Transmitters to only use issuer identifiers with the https scheme [10, Section 6.1], there is no requirement
for Receivers to only request configuration documents from https URLs. If a Receiver requests a
Transmitter’s configuration document from an http URL, a network attacker may launch an MitM
attack, resulting in the Receiver accepting arbitrary, attacker-chosen configuration data (including
JWKs) and arbitrary, attacker-chosen SETs. We, therefore, recommend explicitly mandating Receivers to (1) obtain Transmitters’ issuer identifiers from trusted sources, and (2) verify that these
issuer identifiers use the https scheme.
In our model, we assume that these recommendations are implemented (see Section 2.5).

Stream Configuration Management API Endpoints.

The current SSF specification does not
mandate the use of https for any of the stream configuration management API endpoints. We
note that for SET delivery, [RFC8935, RFC8936] mandate the use of https URLs, and of course
recommend mandating Transmitters to use https URLs for all stream management API endpoints
and the JWKs endpoint.

In our model, we assume that this recommendation is implemented (see Section 2.5).

Requirements on Additional SET Delivery Methods.

In our model, we only consider the push
and poll delivery methods as defined in [RFC8935, RFC8936] (see Section 2.2). This implies that
in our model, SET delivery always takes place via TLS-protected connections. However, the SSF
5
specification does not limit allowed delivery methods to these two. Hence, we recommend requiring
the use of SET delivery methods that ensure SET confidentiality and integrity.

@FragLegs FragLegs added bug Something isn't working spec:SSF v3 Address this issue before the v3 cutoff (June 15, 2024) labels May 14, 2024
@FragLegs
Copy link
Contributor Author

Issuer Identifier Validation

I will address this in an associated PR.

Stream Configuration Management API Endpoints

PR #173 requires TLS for all stream management endpoints

Requirements on Additional SET Delivery Methods

I think this issue might already be addressed. In section 7.1.1, the method field of the delivery object in the Stream Configuration data restricts the delivery options to either push or poll.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working spec:SSF v3 Address this issue before the v3 cutoff (June 15, 2024)
Projects
None yet
1 participant