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 requesting.

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.

Best regards, Mike