Package: apt

Hi,

in order to transparently overwrite deb.debian.org in our own network,
we can overwrite the SRV records for http on the internal resolvers, i.e.:

_http._tcp.deb.debian.org. IN SRV 10 1 80 mirror.example.org.

however, in the case of HTTPS using _https.tcp.deb.debina.org this
doesn't work as we'll be having a certificate mismatch
(mirror.example.org cannot have a valid deb.debian.org certificate).

it would be nice, if apt would not just replace the IP of the
deb.debian.org request with the IP of mirror.example.org, but instead
treat it more like a 301: the request to deb.debian.org should be done
as a request to the hostname provided (aka mirror.example.org).


this would allow local network administrators to transparently redirect
traffic to the internal mirror in cases, where it's unrealistic to have control/influence the clients otherwise (in our case, large university
network with all BYD devices).

I don't think this is a privacy/security issue if apt would implement
this, as you have to trust your local network administrator anyway (they
could use transparent proxies instead and still "inject" .deb files
without the user noticing it) and can't enforce client side where the
.debs are downloaded from.

As a user, you can be still sure that what you're getting is valid, as
all the security measures of apt-secure (gpg validation, indices
expiration, etc.) are untouched by that and will prevent any tampering.


or in other words: please support making local mirroring using
deb.debian.org possible with https.

Regards,
Daniel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Julian

No that's not how SRV records work or can even work.

I don't think we have the same understanding on "how SRV records work"
then. however, ...

You'd completely violate the basic premise of TLS encryption and authenticity, allowing your local network operator to intercept
encrypted communications.

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.

but whatever.

Regards,
Daniel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20 July 2025 16:07:50 CEST, Daniel Baumann <[email protected]> wrote:

Hi Julian

No that's not how SRV records work or can even work.

I don't think we have the same understanding on "how SRV records work" then. however, ...

You'd completely violate the basic premise of TLS encryption and
authenticity, allowing your local network operator to intercept
encrypted communications.

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.

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.

--
sent from my phone, excuse the brevity, if any

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)