[stunnel-users] Server-side SNI support

[Michal Trojnara]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20110618/443a9ee8/attachment.sig>