Hello! On Fri, Mar 28, 2014 at 12:51:17PM -0400, Ben Johnson wrote:
> > > On 3/28/2014 11:45 AM, Maxim Dounin wrote: > > Hello! > > > > On Fri, Mar 28, 2014 at 02:53:18PM +0000, Jonathan Matthews wrote: > > > >> On 28 March 2014 14:31, Ben Johnson <[email protected]> wrote: > >>> Is there any way to av,oid this certificate being presented, but still > >>> return the 444 response under the conditions I've described? > >> > >> I'd /suspect/ not, as the 444 response can't be "delivered" (i.e. the > >> connection closed) until sufficient information has been passed over > >> the already-SSL-secured connection. In other words, the cert *has* to > >> be used to secure the channel over which the HTTP request will be > >> made, and only after its been made can the correct server{} block be > >> chosen and the response delivered - even if the response is simply to > >> close the connection. > > > > If SNI is used, it's in theory possible to close a connection > > early (during an SSL handshake, after ClientHello but > > before sending enything). The following tickets in trac are > > related: > > > > http://trac.nginx.org/nginx/ticket/195 > > http://trac.nginx.org/nginx/ticket/214 > > > > Thanks for the input, Jonathan and Maxim. > > Maxim, when you say, "If SNI is used, it's in theory possible to close a > connection early," do you mean to imply that while possible, this > capability has not yet been implemented in nginx (the tickets are still > open after almost two years)? Nobody care enough to submit a patch. Likely due to the fact that SNI isn't considered to be an option for serious SSL-enabled sites anyway due to still limited client-side support, see here for details: http://en.wikipedia.org/wiki/Server_Name_Indication#Client_side -- Maxim Dounin http://nginx.org/ _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
