On 7/20/25 22:22, Julian Andres Klode wrote:
no, as I've written it could mimic the same behaviour as 301 in HTTP(S) which
obviously doesn't interfer with encryption at all.
The key difference is that this is signed and encrypted by the end point you
wanted to talk to.
I'm afraid I don't understand.
To overwrite _https._tcp.deb.debian.org locally is the prerogative of
the admin of the local DNS resolver and users have to trust them
(otherwise they use their own resolver). DNSSEC doesn't help in that
case, as it's not visible to the client using the resolver with the
override.
To use the SRV target as the hostname, the DNS record would need to be
accordingly signed with DNSSEC and that verified such that the authenticity of
the SRV can be tied back to the domain owner.
If the resolver the user trust in is returning a technically valid DNS
answer to the client (e.g. mirror.example.org instead of fastly), the
client cannot know it's semantically legit or not (see above).
Hence, the client (= apt) who is afaik not verifing DNS indepently of
what is configured in /etc/resolv.conf, could then just take that record
and connect to the 'new' hostname (mirror.example.org), verify its
certificate etc.
If I understood your argument correctly, it would imply that apt should
refuse to work in all situations where there's no local DNSSEC
validation as it cannot trust the resolver or the intermediate network
at all - so it would need to do all its DNS queries and DNSSEC
verification on its own.
There is nothing to be prevented on that OSI layer here - as said
before, local network adminstrators can always place a transparent proxy
in between and filter traffic at their will. There is conceptually no
defence in apt itself appropriate for that. What prevents abuse here is
the signatures, hashes and expiration of what's inside the archive, not DNS.
oiow:
* due to the public nature of a debian mirror, it's the content and
it's up2date-ness that needs to be protected, not the mirror it
comes from.
* disallowing using SRV records to shape traffic is not increasing
security or preventing anything, it's making legitimate network
optimization for users benefit needlessly difficult/inconvenient.
Regards,
Daniel