Repository navigation
Refuse redirects when fetching a creator's key - #7
Merged
Merged
Conversation
Found in the review that followed the Python and PHP fetches, which were modelled on this one and inherited it. The key fetch followed redirects. HttpURLConnection follows one to any other host by default, refusing only a change of protocol, so a creator whose domain answered 302 to some other https host would have that other host's key trusted as its own, and a network attacker able to bend the creator's DNS, or a creator that was simply misconfigured, could put a key there and have forgeries verify. There is no legitimate reason for the well known key end point to send a caller off its own host, and this is the one request in the specification whose answer decides whether an identifier is genuine. setInstanceFollowRedirects(false) leaves the 3xx as the response code, which read() already treats as the key being unavailable with the code carried, which is what it is. The stand in end point learned a REDIRECT answer naming where to send the caller. The new test redirects to a second stand in serving the genuine schedule, so following would read as valid, and asserts the answer is unavailable, the creator was asked once, and the second stand in never was. It fails when redirects are followed again. DatedKeyFetchTest: 15 tests, up from 14.
jwrosewell
added a commit
to 51Degrees/pipeline-java
that referenced
this pull request
Sep 6, 2026
…ing a key (#126) The 51Degrees fork of owid-java now carries SWAN-community/owid-java#7, which stops HttpURLConnection following a redirect from a creator domain, so a creator whose domain answered 302 could no longer have some other host's key trusted as its own. The pin moves from 764996e0 to 44d4e0bf, the fork's main after the sync. PublicKeyFetch.java stays excluded from this module's build, as before, because DidClient fetches the cloud's key list through its own transport. pipeline.did tests: 127 run, 0 failures.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found in the review that followed the Python and PHP fetches, which were
modelled on this one and inherited it.
The key fetch followed redirects. HttpURLConnection follows one to any
other host by default, refusing only a change of protocol, so a creator
whose domain answered 302 to some other https host would have that other
host's key trusted as its own, and a network attacker able to bend the
creator's DNS, or a creator that was simply misconfigured, could put a
key there and have forgeries verify. There is no legitimate reason for
the well known key end point to send a caller off its own host, and this
is the one request in the specification whose answer decides whether an
identifier is genuine.
setInstanceFollowRedirects(false) leaves the 3xx as the response code,
which read() already treats as the key being unavailable with the code
carried, which is what it is.
The stand in end point learned a REDIRECT answer naming where to send the
caller. The new test redirects to a second stand in serving the genuine
schedule, so following would read as valid, and asserts the answer is
unavailable, the creator was asked once, and the second stand in never
was. It fails when redirects are followed again.
DatedKeyFetchTest: 15 tests, up from 14.
Produced with AI assistance after an adversarial review of the fetch across every port, and needs human review before merging. Held for the batch merge with the other six. The test was proved by mutation.