ppa.launchpad.net does not support https

As the packages you download from launchpad are all cryptographically signed just like with every other debian repository, a man-in-the-middle attack is not really feasible. apt checks the signature of the downloaded .deb files and any tampering would lead to an invalid signature. Invalid signatures cause an error prior to installation. So I don't see this as a major problem from a security perspective.

One could argue that it is a violation of privacy as anyone listening in on the connection could see which software you are installing. Therefore, an HTTPS connection would indeed be preferable.

As for your last question regarding if they couldn't just add the certificate and be done with it, we both don't know how the infrastructure behind ppa.launchpad.net works. For a single server things are often that simple. But I doubt that we are talking about a single simple server. The infrastructure is probably more complicated than that and therefore the setup may be more complicated. There are also issues regarding server load to consider, as encrypting all outgoing traffic requires a lot more CPU cycles than just delivering it. Depending on the volume of traffic they receive this may cause significant load on the server which they might not want to handle. But please bear in mind that this is just speculation on my part and the reasons might be entirely different.

Why is there no cert for ppa.launchpad.net?

See Launchpad bug 1473091: default PPAs to HTTPS

William Grant (wgrant) replied on 2015-07-10:

This is non-trivial due to the arbitrary content served on the domain. We would do better to move it away from ppa.launchpad.net entirely.

Colin Watson (cjwatson) replied on 2017-03-27:

It would require deciding on and acquiring a suitable domain for this that isn't under launchpad.net (compare e.g. launchpadlibrarian.net, which exists for the same reason), since otherwise an XSS attack by user-supplied content on ppa.launchpad.net would be able to steal cookies from its launchpad.net superdomain. We're currently saved by the Secure attribute, but that would become ineffective if ppa.launchpad.net were served over HTTPS. It would of course then require reconfiguring various things to point to that, and I would expect quite a bit of miscellaneous fallout; it's the sort of task that requires budgeting a lot of time for debugging.

Colin Watson (cjwatson) elaborated on 2020-02-03:

Launchpad needs to set the domain of its session cookies to ".launchpad.net" so that they're visible by its other virtual hosts (code.launchpad.net, bugs.launchpad.net, etc.), but this also causes them to be visible to all other subdomains of launchpad.net. We also set the "secure" flag on those cookies, which mitigates this by ensuring that browsers at least only send them over HTTPS. However, if ppa.launchpad.net were accessible over HTTPS, then any page there would be able to exfiltrate your session cookie. While I don't currently know of a way to get ppa.launchpad.net to serve arbitrary content with Content-Type: text/html, it's a service that hosts a great deal of user-generated files, and it wouldn't take that much to construct abuses of it that would confuse browsers. We need to move it before using HTTPS is safe.

Colin Watson (cjwatson) began actions to resolve the bug on 2021-09-28:

I've filed https://portal.admin.canonical.com/C133313 (internal link only) asking our sysadmins to register another domain so that we can start making progress on this.

On 2021-09-30:

The alternate domain in question has been registered, and I've filed https://portal.admin.canonical.com/C133345 (again, internal link only) to get it configured on the relevant host.

Launchpad now supports HTTPS (2022)

Launchpad has finally launched support for serving PPAs over HTTPS!

So you can now do a find and replace of any apt sources.list files that refer to the old domain:

• http://ppa.launchpad.net/ → https://ppa.launchpadcontent.net/
• https://private-ppa.launchpad.net/ → https://private-ppa.launchpadcontent.net/

This is a big improvement for privacy, since eavesdroppers can no longer see what PPAs you visit or what packages / OS versions you download.

Using HTTPS to provide transport layer security also adds defense in depth, in case a vulnerability is discovered in GnuPG or in the apt package signing mechanisms. This has happened several times in years past, so this is a big improvement.

https://bugs.launchpad.net/launchpad/+bug/1473091

There's another ticket (still open as of 2022-02-07) to change add-apt-repository to prefer HTTPS by default.

https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1959015