rfq: add tls support for price oracles #1775
Conversation
Introduces rfq/tls.go, which contains a basic TLSConfig type and default value of such. The default value, which for now only indicates that certificate verification should be skipped, is used in place of the 'dialInsecure' bool when setting up the price oracle RPC.
jtobin
added
security
mainnet preparedness
Pull Request Test Coverage Report for Build 17361316751Details
💛 - Coveralls |
Adds both 'TrustSystemRootCAs' and 'CustomCertificates' to the rfq TLSConfig. The former indicates whether or not to trust the operating system's root CA list; the latter allows additional certificates (CA or self-signed) to be trusted. Also adds a basic unit test skeleton.
We don't skip certificate verification by default, and also default to trusting the operating system's root CA list.
Adds some basic test cases for configuring transport credentials.
Ensures that certificate verification is skipped when constructing a communication channel with the itest oracle harness.
Ensures the price oracle TLS toggle fits the existing pattern of flags defaulting to false.
|
(Changed this from draft; I think the litd tests are failing for an unrelated reason.) |
|
(As pointed out by @ZZiigguurraatt, to be more precise: TLS support already existed for price oracles, but certificate verification was skipped entirely.) |
|
|
||
| PriceOracleTLSInsecure bool `long:"priceoracletlsinsecure" description:"Disable price oracle certificate verification."` | ||
|
|
||
| PriceOracleTLSNoSystemCAs bool `long:"priceoracletlsnosystemcas" description:"Disable use of the operating system's list of root CA's when verifiying price oracle certificates."` |
There was a problem hiding this comment.
typo: s/verifiying/verifying
There was a problem hiding this comment.
There are other cases where we need more precise control over TLS behavior. For example:
taproot-assets/proof/courier.go
Lines 309 to 320 in a17a67a
With that in mind, I wonder if we could define a more general, reusable solution in something like the new rfq/tls.go file, especially given the need for configuration and the importance of which package owns this logic.
| name: "invalid custom certificate", | ||
| expectInsecure: false, | ||
| tlsConfig: &TLSConfig{ | ||
| Enabled: true, | ||
| InsecureSkipVerify: false, | ||
| TrustSystemRootCAs: false, | ||
| CustomCertificates: []byte(invalidCertificate), | ||
| }, | ||
| }, |
There was a problem hiding this comment.
I'm not sure I see the purpose of invalidCertificate here. It doesn't look like the test actually exercises its invalidity.
More broadly, do we need certificate examples in our unit tests at all? It seems like we're testing the behavior of the underlying TLS/certificate library rather than the logic we're adding on top of it.
|
@jtobin, remember to re-request review from reviewers when ready |
(Draft, for now, as the test suite still needs a little work.)
Adds TLS support for communication with price oracles, mostly following the suggestions proposed in #1278. Adds configuration options for skipping certificate verification, distrusting the operating system's root CA list, and using a custom certificate.
Resolves #1278.