On Thu, Aug 13, 2015 at 05:46:24PM +0000, Anthony Towns wrote:
> On Thu, Aug 13, 2015 at 11:23:19AM +0200, David Kalnischkies wrote:
> > On Wed, Aug 12, 2015 at 11:12:05PM +0000, Anthony Towns wrote:
> > > To use an external repo, you need a deb822 sources.list file and a pubkey.
> > >
> > > To get those, you contact extrepos.debian.net, and either do some sort
> > > of search, or plug in a 6+ digit hex code. extrepos.debian.net spits
> > > back a signed bundle of the repo's public key and a deb822 sources.list
> > > (which includes a description of what the repo is meant to contain), both
> > > named to match the 6+ digit hex code.
> > That could work (see also below), you "just" need to figure out a way of
> > registering an external repository at extrepos.debian.org now, which
> > involves deciding who can register one and how to ensure that what
> > I register is actually owned by me because…
>
> I think my working assumption is "anyone" can register, and it's done
> automatically. If you want to ensure the URL is owned by the register,
> you could use a dummy DNS record ("please add
> extrepo-de684554ae0c3440.example.org CNAME extrepos.debian.net.
> to your DNS").
"Srsly"? Until now it sounded very open, but DNS records are far from
being available for everyone (and far from being secured) beside that
there can be multiple archives on the same domain. Try again.
> > > > > Or did you mean that the DD signs the sources.list file directly? Well,
> > > > > then my key isn't usable for that right now, but in exchange the DD
> > > > > might have a slight problem in assuring the correctness of what he is
> > > > > signing: I am the owner of example.org/debian. Trust me.
> > > I'm not sure this is a problem -- if you're not the owner of
> > > example.org/debian, then the files I download from there won't have your
> > > signature. If they do have your signature, then it's just the question
> > > of whether I trust your random repo, and I can't figure that out just
> > > from knowing who you are.
> > … I was thinking man-in-the-middle here. If I can register
> > example.org/debian with a key of my choosing I can do really bad things,
> > especially if example.org is the domain of a Debian mirror and I manage
> > to trick people into adding this e.g. by claiming that this is a faster
> > mirror…
[…]
> If you put in a /different/ key and go to the trouble of intercepting
> some users' traffic to example.org, things look slightly different:
[…]
> There's a few problems with doing that:
>
> a) anybody whose traffic to example.org you can't intercept will
> get an error if they check that repo against the nominated signing key.
> if extrepos.d.n does minimal sanity checking before adding a repo,
> this makes this attack a non-starter afaics.
So, let me get this straight: The reason we need extrepo.d.o is because
there could be an all consuming man-in-the-middle exchanging the
description as well as the download of the archive key with something of
his own choosing, but if we have extrepo.d.o this is suddently no longer
a problem because it is too unlikely that there is such a man-in-the-
middle.
> b) if someone's trying to install a PPA for secured-ssh, why would
> they go through extrepos?
Because editing sources.list is hard and running 'extrepo add
ppa-whatever-16734' is easy? -- How many people have changed their used
Debian mirror to the DebConf local one. How many would have if I had
posted a extrepo snipped which would do it with just one click?
Or just because the PPAs are signed by the Debians archive keyring
doesn't mean they shouldn't be served by extrepo.d.o as they are
external repositories, just that they have an established trustpath
already – would be bad to have a system to look for packages of (newer
versions of) foobar in external repos which ignores PPAs which might as
well be the best source for it…
> c) if you've gotten someone to install your extrepo, and they'll agree to
> install things signed by your key, why not just point them directly
> at a server you control? if you do that, you can be much nastier,
> eg by serving a real secured ssh to most people, and a vulnerable
> ssh only to people you're trying to hack.
>
> Running an extrepo by someone you don't trust at all is still crazy,
> as installing software written by someone you don't trust at all is crazy.
> The improvement is for the case where:
>
> - you trust "Debian"
> - you trust whoever wrote/packaged the software by reputation
> - you don't have direct communication with the software author/packager,
> or their public key, etc
Which is exactly the problem. You have moved the problem of being unable
to establish a trust path from user to archive, to extrepo to archive
– which is potentially a better place to get a path – but yet you have
completely omitted how the trustpath is established and just declared
that extrepo does it "somehow" while this is the most important part.
So again, lets say I am registering example.org/debian as repository
with key 0xABCDEF, how do you ensure that I am a) the owner of
example.org/debian, b) the owner of 0xABCDEF c) this key is really for
this archive and d) that while I say I am the master of the known
universe (or more realistically, this is the Davids APT ppa), how do you
going to verify that I am who I am saying I am.
> Havng an extrepo lets the software author/packager announce an extrepo id,
> at which point any Debian user can obtain the same extrepo sources.list
> entry. (There's still a potential mitm in *obtaining* the extrepo
> id, but that's more easily mitigated the shorter it is)
Or as you describe it here you are not checking at all at which point
there will be 300 repositories all claiming to be from me so that users
still somehow have to figure out how to contact me personally in
a secure way so I can tell them which one is really from me. And suprise
suprise, that is the very same situation we are in at the moment, so
what was it again we have solved?
> > Which isn't much different to how a man-in-the-middle works nowadays on
> > the installation of an archive-keyring by man-in-the-middle the site
> > where the instructions are written down to add the sources.list entry
> > and the key.
> >
> > SSL CAs regularily mess up checking that I am really the owner of
> > example.org I want to get a certificate for and extrepos.d.o would be
> > basically a certificate authority, just not for SSL but for
> > archive-keys.
>
> SSL CAs associate a key with a site, so that when users see a site,
> they know what key to trust.
>
> But extrepos is the other way around, you decide to trust the key when
> you add the extrepo, after that, whichever URL you end up at just needs
> to be using that key. And you can't easily middleman adding the extrepo
> because that's signed (and dated?) via the extrepo key (which you got
> when you installed extrepo.deb from main).
So you are not linking keys to URLs, which means if I can man-in-the-
middle the users connection to extrepos.d.o I will instead of returning
the signed key for repo A, return the signed key for my bad repo B and
"we are fine"?
I am gonna guess your answer is the second part of the response which
carries the sources template and which key it is supposed to be signed
with. Here you have it, extrepo is certifying which key belongs to which
URL, which is what SSL CAs try.
> > So, what you might want to do is drop the archive key "somewhere"
> > is not /etc/apt/trusted.gpg.d/ and declare with this option where this
> > keyring file is. Maintain this keyring in a -archive-keyring package and
> > you can do key transitions easily. Maintain this package not in the
> > third-party repository but in an extrepos.debian.org archive just
> > containing -archive-keyring packages and you can do 'revokes' of keys by
> > no longer including it in the package, which gives you the 'ping' to the
> > extrepos.d.o service for free in a secure way as otherwise we had to
> > figure out a way to sign the ping, ensure it isn't a replay attack and
> > all that stuff more or less solved for packages.
>
> I think it'd be better to maintain the extrepos keys via a script than a
> single deb -- for one, a deb would have to be updated every time a new
> extrepo gets created, and in any event, the user has to run some sort
> of script to activate an extrepo anyway.
I was thinking every repository has its own -archive-keyring package
like it is now and the extrepo script does install this package rather
than go of by itself and download stuff directly from the internet
because this is hard™ to do right without running into all kinds of
interesting cornercases like replay attacks as the problems do not end
by just signing everything…
> > Maybe I am just pessimistic, but I kinda doubt this would change
> > anything for this class as you usually have to do the 'curl|sh' and
> > similar dance because there is no debian repository [...]
>
> Maybe. But at the moment, even if there /were/ a debian repository,
> "curl|sh" would be easier than going through the hoops to add the repo
> to your system, and it's pretty hard to verify that you're not being
> mitm'ed ("how do I know the key I've got is actually the one you wanted
> me to add?").
How do I know that whoever told me to add it was you? I can trust that
the data coming from extrepo is legit, but I currently can't trust it to
give me the data I expected as valid data for repo A is just as valid as
valid data for repo B and I have no secure way of deciding if A or B is
the right one for me.
> > – and not few people
> > are on the 'creating one is too much work' camp which is why I mentioned
> > signed debs in my last response as I think is a little more realistic to
> > replace them… in like 1 of 100 cases as the rest is too "cool and hipp"
> > to worry about "legacy distros" now that everything can and should be
> > done in the cloud™ where security isn't a problem…
>
> Yeah, I don't disagree. I'd like to have an answer for the people who
> *do* care about security and legacy distros, though. At the moment, I
> don't have one other than "become a DD or DM, and get the package into
> Debian proper".
What makes this process so hard is that there is a proper trustpath in
place. Strip the trustpath and everything is super easy, but also super
insecure. That doesn't mean it must be hard for the user, but if it
isn't hard for the user, it is at least hard for the implementors, but
currently the discussion leads the proposal into neither fast.
> > > > > Oh, what about "add me" files which just add components? That can be
> > > > > done already and is secure, but lets just imagine someone clicks the
> > > > > "add me" file for Debian-main and after that the one for
> > > > > Debian-main-contrib-nonfree. Pretty obvious that this shouldn't end up
> > > > > creating two sources files, right? (+ the joy of detecting mirrors)
> > > That's not obvious to me. First because, why would you be adding "debian
> > > main" ever -- how do you have a Debian system without main? Second
> > > because doesn't having duplicate deb lines in your sources.list work
> > > fine anyway? It seems to for me. And third, if this is just for extrepos
> > > anyway, having each extrepo have a unique base url seems plausible.
> > No it isn't fine to have e.g
> > deb http://httpredir.debian.org/debian sid main
> > deb http://httpredir.debian.org/debian sid main contrib
> > If you drop the 'main' from the second (or just the complete first) line
> > everything is fine.
>
> It seems fine even with the dupe to me? With:
>
> deb http://http.debian.net/debian/ testing main contrib non-free
> deb http://http.debian.net/debian/ testing main
>
> I just get:
>
> W: Duplicate sources.list entry http://http.debian.net/debian/ testing/main amd64 Packages (/var/lib/apt/lists/http.debian.net_debian_dists_testing_main_binary-amd64_Packages)
> W: Duplicate sources.list entry http://http.debian.net/debian/ testing/main i386 Packages (/var/lib/apt/lists/http.debian.net_debian_dists_testing_main_binary-i386_Packages)
>
> ?
Sure, if you not consider warnings from your package manager a problem,
then yes, this is totally fine… with the same reasoning we could ignore
security alltogether as this is just a warning, too, through.
Best regards
David Kalnischkies
Attachment:
signature.asc
Description: Digital signature