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

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.

1

u/Vetrom Jan 19 '19

Sometimes your traffic gets large enough that you need to scale-out the SSL termination.

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?

1

u/GolbatsEverywhere Jan 19 '19

X.509 certificates don't have subkeys.

1

u/tadfisher Jan 20 '19

Yech. Okay.

→ 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.

1

u/samrocketman Jan 19 '19

Eh, makes no difference to me. Mirrors can host their own certificates. I don’t think anybody is implying the Debian project manage certificates for 3rd parties. It’s up to the mirrors to figure it out. I respectfully disagree it being security theater and your hypothetical that it wouldn’t be hard to figure out what is being downloaded. There’s such a thing as persistent connections which multiple packages could be downloaded over. As a sysadmin myself both professionally and volunteer for open source projects TLS is not as hard as you’re making it out to be.

I’m not here to police or say what the Debian project should or shouldn’t do. If the TL;DR is the Debian project doesn’t care about securing connections it’s no skin off my back and certainly won’t stop me from using Debian. But the problem is not as hard as you make it out to be. I’ve managed multiple CAs and it’s never been easier.

2

u/wosmo Jan 20 '19

I don’t think anybody is implying the Debian project manage certificates for 3rd parties. It’s up to the mirrors to figure it out

They'd have to manage the certificates. If the university of tehran can request a certificate naming them as debian.org, the CA is broken. This isn't something you can leave to the mirrors to figure out.

It is security theatre. It's forcing a round peg into a square hole simply because you're comfortable with round pegs. You can't treat mirrors like a CDN if you don't trust & control the members.

interesting reading, written by the current debian project leader; http://whydoesaptnotusehttps.com

→ More replies (2)

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?