TLS Certificate verification about coyim HOT 26 CLOSED

That would be pretty cool since when trying to connect to jabber.ccc.de coy tells me:

>>> ALERT xmpp: failed to verify TLS certificate: x509: certificate signed by unknown authority (possibly because of "x509: cannot verify signature: algorithm unimplemented" while trying to verify candidate authority certificate "CA Cert Signing Authority")

from coyim.

but it seems to be a 'algorithm unimplemented' according to this log

from coyim.

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID:
    Session-ID-ctx:
    Master-Key: D0B089671C98489448420926883A752770E61A64360241E76EF1392BDE1AD161E8755D829F6B7E527C098E5C41D87DC0
    Key-Arg   : None
    Start Time: 1451946131
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)

golang/go#7758

from coyim.

The "x509: cannot verify signature: algorithm unimplemented" error comes from the crypto/x509 package and has nothing to do with the TLS ciphersuites. The problem here is really the missing CA Cert root certificate needed to verify the jabber.ccc.de certificate.

xmpp-client contains some hard-coded logic for this actually, so it is possible to connect to jabber.ccc.de (for example using the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ciphersuite supported both by Go's tls package and by jabber.ccc.de)

from coyim.

@sycamoreone FYI, coy has the same code: https://github.com/twstrike/coyim/blob/master/config/certs.go#L165

which is used by the connection policy: https://github.com/twstrike/coyim/blob/master/config/connection_policy.go#L85

Unless the error message reported by @jubalh (which is the error returned by https://golang.org/pkg/crypto/x509/#Certificate.Verify) is very misleading, I would also suspect the problem is the x509: cannot verify signature: algorithm unimplemented.

Do you have any additional debug information?

from coyim.

@sycamoreone
Thanks for infomation, I tried on my xmpp-client without system trusting this cacert root class 1 PKI. It's still showing an error

 * (10:50AM) Temporarily trusting only CACert root for CCC Jabber server
 * (10:50AM) Making connection to okj7xc6j2szr2y75.onion:5222 via proxy
 * (10:50AM) Starting TLS handshake
 * (10:50AM)   SSL/TLS version: TLS 1.2
 * (10:50AM)   Cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 * (10:50AM) Failed to connect to XMPP server: xmpp: failed to verify TLS certificate: x509: certificate signed by unknown authority (possibly because of "x509: cannot verify signature: algorithm unimplemented" while trying to verify candidate authority certificate "CA Cert Signing Authority")

from coyim.

But anyway manually trusting a cert is still a good feature we should support,

For the ciphersuite should we create another issue?

from coyim.

The following two lines are not working actually, if I use mac keychain to trust, this problem is solved,
@jubalh can you please provide some more info about your system and RootCA trusts?
I guess it's also a bug of xmpp-client.

roots.AddCert(caCertRoot)
xmppConfig.TLSConfig.RootCAs = roots

from coyim.

This is also a bug in xmpp-client and the problem really is a "missing" algorithm in the x509 package. If one compiles with a recent Go with this patch golang/go@606d9a7, one gets this error message instead:

xmpp: failed to verify TLS certificate: x509: certificate signed by unknown authority (possibly because of "x509: cannot verify signature: insecure algorithm MD5-RSA" while trying to verify candidate authority certificate "CA Cert Signing Authority")

from coyim.

Just checked: The hardcoded root certificate really uses the MD5WithRSA as SignatureAlgorithm.

from coyim.

@sycamoreone

Things are bit of complicated now,
xmpp-client is having a bug for this, but the ciphersuit is not the problem here (saying: jabber.ccc.de).

I made a fix for both xmpp-client and coyim.

But yes, if the algorithm of server only support DHE and MD5WithRSA, it's still a problem.

from coyim.

What's the status on this one?

from coyim.

Manually trusting a ca is not done, we just fixed the ccc.de hard coded part.

from coyim.

OK, but is there an actual problem with algorithms here?

from coyim.

If the server only supports MD5WithRSA, algorithms is still a problem.

from coyim.

And the problem is the Go support, that doesn't support that algorithm? Or is it because we manually restrict the available ciphers?

from coyim.

As @sycamoreone mentioned, golang will return error if it knows insecure algorithm like MD5. But manually trusting a cert won't have that problem I think.

from coyim.

OK, but does it do that because we are restricting the algorithms, or is it hardcoded into Golang?

from coyim.

We are restricting here. the change in golang is just to show more details rather than providing a "algorithm unimplemented"

from coyim.

But Some cases will be treated as InSecureAlgorithm by default.
eg. MD2WithRSA and MD5WithRSA
https://github.com/golang/go/blob/be7544be237b279e45be73963e84ab59916b8ac2/src/crypto/x509/x509.go#L684

from coyim.

As @sycamoreone mentioned, golang will return error if it knows insecure algorithm like MD5. But manually trusting a cert won't have that problem I think.

My analysis wasn't correct. Go indeed won't verify certificates using the MD5WithRSA algorithm used by by the CACert certificate, but this was not the problem here, because the root certificate doesn't need to be verified, so the algorithm suite used is irrelevant.

The real problem was fixed by @tcz001's patch in #41 (comment).

(All of this had nothing to do with allowing people to manually trust a cert. Sorry for having hijacked this issue.)

from coyim.

This issue is about the server's leaf certificate. The idea here is to notify the user when some problem happens with the certificate, interrupt the connection, ask for an action, and then reconnect if necessary.

Which actions make sense?

1. Trust the certificate temporarily and connect.
2. Trust the certificate permanently for this account and connect.
3. Don't connect.

(1) requires allowing ConnectionPolicy to create an xmpp.Config with a temporary ServerCertificateSHA256 property rather than loading it from config.Account#ServerCertificateSHA256, and then reconnect using this new ConnectionPolicy.

(2) requires setting config.Account#ServerCertificateSHA256 to the target certificate SHA256 hash, and saving the config. After this simply reconnect.

(3) should require no significant change.

from coyim.

I think all three should be valid ones. I also know there are situations where more than one certificate is valid - so we might want to move to a list of certificate hashes.

from coyim.

If we stop connection and ask the user to decide which path to follow aren't we assuming the user is making an informed decision? I'm not sure this would be a correct assumption and would actually be prone to believe the user is just trying to get CoyIM out of the way.

A secure default here, I guess, would be to do not connect and issue the warning. Then, the user would need to enable connection for that server (temporary or permanent) manually.

from coyim.

I think we will ignore the parent cert for now.

from coyim.

I think we will ignore the parent cert for now.

from coyim.