rfq: add price oracle certificate verification

[jtobin]

Adds certificate verification for TLS 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.

[coveralls]

Pull Request Test Coverage Report for Build 21747678444

Details

• 75 of 88 (85.23%) changed or added relevant lines in 5 files are covered.
• 19 unchanged lines in 4 files lost coverage.
• Overall coverage increased (+21.9%) to 56.408%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
rfq/tls.go	26	28	92.86%
tapcfg/server.go	3	6	50.0%
tapcfg/config.go	24	32	75.0%

Files with Coverage Reduction	New Missed Lines	%
address/mock.go	2	95.11%
asset/group_key.go	2	72.15%
asset/asset.go	7	80.62%
asset/mock.go	8	72.47%

Totals
Change from base Build 21716809279:	21.9%
Covered Lines:	67153
Relevant Lines:	119048

---

💛 - Coveralls

[jtobin]

(Changed this from draft; I think the litd tests are failing for an unrelated reason.)

[jtobin]

(As pointed out by @ZZiigguurraatt, to be more precise: TLS support already existed for price oracles, but certificate verification was skipped entirely.)

[ffranr]

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

	// serverDialOpts returns the set of server options needed to connect to the
	// server using a TLS connection.
	func serverDialOpts() ([]grpc.DialOption, error) {
	var opts []grpc.DialOption
	// Skip TLS certificate verification.
	tlsConfig := tls.Config{InsecureSkipVerify: true}
	transportCredentials := credentials.NewTLS(&tlsConfig)
	opts = append(opts, grpc.WithTransportCredentials(transportCredentials))
	return opts, nil
	}

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.

[jtobin]

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.

I looked into this and agree that it's probably worth centralizing our TLS handling, but I'd consider it out of scope for this change set, which does resolve a concrete issue as-is. Maybe we can open a broader "refactor TLS handling" issue for that?

I get the following hits for "crypto/tls" imports, as a rough metric:

$ ack -l "crypto/tls" --ignore-dir=itest --ignore-dir=docs
cmd/commands/conn.go
proof/courier.go
internal/test/grpc.go
universe_rpc_registrar.go
tapcfg/config.go
rfq/tls.go
authmailbox/client.go
universe/proof_download_test.go

[jtobin]

The LiT itest failure should be resolved by lightninglabs/lightning-terminal#1190.

[jtobin]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces TLS certificate verification for price oracle connections, a significant security enhancement. The changes are well-structured, with new configuration options for TLS control and the core logic neatly encapsulated in a new rfq/tls.go file, complete with thorough testing. The updates to the configuration and test files are consistent and correct. I have one minor suggestion to update a function comment to align with the new function signature, improving clarity for future developers.

[jtobin]

@GeorgeTsagk @ffranr this one should be good for {re-}review whenever.

[lightninglabs-deploy]

@ffranr: review reminder
@jtobin, remember to re-request review from reviewers when ready

[ffranr]

Some trivial comments to be removed, for example:

// Construct the oracle's TLS configuration.

Otherwise, just nits. I can quickly approve from here.

[jtobin]

Note that the failing itest case passes with the changes in lightninglabs/lightning-terminal#1190.