galaxie has quit [Ping timeout: 256 seconds]
galaxie has joined #nixos-security
<pie_> gchristensen, watching your vuln roundup n + 1 talk, thanks for working on this stuff
<pie_> and everybody else too!
<gchristensen> woot1
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-security
pie_ has quit [Ping timeout: 252 seconds]
pie_ has joined #nixos-security
book` has quit [Quit: Leaving]
ivan has quit [Quit: lp0 on fire]
book` has joined #nixos-security
book` has quit [Client Quit]
book` has joined #nixos-security
ivan has joined #nixos-security
infinisil has joined #nixos-security
simpson has joined #nixos-security
xorAxAx has joined #nixos-security
<xorAxAx> So, the attack vector again: user A runs nixos on a laptop, travels somewhere, does a channel update. then, somebody performs a MITM attack, pointing him to flawed .nix files, poisoning his system.
<xorAxAx> gchristensen points out that you can also use git to fetch the tree
<xorAxAx> that would be an improvement if ssh is being used
<xorAxAx> probably
<simpson> Specifically one of the NixOS-controlled channels at https://nixos.org/channels/, right?
<gchristensen> is one you can fetch vi agit
<LnL> yeah, a MITM of eg. https://nixos.org/channels/nixos-19.03 of could update your channel with unknown expressions
<xorAxAx> yep
<LnL> if you trust github then you can use that repo over ssh
<LnL> I think only ~2 people and the infrastructure have access to that
<infinisil> Would be neat to have a list of potential attacks against Nix(OS)
<gchristensen> access control to the build infrastructure is quite carefully maintained
<xorAxAx> LnL, i am more concerned about on-the-wire threats
<xorAxAx> not somebody mutating the eye-balled repo to contain malware etc.
<pie_> some of my security friends have told me the usual https pki stuff is basically broken because of stolen wildcard certs and who knows whar
<pie_> what
<pie_> but id hope thats not all we're relying o
<pie_> *on. re signing i guess
<LnL> alternatively you could run NIX_SSL_CERT_FILE=foo.crt nix-channel with only the nixos root cert
<xorAxAx> pie_, apparently thats crucial
<xorAxAx> in the default setup
<infinisil> pie_: Take a look at certificate transparency, which solved some problems
<infinisil> But I'm pretty sure wildcard certs can only have subdomain level or lower wildcards
<pie_> yeah idk it was probably some other thing
<xorAxAx> there are CA certs in airplanes that can sign any domain cert
<xorAxAx> according to what i read in the past
<xorAxAx> not sure what the full chain was
<xorAxAx> (somebody saw ssl warnings while surfing on an airplane)
<LnL> problem is that multiple root CA's can sign the same domain, only one of which is the real one
<gchristensen> I can make a CA right now whic hcan sign for any domain cert
<gchristensen> and you too will get the pleasure of seeing SSL warnings
<pie_> installing root CAs via nix updates :D
<xorAxAx> pie_, arent they?
<xorAxAx> LnL, yeah, and it doesnt need to be root CAs which sign the malicious cert
<LnL> well, it still needs to be signed by one of the ~600 in the cacert package
<xorAxAx> LnL, does it? ca depth is limited to 2?
<simpson> xorAxAx: Do you have examples of delivery methods which *would* be acceptable to you, if HTTPS and SSH+git aren't sufficient?
<xorAxAx> simpson, i never said that
<gchristensen> I think they're saying if we signed it and verified it outside of transport
<simpson> Signed *what*, and verified *how*? Just adding another signature doesn't improve anything.
<gchristensen> a simple example is the channel could be fetched like any other substitutable derivation
<gchristensen> and be subject to the same verification rules of any other substituter
<simpson> Hm, can it? Sure, a particular *version* of the channel can be fetched, but to fetch a newer version means to have a newer hash to expect, right? So we still have a problem of getting the new hashes out over a secure distribution channel.
<gchristensen> sure, but you've narrowed the scope of possible results of a channel to "was at one time produced by hydra"
<simpson> Okay, yeah, I see your point.
<LnL> yeah, signing wouldn't prevent fetching an old (ie. insecure) channel
<simpson> Certainly a new hash is also *shorter* than an entire channel!
<LnL> it could keep track of the revision count and warn/fail if that goes down, but that's still not particularly reliable
<infinisil> Could we sign new channel versions with keys distributed in earlier versions?
<pie_> i havent really been keeping track but why cant you just - yeah what infinisil said
<pie_> with the caveat that if an old key is compromised i dont see what you could to about it
<LnL> not sure I understand that
<pie_> does that end up tautological
<xorAxAx> you can also switch to ssh+git, that would be reasonable secure as far as i am concerned
<xorAxAx> as a default method in docs etc.
<xorAxAx> not sure whether that has disadvantages
<pie_> i figure something like this would make sense?: you have a basis of trust which is some root hydra key or something, derive an intermediate key thats actually deployed on hydra, sign artefacts with the intermediate key. the users have the intermediate public keys and can verify artefacts against them.
<pie_> the problem with https pki is that you have various authorities all with the permissions to do anything with anyone
<pie_> at least thats my current limited understanding
<pie_> continuing "<pie_> i figure something like this would make sense?:"; if you have something like that the actual transport medium doesnt matter?
<pie_> (typical self run pki stuff i think)
<pie_> well, certificate pinning is a thing, which kind of alleviates mitm problems, i think
<pie_> (am i just talking nonsense to myself?)
<infinisil> It sounds good at least xD
<pie_> i think theres two possible problems to talk about here, one is security (meaning what exactly?) of the transport protocol, and the other is integrity of the transported data. for public (dunno about private) nix infra i figure we're concerned about the latter, in which case the actual protocol used shouldnt matter?#
<pie_> ^assuming a satisfactory implementation
<pie_> (im quite sure this is a solved problem i just dont know the space too well...)