0

I have Xubuntu 18.04.3 LTS installed on a live USB with persistence. With apt using http sources instead of https. How can I confirm that I am getting all the security updates? According to the accepted answer in this post How to use https with apt-get? an unscrupulous ISP could reroute the request to stale security packages. I have tried changing the APT sources to https, however, upon sudo apt-get update I received the following connection failure warnings:

W: Failed to fetch https://security.ubuntu.com/ubuntu/dists/bionic-security/InRelease 
Could not connect to security.ubuntu.com:443 (91.189.91.14). - connect (111: Connection refused) 
Could not connect to security.ubuntu.com:443 (2001:67c:1560:8001::11). - connect (113: No route to host) 
Could not connect to security.ubuntu.com:443 (91.189.88.149). - connect (111: Connection refused) 
Could not connect to security.ubuntu.com:443 (2001:67c:1360:8001::21). - connect (113: No route to host) 
Could not connect to security.ubuntu.com:443 (91.189.88.174). - connect (111: Connection refused) 
Could not connect to security.ubuntu.com:443 (91.189.88.24). - connect (111: Connection refused) 
Could not connect to security.ubuntu.com:443 (91.189.88.162). - connect (111: Connection refused) 
Could not connect to security.ubuntu.com:443 (2001:67c:1560:8001::14). - connect (113: No route to host) 
Could not connect to security.ubuntu.com:443 (91.189.91.26). - connect (111: Connection refused) 
Could not connect to security.ubuntu.com:443 (91.189.88.31). - connect (111: Connection refused) 
Could not connect to security.ubuntu.com:443 (91.189.91.23). - connect (111: Connection refused) 
Could not connect to security.ubuntu.com:443 (91.189.88.173). - connect (111: Connection refused) 
Could not connect to security.ubuntu.com:443 (2001:67c:1360:8001::17). - connect (113: No route to host) 
Could not connect to security.ubuntu.com:443 (91.189.91.24). - connect (111: Connection refused) 
Could not connect to security.ubuntu.com:443 (2001:67c:1562::16). - connect (113: No route to host) 
Could not connect to security.ubuntu.com:443 (2001:67c:1562::19). - connect (113: No route to host)

It gives the same warning for other sources as well. I am not able to pull up https://security.ubuntu.com on my browser either, but I am able to pull up other secure sites.

The contents of the APT sources are:

deb cdrom:[Xubuntu 18.04.3 LTS _Bionic Beaver_ - Release i386 (20190805)]/ bionic main multiverse restricted universe  
deb https://archive.ubuntu.com/ubuntu/ bionic main restricted universe multiverse  
deb https://security.ubuntu.com/ubuntu/ bionic-security main restricted universe multiverse  
deb https://archive.ubuntu.com/ubuntu/ bionic-updates main restricted universe multiverse

EDIT: There may be three routes to ensuring that a given system is getting the latest updates. The first may be to provide the updates over SSL/TLS and thus fail by letting the victim know that the network isn't allowing the system to access a known secure resource. The second method could be to provide information about the availability of the update through SSL/TLS, and the actual update through mirrors which would also make noise if the system is prevented from getting the information related to the update, or the update itself. The third, and the simplest option would be to maintain a timestamp/serial number, or a set of timestamps/serial numbers by update type on a website secured by SSL/TLS, so that the admin for the given system can compare it with timestamps/serial numbers on the system to ensure that the system has the latest updates. My question is whether these or similar methods exist by which I can ensure that my system has the latest updates.

EDIT: It has been suggested that the answer to the post Are repository lists secure? Is there an HTTPS version? answers my question. Given the last method that I have suggested in my previous edit, there wouldn't be a necessity of having a direct SSL/TLS connection to the resource lists. My question is whether there is any way available, be it through SSL/TLS, or through simple HTTP, to ensure that my system has the updates that have been released up to that point? One can easily imagine an IT auditor asking the same question. Furthermore, being able to verify that his/her system has the latest updates can also allow a user to refrain from using the system for financial, or similar matters, when it's not, and is being prevented from receiving the updates. A good answer would be one that states that a method exists and explains the method by which one can confirm that a given system has the latest updates, or one that admits that no such mechanism exists at present.

Jaq
  • 1
  • The same thread you linked to also pointed out that the evil-ISP attack was 1) Far-fetched, 2) Would cause apt to throw a signatures-don't-match error. Lots of security built into apt over the past 20 years. While there are a few advantages to https (mostly conveniently bypassing proxies instead of significant security improvement), the hassle and cost of trying to maintain ssl certs on hundreds of volunteer servers --that Ubuntu archive admins don't have access to-- seems greater than the benefit. – user535733 Feb 15 '20 at 14:41
  • The accepted answer in the linked post states: "In fact, there is one small benefit to HTTPS for step 4: the package signatures only ensure that the package is authentic. An attacker in step 4 could impersonate a legitimate server and serve stale versions of the package. For example, the attacker could prevent you from downloading any security updates, in the hope of exploiting a vulnerability on your machine that you would have patched if it wasn't for the attack." – Jaq Feb 16 '20 at 10:34
  • 1
    The answer to your specific question is: "You cannot connect using https to mirrors that don't provide https". But seems like you probably knew that already. So what is your real question? How to find https-compatible mirrors? Or are you trying to start a discussion? Or are you asking about mirror security? Or something else? – user535733 Feb 16 '20 at 16:22
  • The accepted answer on the attached post also stated "apt-get (and other package manipulation commands, which are a front-end to the same APT libraries) can use HTTP, HTTPS and FTP (and mounted filesystems). If you specify https:// URLs in /etc/apt/sources.list and /etc/apt/sources.list.d/*, then APT will use HTTPS.", given which, I have simply changed the http to https urls in my sources file. My question, as the title of my post indicates, is, how can I verify that my system has the latest security updates if I am unable to access, or do not have the list of secured APT sources. – Jaq Feb 17 '20 at 16:12
  • 3
  • Sorry for the delay in my response. The link that was referred to by Stephen has an answer that states "It would be plausible for a man-in-the-middle to substitute an archive with an unmodified earlier version of the archive within this Valid-Until date and cause your APT to believe there are no updates." This defines my issue in brief. As soon as the vulnerability is listed in a CVE database, an attacker gains an opportunity, and if the attacker has control of the network, they can prevent or delay an update, and add a permanent weakness by adding a user or opening an ssh port, etc. – Jaq Apr 17 '20 at 10:15
  • 1
    Do note that even over TLS connections, a MITM attacker can keep you from getting security updates by simply preventing you from contacting the service in the first place. It's a bit noisier than serving you with stale apt lists, but the end result is similar: you can't get updates. – sarnold Apr 18 '20 at 01:00
  • Thank you for your response. Noise, and a whole lot of it, would be preferred in such cases, so that at least one could ask for an explanation from the network provider, and also to know when the system may not be safe for online banking, etc.. Even from an IT audit standpoint one would want to ensure that the system has been updated up to a certain time stamp or serial number that one can verify from a secure website. – Jaq Apr 18 '20 at 01:53

0 Answers0