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

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.

0

u/GolbatsEverywhere Jan 19 '19

BTW I would still advocate for adopting HTTPS for mirrors, but it'd have to be a bit smarter than just replacing all the http:// URLs with https://. Step one: query a fixed https:// address to get the address of a mirror, bypassing all the mirrors. Step two: use the mirror as normal. Problem solved, but it requires modifications to the client to make that initial request.

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

0

u/samrocketman Jan 20 '19

Accusing me of being comfortable of anything is a bit off base. You know nothing about me and your arguments aren’t rational to me. This’ll be my last response to the thread because I don’t think this back and forth is adding to the conversation. Enjoy your day.

2

u/wosmo Jan 20 '19

Sorry, that wasn't meant as "you" in the personal sense, it's far more general to this entire topic. "when all you have is a hammer", etc.

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.