Components using X.509 certificates need to do CN name verification

I think it would be good to discuss this in more detail. What was mentioned by Yu is actually not allowed based on the x.509 RFC. Also, the current XDCR code looks like it is vulnerable to man-in-the middle attacks because we don’t do any ip address checking in the case that there is an ip address in the common name of the certificate.

Below is an example of an issue (separate from above) we can run into by using a certificate with an IP address in the common name.

http://www.westpoint.ltd.uk/advisories/wp-10-0001.txt
https://tools.ietf.org/html/rfc2818

One thing from the articles above that I’m not certain of yet is if a full ip address (no wildcards) would technically be ok to match with. I feel like it would be, but I think we’re better off following the RFC if that’s really not allowed.

Another thing I was looking into is whether or not it is common practice to create certificates where ip addresses are the primary why of doing name matching and it doesn’t look like that is the case. As a result I think the best thing for us to do might be to gear our documentation towards adding hostnames to all server nodes before setting up x.509. This is probably something that people do before going into production anyways.

Please let me know your thoughts since I’m sure there are some integration issues I’m missing here that might shed more light on why we have done things the way we have done. I know XDCR in particular is tricky with hostname/ip addresses. Especially in AWS deployments.

• Mike

From: Yu Sui <yu@couchbase.com>
Date: Thursday, April 14, 2016 at 4:14 PM
To: Mike Wiederhold <mike@couchbase.com>, Don Pinto <Don@couchbase.com>, Johan Larson <Johan.Larson@couchbase.com>
Cc: Artem Stemkovski <Artem@couchbase.com>, Ritam Sharma <ritam@couchbase.com>
Subject: Re: OpenSSL X.509 verification in GO

I suppose. There is not much we can do with clusters with older versions, though.

Thanks,
Yu

From: Mike Wiederhold <mike@couchbase.com>
Date: Thursday, April 14, 2016 at 4:11 PM
To: Yu Sui <yu@couchbase.com>, Don Pinto <Don@couchbase.com>, Johan Larson <Johan.Larson@couchbase.com>
Cc: Artem Stemkovski <Artem@couchbase.com>, Ritam Sharma <ritam@couchbase.com>
Subject: Re: OpenSSL X.509 verification in GO

I understand that, but my question is does this cause a security vulnerability by not doing that validation?

• Mike

From: Yu Sui <yu@couchbase.com>
Date: Thursday, April 14, 2016 at 4:08 PM
To: Mike Wiederhold <mike@couchbase.com>, Don Pinto <Don@couchbase.com>, Johan Larson <Johan.Larson@couchbase.com>
Cc: Artem Stemkovski <Artem@couchbase.com>, Ritam Sharma <ritam@couchbase.com>
Subject: Re: OpenSSL X.509 verification in GO

If I remember correctly, when golang sets up TLS connections, the default verification options includes the check for DNS name. This causes problems when couchbase certificates do not contain IP SAN. XDCR had to overwrite the default verification options to skip the check on DNS name in such cases.

Thanks,
Yu

From: Mike Wiederhold <mike@couchbase.com>
Date: Thursday, April 14, 2016 at 4:03 PM
To: Yu Sui <yu@couchbase.com>, Don Pinto <Don@couchbase.com>, Johan Larson <Johan.Larson@couchbase.com>
Cc: Artem Stemkovski <Artem@couchbase.com>, Ritam Sharma <ritam@couchbase.com>
Subject: Re: OpenSSL X.509 verification in GO

Yu,

Can you explain why golang enforces this? I understand XDCR doing this for backward compatibility, but if there is a good reason for people to provide a SAN field then we should require it.

• Mike

From: Yu Sui <yu@couchbase.com>
Date: Thursday, April 14, 2016 at 4:01 PM
To: Don Pinto <Don@couchbase.com>, Johan Larson <Johan.Larson@couchbase.com>
Cc: Mike Wiederhold <mike@couchbase.com>, Artem Stemkovski <Artem@couchbase.com>, Ritam Sharma <ritam@couchbase.com>
Subject: Re: OpenSSL X.509 verification in GO

The latter. There was an issue that Couchbase certificates may not have IP SANS. XDCR had to call the Verify() method that golang provides explicitly instead of calling the higher level Dial() method when setting up TLS connections.

Thanks,
Yu

From: Don Pinto <Don@couchbase.com>
Date: Thursday, April 14, 2016 at 3:52 PM
To: Yu Sui <yu@couchbase.com>, Johan Larson <Johan.Larson@couchbase.com>
Cc: Mike Wiederhold <mike@couchbase.com>, Artem Stemkovski <Artem@couchbase.com>, Ritam Sharma <ritam@couchbase.com>
Subject: Re: OpenSSL X.509 verification in GO

Does this just mean checking expiry date, or also calling openssl verify equivalent (walking up the cert chain)?

Thanks,
Don Pinto
Product Management

647.839.7876

From: Yu Sui <yu@couchbase.com>
Date: Thursday, April 14, 2016 at 6:51 PM
To: Don Pinto <don@couchbase.com>, Johan Larson <Johan.Larson@couchbase.com>
Cc: Mike Wiederhold <mike@couchbase.com>, Artem Stemkovski <Artem@couchbase.com>, Ritam Sharma <ritam@couchbase.com>
Subject: Re: OpenSSL X.509 verification in GO

Yes, XDCR is verifying that the certificates are valid.

Thanks,
Yu

From: Don Pinto <Don@couchbase.com>
Date: Thursday, April 14, 2016 at 3:42 PM
To: Yu Sui <yu@couchbase.com>, Johan Larson <Johan.Larson@couchbase.com>
Cc: Mike Wiederhold <mike@couchbase.com>, Artem Stemkovski <Artem@couchbase.com>, Ritam Sharma <ritam@couchbase.com>
Subject: OpenSSL X.509 verification in GO

Hi Folks,

Mike was investigating a bit more about X.509 certificates in Couchbase, and I believe for xdcr, and query engine, your components might have done the verification of the X.509 certificates in GO.

Can you confirm that that XDCR, and query engine are indeed verifying these certificates?

Thanks,
Don Pinto
Product Management

647.839.7876