code review on TLS wrapper

<p><a href="https://github.com/aubble/goTunneLS" rel="nofollow">https://github.com/aubble/goTunneLS</a></p> <p>Hello I posted earlier for code review on my repos except I wasn&#39;t very specific, however this time it&#39;s just this one little project, a TLS wrapper in go, basically a stunnel clone. It allows you take applications not programmed to use TLS and wrap them in it. It takes a json config file for the various ports you want forwarded over TLS through goTunneLS to another goTunneLS (could be any wrapper that doesn&#39;t have its own protocol, just uses standard TLS) instance which then routes them to their final location. I&#39;d really appreciate if someone could look this over and check if I did everything right. If there are any vulnerabilities or nooby mistakes etc, specifically my use of TLS. Thanks in advance!!! </p> <hr/>**评论：**<br/><br/>joushou: <pre><p>First of all, a disclaimer: You asked for a review, so a review is what you&#39;re getting! Don&#39;t take anything as insults, or as me looking down on your code; it is merely constructive criticism.</p> <ol> <li><p>Write a description in the README. That&#39;s very important, so that people seeing the project will know what to do with it. It also helps exposure, as it increases the chance of being found by Google searches.</p></li> <li><p>Your socket seems to have turned into a class with your application logic, although it seems to also be your configuration object. I would heavily suggest splitting server and client, with your server logic most likely residing directly in main() (It&#39;s just a loop calling Accept()), and having your configuration completely separate. In case of multiple servers running, make it a function that takes the required function as arguments (certPool, []tls.Certificates, listening address and connection address). There is nothing here that seems to require any state, so it&#39;s free functions all the way.</p></li> <li><p>getCertArray doesn&#39;t do anything specific to the socket, so don&#39;t make it take a socket as a receiver. It&#39;s just a free function!</p></li> <li><p>Related to 3, I would suggest parsing the certs before giving them to any handler - that abstracts the format away, leaving the config handler to figure out how to parse things, as long as it spits out a []tls.Certificate.</p></li> <li><p>Close the net.Conn&#39;s when you&#39;re done with them. In this case, you can cheat a bit and just not not &#34;go&#34; one of the io.Copy&#39;s, and then defer the Close of both the incoming and outgoing net.Conns.</p></li> <li><p>You just try again in case of errors? That&#39;s a good way to burn CPU cycles if the configuration is broken. Print them and exit!</p></li> <li><p>The names &#34;server&#34; and &#34;client&#34; doesn&#39;t seem particularly descriptive when both are actually proxies. One is &#34;unwrapped-to-TLS&#34; and the other is &#34;TLS-to-unwrapped&#34;. Those are of course terrible names, but try to think of something more descriptive. You can submit for another review which focuses more on the application logic itself once some of those have been taken care of.</p></li> <li><p>Defaulting to &#34;aubble.com&#34; doesn&#39;t seem like a particularly sane default!</p></li> </ol> <p>Once some of those have been fixed, we can take a look at a re-review at more application-logic specific parts.</p></pre>nhooyr: <pre><p>thank you very much. time to fix it up.</p></pre>