
Show HN: TLSproxy – automatic Let's Encrypt proxy - weddpros
https://github.com/chrisDeFouRire/tlsproxy
======
stephenr
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.

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...](https://mozilla.github.io/server-side-tls/ssl-config-generator/)
or results from
[https://www.ssllabs.com/ssltest](https://www.ssllabs.com/ssltest), you're
shit out of luck.

~~~
weddpros
..author here...

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.

~~~
stephenr
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.

~~~
weddpros
forward secrecy: fixed cipher order

weak ciphers: 3DES is not weak only a bit less strong, fixed anyway

I'm still working on making TLSproxy better. A little encouragement will help
;-)

Now 'A' with SSLLabs, with 0 configuration, which is WAY better than the vast
majority of TLS servers out there (people don't take the time).

~~~
stephenr
Great work.

Any chance of supporting ocsp stapling and PROXY protocol?

Presumably it uses the tls-sni challenge for LE certs?

~~~
weddpros
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!

~~~
stephenr
I see.

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?

~~~
weddpros
By proxy, do you mean [https://www.haproxy.org/download/1.8/doc/proxy-
protocol.txt](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) ?
this looks very new... (I thought you were talking about X-Forwarded-For)

Yes, it's using the TLS-SNI challenge (through golang's autocert)

~~~
stephenr
Yes that's what I meant by PROXY protocol support.

Introduced 7 years ago is "very new"?

~~~
weddpros
I must have read a bit too fast...

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

