1. The Snowden leaks and the whole "SSL added and removed here" issue,
for example. TLS on internal networks is more important these days due
to local network implants and other security issues on LANs.
2. Our use case is actually DigitalOcean where there is "private
networking" but it is shared among many customers. Operating without TLS
on this semi-private network would be unwise.
3. Most of the public tutorials for re-encrypt bridged TLS are simply
incurring TLS overhead while providing no TLS security. (eg SSL on but,
verify none enabled, verifyhost not set, etc)
4. Use cases like CDN proxy of public servers. Think Cloudflare's Full
SSL (Strict) setup...
--
Kevin
On 2017-05-05 7:20 PM, Igor Cicimov wrote:
On 6 May 2017 2:04 am, "Kevin McArthur" <ke...@stormtide.ca
<mailto:ke...@stormtide.ca>> wrote:
When doing tls->haproxy->tls (bridged https) re-encryption with
SNI, we need to verify the backend certificate against the SNI
value requested by the client.
Something like server options:
server app1 app1.example.ca:443 <http://app1.example.ca:443> ssl
no-sslv3 sni ssl_fc_sni verify required verifyhost ssl_fc_sni
However, the "verifyhost ssl_fc_sni" part doesn't work at current.
Is there any chance I could get this support patched in?
Most folks seem to be either ignoring the backend server
validation, setting verify none, or are stripping tls altogether
leaving a pretty big security hole.
Care to elaborate why is this a security hole if the backend servers
are in internal LAN which usually is the case when terminating ssl on
the proxy?
--
Kevin McArthur
