Discuss: Certificate signed with self-signed CA. about naiveproxy HOT 4 CLOSED

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

from naiveproxy.

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.

from naiveproxy.

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.

from naiveproxy.

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

from naiveproxy.