This gives literally zero control over the TLS side of things: no way to specify what options you want to support, what versions you want to support, or what cipher suites you want to support.
The argument is that this is because it's 'too complicated'.
The problem is, that then means you're completely relying on the developer(s) of TLSproxy to know what is considered a secure setup, and to keep it updated.
I'm very well aware of the restrictions of TLSproxy, but there are 2 kinds of people: those who take the time to setup TLS properly and know how, and those who just skip TLS.
As the author of sslping.com, so I know very well that most TLS installations are not well configured. Of 6600+ servers monitored by sslping, only HALF are ok.
So yes, you can configure TLS on your webserver, handle your certificates, renew them on time, and if you know how to do it properly, then perfect.
Or there's TLSproxy if your can't spend the time, or just don't know how.
Shouldn't a "no knobs" tls proxy do forward secrecy and ocsp stapling?
Shouldn't it also not use weak ciphers?
This was my whole point: it's advertised as being easier than configuring an existing tls web server or proxy, but it means you get a less secure tls endpoint than you'd have if you literally copy and pasted the config from Mozilla's recommended tls settings tool.
If copy and pasting a config file is too hard for someone, maybe that's a sign they shouldnt be trying to configure their own server.
OCSP stapling isn't supported yet by Go as far as I can tell, but I'll implement PROXY for HTTP proxying (not for TCP proxying of course)...
And yes, it's using SNI which is now largely supported, but I think I can add an option to restrict it to as single TLS certificate (and make it work without SNI).
The original use-case is a friend with 2500 websites hosted on a single server, and he wants to make the switch to TLS ;-) but I'll try to make it work for everyone!
Re: SNI I meant the ACME challenge mode to issue the LE cert: given that it only listens on :443 i assumed it must use the tls-sni based challenge, rather than the http based challenge?
I'd never heard of it actually, I just knew about X-Forwarded-For for HTTP but I didn't know of a TCP compatible protocol.
I've read the RFC, it's easy enough to implement the v1, I'll do it... If you're willing to test it with me, please email me chris [à] chris-hartwig.com
The argument is that this is because it's 'too complicated'.
The problem is, that then means you're completely relying on the developer(s) of TLSproxy to know what is considered a secure setup, and to keep it updated.
If you decide you want to make a change (e.g based on recommendations on https://mozilla.github.io/server-side-tls/ssl-config-generat... or results from https://www.ssllabs.com/ssltest, you're shit out of luck.