[stunnel-users] Server-side SNI support
Michal.Trojnara at mirt.net
Sat Jun 18 11:23:23 CEST 2011
Bri Hatch wrote:
> Not sure the 'right' way to handle TCP wrappers in this case - should
> tcpd checks be delayed until it is determined that sni was or wasn't
> used and then check against the actual [name] e.g. virtual vs
> sni1? Or should there be two tcpd checks, e.g. check virtual
> on accept, and then sni2 iff it turns out that's the cert they're
> I'd suggest the former method - it would allow you to have more
> open access for the sni services. In the latter method you'd need
> to have the virtual service's permissions a union (or greater)
> of the sni services.
It's an interesting problem indeed. Libwrap check is executed
*before* TLS negotiation, whereas SNI is performed not only *during*
the initial TLS handshake, but also *during* subsequent
renegotiations. It would be equally confusing to delay libwrap check
and to perform it during or after each SSL handshake.
Also some people may use libwrap to prevent DoS attacks against TLS
handshake or to mitigate the impact of potential OpenSSL
vulnerabilities. Libwrap needs to be executed before TLS handshake to
prevent attackers from interacting with OpenSSL.
On the other hand two checks may cause severe performance impact. In
fact libwrap authentication is slower than TLS handshake while being a
lot less secure.
I think I will stick with libwrap check performed before any TLS code.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 194 bytes
Desc: This is a digitally signed message part
More information about the stunnel-users