Please add transaction integrity for APT.

[vbgf3]

@currentshaft
"No, they can't. TLS defends against MITM."

TLS encryption only protects the contents of https traffic.(in other words, browser traffic ) So it does protect your https content from eavesdropping by opponents. But TLS does not protect against packet injection. An entire package can be inserted into ubuntu apt's stream, and TLS wouldn't blink. TLS also does not protect the ip address header.

Now lets say I used a repository that supports https. Then the traffic contents will be protected against eavesdropping. But since APT handles http as well as https repositories, the encrypted transmission is transparent to it. APT checks on the package itself being OK and not tampered with. If the attacker inserts a properly signed package, APT will proceed to install it. His package being OK and valid does not preclude that it is not something I want on my system, like for example open-sshd. ( I don't want/need remote access capability )

I don't want to point this out in your face, but you overvalue encryption and think it solves all problems.

So the scripts I mentioned are post installation scripts that I run to configure Ubuntu; copying over conf files, removing unwanted packages and so on. The attacker has modified my scripts so that they fail, by making a syntax error here and there etc. I know the scripts should run pefectly because I wrote and debugged them. And that is tampering in STRIDE.

You are harboring the thought that all my thinking is paranoia and fantasy. But my failed scripts are evidence of tampering. And I have shown the mitm can still be done. If you want to, you can look into the many techniques that can be used to implement mitm. Arp manipulation is my favorite.

"Counter what? You still have not demonstrated a threat."
So now I have demonstrated a threat. And that is mitm. Fedora dnf's transaction checks protect against a package being inserted into an upgrade stream.

And also, since the attacker was modifying my installation scripts, they too are not protected by the existence of TLS 1.3. TLS encryption solves only particular problems. But does not protect me in this instance. Now you can re-read what I am doing and consider it in a different light.

[vbgf3]

..

[vbgf3]

..

[currentshaft]

TLS encryption only protects the contents of https traffic.(in other words, browser traffic ) So it does protect your https content from eavesdropping by opponents. But TLS does not protect against packet injection. An entire package can be inserted into ubuntu apt's stream, and TLS wouldn't blink. TLS also does not protect the ip address header.

This is absolute nonsense. It really is.

Inject packets into an end-to-end encrypted TLS stream? How would that even work?

You realize 99.99% of websites support TLS 1.2, right?

If what you're saying is true, then no website on the internet is secure.

Of course it's not true and we can all breathe a sigh of relief.

Also, why does the "IP address header" need "protection"? From this comment alone it is apparent you don't understand the technology being discussed.

Now lets say I used a repository that supports https. Then the traffic contents will be protected against eavesdropping. But since APT handles http as well as https repositories, the encrypted transmission is transparent to it. APT checks on the package itself being OK and not tampered with. If the attacker inserts a properly signed package, APT will proceed to install it. His package being OK and valid does not preclude that it is not something I want on my system, like for example open-sshd. ( I don't want/need remote access capability )

How would an attacker insert a properly signed package ... without the keys? Using magic?

I don't want to point this out in your face, but you overvalue encryption and think it solves all problems.

I never made that assertion, nor was it implied.

So the scripts I mentioned are post installation scripts that I run to configure Ubuntu; copying over conf files, removing unwanted packages and so on. The attacker has modified my scripts so that they fail, by making a syntax error here and there etc. I know the scripts should run pefectly because I wrote and debugged them. And that is tampering in STRIDE.

What OBJECTIVE PROOF do you have of this happening? If you have no OBJECTIVE PROOF, it DID NOT HAPPEN. Is that clear yet?

You are harboring the thought that all my thinking is paranoia and fantasy. But my failed scripts are evidence of tampering. And I have shown the mitm can still be done. If you want to, you can look into the many techniques that can be used to implement mitm. Arp manipulation is my favorite.

What failed scripts? You have posted zero evidence of anything. Just an incoherent rant about apt packages which defies all logic and even common sense.

So now I have demonstrated a threat. And that is mitm. Fedora dnf's transaction checks protect against a package being inserted into an upgrade stream.

No, you did not demonstrate a threat.

You made an unqualified and wrong opinion on how apt package integrity works.

You made a word-salad of some common information security terminology which did not logically compute.

That wrong understanding is compounded by your stubborn attitude and unwillingness to even consider the possibility you might be wrong.

I have tried my best to help you, but without providing artifacts of your situation (logs, command outputs, screenshots, etc), it won't be possible to have a productive discussion.

[TheFu]

https://www.zdnet.com/article/china-...-1-3-and-esni/ - that's from 2020. The Chinese "Great Firewall" only allows encryption that they can crack

Exceptional claims require exceptional proof.

We're 13 posts in this thread and no real facts have been posted, just claims.

[vbgf3]

Hi currentshaft:

Here is a clear explanation : https://community.isc2.org/t5/Tech-T...%20IP%20header.

In summary there are 2 ways of doing it. One is End to End ecryption, which does not encrypt the ip address header. It only encrypts the data. With the ip address header in clear text, routers on the internet can route the packet

The other is Link encryption which does encrypt the ip address header. This requires dedicated connection points for both ends.

Here is another explanation: https://en.wikipedia.org/wiki/HTTPS#...esponse%20data.

[currentshaft]

Hi currentshaft:

Here is a clear explanation : https://community.isc2.org/t5/Tech-T...%20IP%20header

The amount of nonsense techno-babble in that post is truly impressive. It makes this entire thread look like an O'Reilly book by comparison. I mean, it is truly stupid stuff.

It's time to stop following what some random online strangers are contriving and time to start doing threat modeling, if security is a priority.

And to state the obvious again: Ubuntu apt is not at risk of "unauthorized updates are inserted into the upgrade stream". Such bold claims will require bold evidence.

[QIII]

OK. That'll do for now.

Closed.