Support Client Certificates about convergence HOT 27 CLOSED

Right, well, there is no need to trust a CA at all with a client cert technically, as the client cert can do full two way Dixie-Hellman verification and detect any (well, unless the attacker knows the keys and then you are totally stuffed) MITM (man in the middle), this however causes an issue, cause at the moment, we have to MITM the connections as firefox does not expose an API for us to do our own verification instead. As a such the this is being detected as it should be and refusing the connection. The only solution at the moment is to turn off convergence when using a client certificate.

from convergence.

@apie are you referring to client cert auth (TLS mutual auth)?

from convergence.

Oops, I meant: It no longer supplies my client certificate to my webserver.

from convergence.

Yes, you are using a certificate to login right?

from convergence.

@Lcstyle Yes. @ewanm89 Yes.

from convergence.

SSL Handshake.

http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=%2Fcom.ibm.mq.csqzas.doc%2Fsy10660_.htm

from convergence.

Even if we pass the cert onto the server, cause it only contains public keys and not private keys the proxy does not know the private keys, they server should kill the connection as a MITM attempt. It should be 100% impossible to MITM a mutal authentication without knowing one or other private keys.

from convergence.

Yep, forgot about that.

The client sends a CertificateVerify message, which is a signature over the previous handshake messages using the client's certificate's private key. This signature can be verified by using the client's certificate's public key. This lets the server know that the client has access to the private key of the certificate and thus owns the certificate.

from convergence.

Yup, standard part of a full mutual authentication (adapted straight out of diffie-hellman key exchange), as long as there wasn't an attack in the initial cert generation, and will detect any and all MITM attacks. This also means that the certificate authority check is frivolous (and in extension convergence) too once client cert is generated.

Suggest we close as a can't/won't fix

Currently the best we could do, is create a way automatically bypass convergence or at least, just pass the packets on as is when doing full mutual auth. But we have no way to know 'till the server sends the client certificate request message. This is why we need an SSL cert API, so we can get the cert for all connections without having to MITM everything.

from convergence.

What about creating a way to store the pub/priv pair in convergence? Let the convergence client have the cert so it can perform the cert auth?

from convergence.

@Lcstyle, thought of that, but no way to move already generated ones into it. And do you really want a known MITM on connections that would be guaranteed secure (as long as public key crypto is secure) and trusted without convergence.

from convergence.

I would argue that a trojan or keystroke logger on the client would be able to get any and all data from said connection even if there was no MITM. But you're right we're splitting hairs now. This probably should be closed as can't/won't fix.

from convergence.

@apie does disabling convergence (clicking the lock icon) and refreshing the page restore client cert auth functionality?
Or do you need to disable the extension and then restart Firefox?

from convergence.

@Lcstyle , yes, disabling convergence and refreshing the page should restore absolutely normal browser behavior.

from convergence.

@chrisglass, we know it should, we want to confirm that is does.

from convergence.

Seems like Convergence should check the NSS certificate DB for client certs when initiating SSL connections and use them if they're present. Sounds like a pain. =)

from convergence.

I can confirm that "disabling convergence (clicking the lock icon) and refreshing the page restores client cert auth functionality."

from convergence.

moxie0: can we even get at that in the API?

from convergence.

@ewanm89, I think the API might actually do something for us here. Looks like maybe all we need to do is call SSL_GetClientAuthDataHook with a pointer to NSS_GetClientAuthData as a NULL "arg" argument, and it might just do the right thing.

from convergence.

Hmm, okay, I'm not so up on the NSS API and extensions as the python/twisted stuff. If we can it would be great but I don't hold for too much hope.

from convergence.

bump. CAcert certificate login does not work with convergence enabled. without it, it works just fine.

from convergence.

Is there a site setup where I can test client certificate functionality, other than CAcert?

from convergence.

I feel bad suggesting StartSSL.com

from convergence.

@jethrogb I actually tried that, but when I tried to create an account they flagged it for review for some reason.

from convergence.

hey, i hope this is enough for reproducing the problem: https://notary.hsbp.org/cert/index.html

from convergence.

@moxie0 https://myopenid.com/ has ssl client cert auth support.

from convergence.

Alright, client certificates now work as of 97c9d61

from convergence.