[arghwhat]

You seem to have forgotten all the critical TLS bugs we had. Heartbleed ring a bell?

> An attacker doesn't get to attack client's HTTP stack without first piercing protection offered by TLS.

You misunderstand: this means more attack surface.

The attacker can mess with the far more complex and fragile TLS stack, and any attacker controlling a server or server payload can also attack the HTTP stack.

Have you recently inspected who owns and operates every single mirror in the mirror list? None of these are trusted by you or by the distro, they're just random third parties - the trust is solely in the package and index signatures of the content they're mirroring.

I'm not suggesting not using HTTPS, but it just objectively wrong to consider it to have reduced your attack surface. At the same time most of its security guarantees are insufficient and useless for this particular task, so in this case the trade-off is solely privacy for complexity.

[Avamander]

That was a long time ago and it was specific to one implementation. In comparison GnuPG has had so many critical vulnerabilities even recently. That's why Apt switched to Sequoia.

Modern TLS stacks are far from fragile, especially in comparison to PGP implementations. It's a significant reduction in attack surface when it's a MITM we're talking about.

Malicious mirrors remain a problem, but having TLS in the mix doesn't make it more dangerous. Potential issues with PGP, HTTP and Apt's own logic are just so much more likely.

[arghwhat]

If you believe TLS is more fragile than PGP and plain HTTP, then I have reason to believe you have never looked at any of those wire protocols/file formats and the logic required.

Adding TLS in front of HTTP when talking to an untrusted third-party server (and yes, any standard HTTPS server is untrusted int his context), can only ever increase your attack surface. The only scenario where it reduces the attack surface is if you are connected with certificate pinning to a trusted server implementation serving only trusted payloads, and neither is the case for a package repo - that's why we have file signatures in the first place.

[Avamander]

I have implemented parts of all three. I doubt you have.

> Adding TLS in front of HTTP when talking to an untrusted third-party server, can only ever increase your attack surface.

No, against a MITM it instantly subtracts the surface inside the TLS from the equation. Which is the entire point.

> [...] that's why we have file signatures in the first place.

You still don't understand that even before the cryptographic operations done in order to verify the signatures you have all those other layers. Layers that are complex to implement, easy to misinterpret and repeatedly to this day found flawed. PGP is so terrible no serious cryptographer even bothers looking at it this day and age.

I start getting the feeling that you're involved in keeping the package repositories stuck in the past. I can't wait for yet another Apt bug where some MITM causes problems yet again.

[arghwhat]

> I start getting the feeling that you're involved in keeping the package repositories stuck in the past.

I start getting the feeling that you have no actual experience in threat modelling.

[dns_snek]

This entire discussion has been about MITM attacks but you keep making arguments that are irrelevant in this context. A compromised web server that's serving malicious data is not a MITM attack.

Do you acknowledge this disconnect? Is there a good reason why you keep responding to discussion about MITM with ridicule and the type of responses I'd expect from someone who's severely confused what constitutes a MITM attack and what doesn't?