Discuss: Certificate signed with self-signed CA.

[tomac4t]

See "Generate certificates" in https://www.chromium.org/quic/playing-with-quic and https://source.chromium.org/chromium/chromium/src/+/master:docs/linux/cert_management.md (though you don't actually need certutil for adding root CA; you can do that in the browser with GUI). #37 (comment)

I see it make possible to use a certificate signed with self-signed CA. To those who don't have a domain name, this will save them a lot of money. It can write an IP address in SSL certificate's "Common Name(CN)". Then run ./naive --listen=socks://127.0.0.1:1080 --proxy=https://aa.bb.cc.dd/.

The remain question is naive doesn't allow proxy URL contain an IP address:

naiveproxy/src/net/tools/naive/naive_proxy_bin.cc

Line 71 in f7ce953

constexpr char kDefaultHostName[] = "example";

naiveproxy/src/net/tools/naive/naive_proxy_bin.cc

Lines 331 to 341 in f7ce953

	// SNI should only contain DNS hostnames not IP addresses per RFC 6066.
	if (url.HostIsIPAddress()) {
	GURL::Replacements set_host;
	set_host.SetHostStr(kDefaultHostName);
	params->proxy_url =
	GetProxyFromURL(url_no_auth.ReplaceComponents(set_host));
	LOG(INFO) << "Using '" << kDefaultHostName << "' as the hostname for "
	<< url.host();
	params->host_resolver_rules =
	std::string("MAP ") + kDefaultHostName + " " + url.host();
	}

I don't see it is necessary to replace server_name to "example", because It shouldn't be sent server_name when you visit an IP address directly, like https://1.1.1.1/.

Another problem is missing server_name will change the ClientHello fingerprint, and make it become uncommon traffic(Hoping the Chromium will enable the DoH by default:-)):
https://tlsfingerprint.io/id/e94fcb2176c0b827
https://tlsfingerprint.io/compare/bbf04e5f1881f506/e94fcb2176c0b827

Edited: The way to workaround now is write both IP address and domain name(eg. example) in "subjectAltName(SAN)".

What do you think? @klzgrad

[klzgrad]

Have you tried anything you said here? If it does work then maybe you have a point, otherwise...

// SNI should only contain DNS hostnames not IP addresses per RFC 6066.

This comment was a summary of why it didn't work with naked ip addresses. Either this SNI rule stops proxies with naked ip addresses from working, or it was other CA base requirements that made it problematic to use naked ip addresses in certificates. I forgot which one it was and for reasons below I'm not bothered to test it.

In general using naked ip addresses and even self-signed CAs is a red flag in the PKI system because it stands out from most other certificates. I read papers and I knew the GFW is surveying circulating certificates. There is or are several 'trustworthiness' rankings of certificates, and the rankings are used to classify malwares, and of course, hidden tunnels of adversaries. The way to rank certificates is not too far from standard traffic classification, that is, feature extraction and learning. The features of a certificate is then obviously the way and parameters used to generate it. Then my opinion is that what you described (which is what I tried first; don't know if it has become working again since then) is one of the rarest way to generate certificates, as most certificates are either signed by a known CA or self-signed, and as a consequence it stands out among all certificates.

[klzgrad]

I think I wrote more here trojan-gfw/trojan#14 about the best practices wrt certificates. In short the best practice now is to use Let's Encrypt.

[klzgrad]

论文要在知网上找。除了找标题还要看通讯作者历史记录，和项目资金编号。

[klzgrad]

I removed the part you requested. It was meant to make testing easier, and testing is now possible without it.