Hacker News new | ask | show | jobs
by explainplease 2699 days ago

    $ sudo sed -i 's/http:/https:/g' /etc/apt/sources.list
    $ sudo apt-get update
    ...
    Err https://us.archive.ubuntu.com trusty/main Sources                          
    Failed to connect to us.archive.ubuntu.com port 443: Connection refused
    ...
    Err https://security.ubuntu.com trusty-security/main amd64 Packages
    Failed to connect to security.ubuntu.com port 443: Connection refused
  
???

    $ curl -v https://security.ubuntu.com/ubuntu/
    * Hostname was NOT found in DNS cache
    *   Trying 91.189.88.149...
    * connect to 91.189.88.149 port 443 failed: Connection refused
    *   Trying 91.189.88.152...
    * connect to 91.189.88.152 port 443 failed: Connection refused
    *   Trying 91.189.88.161...
    * connect to 91.189.88.161 port 443 failed: Connection refused
    *   Trying 91.189.88.162...
    * connect to 91.189.88.162 port 443 failed: Connection refused
    *   Trying 91.189.91.23...
    * connect to 91.189.91.23 port 443 failed: Connection refused
    *   Trying 91.189.91.26...
    * connect to 91.189.91.26 port 443 failed: Connection refused
    * Failed to connect to security.ubuntu.com port 443: Connection refused
    * Closing connection 0
    curl: (7) Failed to connect to security.ubuntu.com port 443: Connection refused
So even security.ubuntu.com is unavailable over HTTPS? Am I missing something?
1 comments

As was discussed recently on HN (and linked to elsewhere in the comments for this article), packages are signed, and APT checks those signatures; however, APT does download both the packages and the signatures in the clear. So, normally, the signatures get checked, which ensures that you get the package you intended. This is fine, mostly. (If you don't care about privacy, but it does prevent tampering, normally.)

APT does not, however, give privacy, which HTTPS/TLS would. (Those in favor argue that TLS doesn't help here, as you can still see that you're connecting to Ubuntu, so it's still obvious that you're downloading updates. I personally disagree w/ this stance: I think there is value in protecting which packages you're pulling updates for, as what packages you have installed can inform someone about what you're doing. I think there's further argument that the sizes of the responses give away which updates you're pulling, but IDK, that seems harder to piece together, and TLS at least raises the bar for that sort of thing.)

The bug discussed in the article circumvents the signature checking, by lying to the parent process about the validity of the signature by being able to essentially execute a sort of XSS/injection attack.

I think you misunderstood my comment. I'm aware of the apt security model and the nature of this bug.

My point is that these Ubuntu repo servers are not available over HTTPS, which seems like a problem. In the context of this bug, a serious one--who's to say that there aren't more bugs like this lurking? There's no reason that these servers shouldn't be available over HTTPS.