What are the plans for the CentOS repos with respect to authentication and https everywhere? At the moment it is a trivial exercise to perform a MTM attack during a yum update over http.
On Fri, May 15, 2015 at 03:44:39PM -0400, James B. Byrne wrote:
What are the plans for the CentOS repos with respect to authentication and https everywhere? At the moment it is a trivial exercise to perform a MTM attack during a yum update over http.
Since the packages themselves are signed, what risk are you concerned about?
On 05/15/2015 02:49 PM, Matthew Miller wrote:
On Fri, May 15, 2015 at 03:44:39PM -0400, James B. Byrne wrote:
What are the plans for the CentOS repos with respect to authentication and https everywhere? At the moment it is a trivial exercise to perform a MTM attack during a yum update over http.
Since the packages themselves are signed, what risk are you concerned about?
Not only are the packages signed, but we're now offering signed repository metadata as well.
HTTPS is an incremental improvement, but is by no means a silver bullet. Look at the superfish fiasco if anyone thinks otherwise.
The other side to this is many people update from outside .centos.org. Who's cert would you use for mirrors.kernel.org/centos/7/os/x86_64/ for example?
On 16/05/15 08:36, Jim Perrin wrote:
On 05/15/2015 02:49 PM, Matthew Miller wrote:
On Fri, May 15, 2015 at 03:44:39PM -0400, James B. Byrne wrote:
What are the plans for the CentOS repos with respect to authentication and https everywhere? At the moment it is a trivial exercise to perform a MTM attack during a yum update over http.
Since the packages themselves are signed, what risk are you concerned about?
Not only are the packages signed, but we're now offering signed repository metadata as well.
HTTPS is an incremental improvement, but is by no means a silver bullet. Look at the superfish fiasco if anyone thinks otherwise.
The other side to this is many people update from outside .centos.org. Who's cert would you use for mirrors.kernel.org/centos/7/os/x86_64/ for example?
Agreed, MITM isn't a great problem as the packages are signed.
People monitoring your connection know what you've updated, and what you haven't, thus knowing what you may be vulnerable to, is a problem. But quite arguably not a great as problem as a MITM attack.
Pete.
On 05/16/2015 04:18 PM, Peter Lawler wrote:
People monitoring your connection know what you've updated, and what you haven't, thus knowing what you may be vulnerable to, is a problem.
If I'm monitoring your https connection: I know the list of mirrors. That's public information. I know when updates are released. That's also public. I know when you last connected, so I can probably reason what you haven't updated. If I track the amount of data you download, I can probably tell if you skip an update, as well.
https doesn't improve your privacy in this application.
On 05/19/2015 07:07 AM, Kai Bojens wrote:
On 17-05-15 10:35:55, Gordon Messmer wrote:
https doesn't improve your privacy in this application.
No, but it makes it a little bit harder for third parties to gather all these information. That seems to be a worthy goal for me.
Except that mirror.centos.org is a large RRDNS set of mirrors (with geoip redirection) all over the world, not one machine. Fedora also does not do this, because it is not possible in the community setting .. especially since updates are hosted at remote mirrors too. There is a mirrorlist that points to any number of mirrors, some controlled by centos.org, others not. For example:
http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=updates
this results in the following output from my location right now:
http://mirror.cogentco.com/pub/linux/centos/6.6/updates/x86_64/ http://mirrors.usinternet.com/centos/6.6/updates/x86_64/ http://repo.atlantic.net/centos/6.6/updates/x86_64/ http://mirrors.cat.pdx.edu/centos/6.6/updates/x86_64/ http://mirror.steadfast.net/centos/6.6/updates/x86_64/ http://cosmos.cites.illinois.edu/pub/centos/6.6/updates/x86_64/ http://mirrors.umflint.edu/CentOS/6.6/updates/x86_64/ http://mirrors.xmission.com/centos/6.6/updates/x86_64/ http://centos.arvixe.com/6.6/updates/x86_64/ http://www.gtlib.gatech.edu/pub/centos/6.6/updates/x86_64/
30 minutes form now, it may result in a completely different list. It will be a completely different list if accessed from the UK instead of the US:
http://mirror.as29550.net/mirror.centos.org/6.6/updates/x86_64/ http://www.mirrorservice.org/sites/mirror.centos.org/6.6/updates/x86_64/ http://mirrors.vooservers.com/centos/6.6/updates/x86_64/ http://centos.hyve.com/6.6/updates/x86_64/ http://mirror.mhd.uk.as44574.net/mirror.centos.org/6.6/updates/x86_64/ http://mirrors.melbourne.co.uk/sites/ftp.centos.org/centos/6.6/updates/x86_6... http://mirrors.coreix.net/centos/6.6/updates/x86_64/ http://mirrors-uk.go-parts.com/centos/6.6/updates/x86_64/ http://mirror.econdc.com/centos/6.6/updates/x86_64/ http://mirror.ox.ac.uk/sites/mirror.centos.org/6.6/updates/x86_64/
We can not ensure all of those sights instead use https, etc. Nor could we possibly serve all the updates from one set of mirrors that we own to all the millions of CentOS users around the world.
The packages are signed and now there is also even signed metadata for CentOS-6 and centOS-7 .. you can verify you are getting the correct packages (so no man in the middle).
You can also easily create your own copy of mirror.centos.org to update against that is internal to your own facility, thereby keeping all traffic on your own routers and not show anything to the outside world at all.
If you want to go to that effort, then by all means stand up your own copy.
Thanks, Johnny Hughes
On 19/05/15 13:07, Kai Bojens wrote:
On 17-05-15 10:35:55, Gordon Messmer wrote:
https doesn't improve your privacy in this application.
No, but it makes it a little bit harder for third parties to gather all these information. That seems to be a worthy goal for me.
We can likely make the mirrorlist content available on https fairly easily, and encourage other mirrors to also offer urls that run over https.
The other challenge with mirror.centos.org is also driven by it being a network run on donated hardware, not sure if we want to put the https certs on machines that other people can get hands-on easily.
-
Gordon Messmer -
James B. Byrne -
Jim Perrin -
Johnny Hughes -
Kai Bojens -
Karanbir Singh -
Matthew Miller -
Peter Lawler