2013-12-13 IRC conversation¶

_hc any thoughts on the validation order? pin --> tofu vs. tofu --> pin

_hc sounds like you got the CN=IP stuff figured out too :-D

pd0x Yup! Without having to do anything scary like implement my own hostname validation

pd0x I think that pin's should override tofu

_hc what do you use as the CN then?

pd0x the CN is still the IP (to make browsers happy). I had to add a SubjectAltName extension to the cert that also has the IP

_hc right, the grand plan we discussed pin --> tofu --> CA --> prompt

pd0x You can specify an IP type for the SAN and that was enough to make things happy

_hc does MTM/tofu check the cert or the key?

pd0x hc I'm looking at the code now. It checks whether the Certificate is in the MTM keystore to decide if it's seen it before.

pd0x So it's based on the whole cert (which matches what I see with Kerplapp)

_hc but the pinning is based on the key?

pd0x if your IP changes the Kerplapp keypair will be the same but the cert will be regenerated with the new CN & SAN

pd0x and MTM prompts twice

pd0x Yes, pinning is based on the key

pd0x So if you pinned the Kerplapp keypair it wouldn't prompt for any of the certs, despite IP changes

_hc even though it checks MTM then pinning?

pd0x Yah, MTM will say "Do I have this cert in my keystore?" the answer will be no if the IP changed, then it will go to Pinning trust manager which will say "Ah, I have a pin for the SPKI on this cert" and it will work transparently

_hc I see

pd0x hmm, so it's really tofu -> pin -> CA -> prompt I suppose

pd0x since if tofu hsa a memory of the cert it'll accept it before the pin

pd0x I can't decide if that's a problem or not

pd0x the cert memory is more specific than the pin (in that it trusts an exact certificate memory and not any cert with the right SPKI)

pd0x and in theory if there was a pin appropriate for the memorized cert it would have used that on first decision and not the memorizing trust manager

pd0x so there should never BE a stored TOFU'd memory for a cert that we knew a pin for

pd0x because the Pinning manager will OK the cert before prompt to memorize

_hc I think the grand plan would be* pin-cert --> tofu-cert --> pin-key --> tofu-key --> CA --> prompt

_hc so what you added to fdroid is a version of that with pin-cert and tofu-key removed

_hc or maybe the tofu-key step is pointless

pd0x I'm not sure it buys much and will be a complicated thing to explain in a prompt to a user

pd0x "Trust the key or trust the certificate?"

_hc tofu-key might make it too complicated

pd0x Do you think we need pin-cert either? That's basically the same as tofu-cert except it allows for preloading the trust

pd0x and we can already preload the trust by key instead of cert

_hc I think pin-cert would be useful

pd0x using AndroidPinning

_hc but lots of people are lazy about https keys, because they don't really matter that much in the CA model

pd0x You think there are cases where we want to pin to a very precise cert and not the pub key?

_hc in the CA model, the signed cert is what's important

pd0x I see pins as things you mostly ship statically with a build and so you want them to be flexible enough to live through standard SSL lifecycle stuff like renewing a cert with the same keypair but a new expiry

_hc I think that people should only pin the key if they know that means they have to treat the key in a full paranoid way

_hc yes, that's true

pd0x I think we're on the right path anyway :-) maybe we should try to get this workflow merged before we add more complication to justify

_hc pin-cert means you can be lazier about the signing key, but have to be good about client/cert/pin updates

pd0x yeah, it's a trade-off

_hc pin-key means you can be lazy about cert/client updates, but have to good about protecting the ky

pd0x but you need to be good about protecting the key if you want to be able to trust the cert pin too

_hc but since pins are done by devs, and affect the dev mostly, I think we can have both in the framework, and have the tradeoffs documened

pd0x if I can steal the private key I can use the pinned cert just as easily as I can generate a new cert with the same key

_hc if someone gets the key, they can't easily get the cert they generate also signed by the CA

pd0x they don't need to though

_hc but if there is no CA in the picture, and everything that comes from that key is trusted, then the key becomes everthing

pd0x with the private key they can offer the certificate you already got signed & prove knowledge of the corresponding priv key

pd0x there isn't a need to get another cert generated/signed

pd0x if the priv key is compromised it doesn't matter if you pinned the cert or the pub key

pd0x You're equally hosed

_hc but that cert would only work for the pre-registreed domains

pd0x that's true

_hc so you need to either pwn the key and server, which are the same thing, or pwn the key and CA

pd0x hmm

pd0x or pwn the key & MITM?

_hc if you get the server, the key is on that server, and you could get the pw from RAM

pd0x you just need to get in the path of traffic from alice to bob and can use your stolen private key & the public cert signed by the CA to transparently MITM

_hc unless the server has the key on a smartcard

_hc then tey can get the pin but not the private key

pd0x hmmmmmmmmmmm

_hc hmm

_hc so if you have the private key, you can MITM? how would that work? the cert validation would fail

pd0x Why would it?

_hc as far as I understand it, HTTPS ensures you're only talking to the host that's specified in the cert

pd0x Alice attempts to connect to https://guardianproject.org/fdroid/repo and I MITM a response that offers the valid CA signed cert that the real repo would use. I have the private key that corrsponds to the public key in the certificate so I can perform the standard handshakes and everything will proceed identically to the real host

_hc if you have the private key, I suppose you could decrypt the traffic, but not inject

pd0x it ensures the hostname you connect to matches the one in the cert

pd0x Maybe I'm wrong and missing something fundamental? Haven't had much coffee today lol

*13:20

_hc so if you have control of the client's DNS and you have the server's private key, then you can MITM

pd0x I don't think you need control of the client DNS. That would let you change things so Alice connects directly to Mallory instead of Bob. I think you could also do this by being able to manipulate traffic between Alice and Bob

_hc if you have access to the traffic, you could modify the traffic I suppose

pd0x Alice detects that they are talking directly to Bob and there isn't a Mallory in between on the basis of the HTTPS certificate

pd0x with the private key corresponding to that certificate's public key you can provide Alice all the same assurances they are talking to Bob

pd0x You effectively ARE Bob with possession of Bob's private key

_hc except for the CA sig

pd0x which is on the certificate that you provide

pd0x You can take the byte for byte identical certificate chain offered by the real Bob and provide it as your own

_hc a new cert, or the original one

pd0x What prevents you from doing that normally is that you need to also have possession of the private key to use it in SSL negotiation

_hc to do that, you'd have to change the clients mapping of hostname to IP

pd0x not if you're injecting traffic in the conversation between Alice and Bob's IP

_hc yes, if you have the server private key, and router-level access to their traffic, you could modify the traffic

_hc without changing the IP

pd0x Right, that's what I'm saying

pd0x and pinning to the whole cert, or the public key doesn't change the outcome

_hc I don't know if I'd call that a MITM since there is no redirection

pd0x fair

pd0x have I convinced you that adding cert-pinning isn't a meaningful addition?

_hc yeah, pinning certs would give only a little bit of extra protection at a higher risk of usability penalty

_hc pinning certs would help with the situation where someone got the private key, but didn't pwn the server

_hc so I guess its something like tofu-cert --> pin-key --> CA --> prompt

_hc but then the question is* do you tofu the cert after its been verified by pin-key?

_hc probably not

pd0x Nope

_hc then it shouldn't it be pin-key --> tofu-cert --> CA --> prompt

_hc or maybe even* pin-key --> tofu-key --> tofu-cert --> CA --> prompt, with tofu-key being an "advanced option"

_hc for kerplapp, we'll need tofu-key

_hc but my guess is that most apps will want to tofu-cert

pd0x that's going to take some patches to the Memorizing Trust Manager

_hc Ge0rG was open to that

_hc I think the idea was to start with AndroidPinning and MTM, and make a new lib

pd0x that makes sense

_hc I guess the last question is whether to tofu-key, tofu-cert, or both