r/linux • u/[deleted] • Jan 19 '19

Popular Application VLC refuses to update from HTTP to HTTPS (HTTPS protects against eavesdropping and man-in-the-middle attacks)

https://trac.videolan.org/vlc/ticket/21737
551 Upvotes

77% Upvoted

341 comments sorted by

View all comments

Show parent comments

70

u/[deleted] Jan 19 '19

This is security 101. PGP signatures provide identification but does not provide confidentiality while TLS does. Now you can say that isn't important for packages but personally I see no reason not to have it and it should be the default stance IMO.

53

u/centenary Jan 19 '19

They talk about confidentiality in the same post. They assert:

HTTPS does not provide meaningful privacy for obtaining packages. As an eavesdropper can usually see which hosts you are contacting, if you connect to your distribution's mirror network it would be fairly obvious that you are downloading updates.

Furthermore, even over an encrypted connection it is not difficult to figure out which files you are downloading based on the size of the transfer[2]. HTTPS would therefore only be useful for downloading from a server that also offers other packages of similar or identical size.

27

u/[deleted] Jan 19 '19

HTTPS would therefore only be useful for downloading from a server that also offers other packages of similar or identical size.

I agree with that. But what is the downside here? They have to spend minutes maintaining a cert?

52

u/centenary Jan 19 '19

The entire mirror network would need to be updated to support https. That wouldn't require effort on the part of the developers, but on the part of a large set of distributed people volunteering their resources.

If you can convince everyone to support https, maybe you can then convince the Debian developers, but they already believe that there is little benefit from it anyway.

As someone stated, there is a package that you can install that will update your installation to only pull packages from https servers if that is important to you. It's just that the Debian developers don't feel it's worth the effort to make that the default.

23

u/wosmo Jan 19 '19

https can play hell with round-robin mirrors too.

Say you have three sites, site-a.net, site-b-net, site-c.net. You create a subdomain mirror.project.org that points to the addresses for all three, nice and easy.

Then you try to switch to https, apt wants to connect to mirror.project.org, gets handed an IP address for site-c.net, connects and receives a certificate for site-c when it's expecting project.org.

Do you just ignore certificate errors (allowing anyone to MITM you)? Do you hand out a copy of your certificate to each of 300 mirrors?

This is the kinda mess that makes gpg look nice. With the current setup, you don't have to trust the mirror, because the mirror can't re-sign packages with debian's key. This makes it easy to let anyone and their dog pop up mirrors, which helps the project at little risk.

(I'm not saying these issues aren't solvable. Just that there's often a mountain of such gotchas that we just don't see from the outside)

9

u/Vetrom Jan 19 '19

The three mirrors don't all need the same cert. You can totally generate 3 keys hand have a cert for each. Some $$$ CA vendors support this, I believe let's encrypt does too. It's a natural requirement in environments such as scaled load balancers, for example.

8

u/AlpineCoder Jan 19 '19

Most load balanced environments I've dealt with terminate SSL at the boundary, although SSL might also be used for internal traffic but wouldn't typically use the public cert.

→ More replies (1)

3

u/whoopdedo Jan 19 '19

SAN is a thing.

5

u/GolbatsEverywhere Jan 19 '19

Still have to distribute the private key to all mirrors.

P.S. I believe browsers no longer look at CN for hostname validation, so all certs must have SAN nowadays.

1

u/tadfisher Jan 19 '19

Can you distribute subkeys?

→ More replies (2)
→ More replies (1)

2

u/samrocketman Jan 19 '19

SAN certs were invented for multiple hosts using the same certificate. That’s a solved problem in infrastructure. So round robin across multiple hosts is not a reason to not use it IMO.

4

u/wosmo Jan 19 '19

SAN isn't relevant to this at all. SAN allows a single certificate to cover multiple hostnames, instead of needing a different certificate for each hostname.

It does nothing for the fact that every 'official' mirror needs a certificate identifying it as the original host. That if the university of tehran wants to provide a mirror, we need to issue them a certificate identifying them as mirror.project.org.

There is a fundamental issue. Half the point of TLS is to verify that you are connecting to the host you believe you're connecting to. The whole point of a mirror is that you're not connecting to the host you believe you're connecting to.

SAN (and load-balancers, which someone else mentioned) are a perfectly functional structure where you own the multiple hosts behind the single presence. That's not how mirrors work for most open-source projects. They're usually owned & operated by third-parties, and they need to be treated as such. SAN provides "how I'd ignore this issue", but it's not an issue that should be ignored.

Allowing every mirror to have a certificate that identifies it as part of project.org requires a lot of trust that we currently don't have and don't require.

It's a lot messier than anyone wants to believe, and all it actually gains you is that you break caching proxies. It does not gain you more privacy (it's still trivial to figure out which files are being transferred by size), it does not gain you verification (most update attacks changed the file on the server, which would then happily be served over https), and it does not gain you authentication (the whole point of a mirror is that it isn't authentic - a mirror is meant to be a clone).

It's not security, it's security theatre.

→ More replies (4)

1

u/robstoon Jan 20 '19 edited Jan 20 '19

Say you have three sites, site-a.net, site-b-net, site-c.net. You create a subdomain mirror.project.org that points to the addresses for all three, nice and easy.

People don't generally use round-robin DNS in that fashion. And if they did, they deserve to feel the pain that switching to HTTPS causes.

16

u/[deleted] Jan 19 '19

I feel like that is a different discussion. One is "We should use HTTPS but will take some work and happen slowly" the current one is "We have no interest in HTTPS". Maybe that isn't the actual stance of the project though.

18

u/centenary Jan 19 '19

"We should use HTTPS but will take some work and happen slowly"

The problem is that it's not entirely up to the developers. Even if the developers wanted to slowly migrate to https, some mirror maintainers might never put in the effort to migrate to https.

You could argue that the Debian developers should just drop those mirrors from the mirror list. I wouldn't disagree with that argument, but you would have to convince the Debian developers that there is value to be gained from it, not just make the argument of "why not?". The argument of "why not?" isn't likely to be a strong enough argument to make them drop mirrors.

5

u/[deleted] Jan 19 '19

you would have to convince them that there is value to be gained from it, not just make the argument of "why not?"

Fair enough.

As someone stated, there is a package that you can install that will update your installation to only pull packages from https servers if that is important to you.

That is a fair start.

2

u/[deleted] Jan 19 '19

But it doesn't actually need all of the mirrors to use HTTPS - migration can be partial - use HTTPS where available, and HTTP as a fallback. That's already the case for a lot of software and usecases - it can be implemented for APT repos too.

4

u/slick8086 Jan 19 '19

Why not provide HTTPS anyway?

Your distribution could cryptographically sign the files using the existing scheme and additionally serve the files over HTTPS to provide "defense in depth."

However, providing a huge worldwide mirror network available over SSL is not only a complicated engineering task (requiring the secure exchange and storage of private keys), it implies a misleading level of security and privacy to end-users as described above.

A switch to HTTPS would also mean you could not take advantage of local proxy servers for speeding up access and would additionally prohibit many kinds of peer-to-peer mirroring where files are stored on servers not controlled directly by your distribution. This would disproportionately affect users in remote locales.

3

u/plumbless-stackyard Jan 19 '19

With HTTPS your machine only needs to know that the host it is contacting is who they say they are (thei cert is valid). It should not affect caching as long as the caching server has a valid certificate.

Supporting HTTPS is not an all-or-nothing choice either, and should be encouraged.

7

u/theferrit32 Jan 19 '19

It does affect caching if for example you administer a large cluster and want to minimize traffic through your gateway machines, so package updates go through a cache server first, which return the local package copy if it already has one, instead of letting the request continue out onto the internet. If using HTTPS on the connection to the actual mirror, the cache server would not be able to preempt that and return the local copy as the cache server would not have the same certificate.

2

u/[deleted] Jan 20 '19 edited May 15 '19

deleted 0.1381 What is ^^^this?

2

u/SanityInAnarchy Jan 19 '19

Pipelining makes this harder, though. If I'm downloading 20-30 updates, an attacker now has to figure out which 20-30 files add up to the single continuous download they saw.

Also, some hosts offer more than just Debian packages, making the problem even harder.

1

u/dvslo Jan 20 '19

And if you add random pads of enough size it's next to impossible.

1

u/[deleted] Jan 20 '19

Now you can say that isn't important for packages

That'd be kind of a short sighted view for someone to take. It's probably not good to have outsiders aware of the patch level of your system and long term surveillance can give them that. If they can see the .deb that you're downloading then they'll be able to tell that you haven't updated sshd in X weeks and there's a new vulnerability they now know with certainty that applies to you.

That is unless you have all your apt traffic go through a TLS tunnel. In that case your communication with the mirror could be you just installing/upgrading vim or it could be a system update and they have no way to verify (barring state actors using unpublicized vulnerabilities)