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
11 comments
[ 3.5 ms ] story [ 30.3 ms ] threadThe 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.
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 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.
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).
Any chance of supporting ocsp stapling and PROXY protocol?
Presumably it uses the tls-sni challenge for LE certs?
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?
Yes, it's using the TLS-SNI challenge (through golang's autocert)
Introduced 7 years ago is "very new"?
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
https://tlsproxy.com/new-proxy-support/
Please tell me how it works for you if you try it!