This tells me you only have one Cert directive in your listener, but you're using SNI.. Is this true?
Usually the point of using SNI would be to have multiple certificates, and choose the appropriate one on each connection. Up until now there was no point in calling the callback if you only had one certificate, because there's no decision to be made. If you have only one certificate but you need SNI in the backend we'll have to run the callback even with a single certificate in the listener. If that's the case, just remove the if(res->ctx->next) line entirely. We wouldn't get this far without res->ctx->ctx being set. Joe On 5/1/16, 9:21 PM, "gojrzan" <[email protected]> wrote: >OK, I think I found it. >Condition in config.c:1427 (in your 2.8a branch) was never true. Checking for >res->ctx->ctx instead of res->ctx->next makes it work. I'm 65% confident it's >what you intended to check for as the SSL_CTX_set_tlsext_servername_callback() >uses it, but could you verify I'm not getting myself in a greater mess by >doing that? > >diff --git a/config.c b/config.c >--- a/config.c >+++ b/config.c >@@ -1424,7 +1424,7 @@ parse_HTTPS(void) > if(!has_addr || !has_port || res->ctx == NULL) > conf_err("ListenHTTPS missing Address, Port or Certificate - > aborted"); > #ifdef SSL_CTRL_SET_TLSEXT_SERVERNAME_CB >- if(res->ctx->next) >+ if(res->ctx->ctx) > if(!SSL_CTX_set_tlsext_servername_callback(res->ctx->ctx, > SNI_server_name) > || !SSL_CTX_set_tlsext_servername_arg(res->ctx->ctx, > res->ctx)) > conf_err("ListenHTTPS: can't set SNI callback"); > > >Cheers, >Grzegorz > >On 2016-04-26 15:39:45 Joe Gooch <[email protected]> wrote: >> It should be syslogged at debug level - or you can run pound in non-daemon >> mode and send stuff to stderr. >> >> That servername should be set in the SNI callback in config.c - if the host >> sends a SNI header. (around line 1092) Maybe add some LOG_DEBUG stuff or >> LOG_INFO to verify 1) we're receiving a header and 2) it's writing into >> ssl_request... >> >> >> ------ >> >> Joe >> >> >> >> >> >> >> On 4/25/16, 8:49 PM, "gojrzan" <[email protected]> wrote: >> >> >Thanks for your links. I've tried both 2.8a SNIPassthrough branch and >> >applying the patch to 2.7, they do compile fine, but I'm still getting that >> >BIO_do_handshake error. >> > >> >Some poor man's debugging suggests this condition is not true in my case: >> >http.c:931 if (ssl_request.servername[0]) { >> > >> >I tried adding SSL_set_tlsext_host_name function with my servername >> >hardcoded to http.c to confirm pound works with my backend if SNI header is >> >set and it does, so we are on the right track. >> > >> >P.S. >> >Where do all debug messages created by logmsg(LOG_DEBUG, ...) go to? I >> >already redirected all pound logs to its own file in rsyslog template and >> >raised LogLevel in pound config file to 5 (it's not really related to unix >> >loglevels, is it?) but still no luck. >> > >> >On 2016-04-22 12:35:53 Joe Gooch <[email protected]> wrote: >> >> I whipped up passing through SNI from the source request: >> >> >> >> Branch https://github.com/goochjj/pound/tree/SNIPassthrough >> >> Patch >> >> https://github.com/goochjj/pound/commit/00eb996d8e832741cbcf1342e0bf77bba3f06af0.diff >> >> ZIP https://github.com/goochjj/pound/archive/SNIPassthrough.zip >> >> >> >> >> >> This is based on my stage for upstream 2.8a branch, so it does have other >> >> patches in it. The diff should apply cleanly to stock 2.7 if you want to >> >> go that way. >> >> >> >> I don't have a good way to test this, so I didn't. It compiles. So it >> >> might work for you! Let me know. >> >> >> >> Pound resurrects based on the host accepting a socket connect() call - no >> >> SSL handshake is attempted. Anything beyond that would require a custom >> >> host check script. >> >> >> >> Joe >> >> >> >> >> >> >> >> On 4/21/16, 1:57 AM, "gojrzan" <[email protected]> wrote: >> >> >> >> >Hi Joe, >> >> > >> >> >Thank you for your reply. >> >> > >> >> >Preserving SNI header from the original request seems like a more >> >> >suitable or cleaner way, then again if I already have 'HeadRequire >> >> >"Host: .*www.domain.com.*" line in service definition, I would be happy >> >> >with setting the server name in BackEnd definition too, if that would be >> >> >easier to implement. >> >> > >> >> >The later option might be even better in my scenario. I ran tcpdump to >> >> >see what is happening and it seems the backend host just sends TCP RST >> >> >after pound sends its first non-SNI-containing data packet. >> >> > >> >> >17:32:33.526367 IP 192.168.11.21.41841 > 192.168.33.10.443: Flags [S], >> >> >seq 2237443044, win 29200, options [mss 1460,sackOK,TS val 823584186 ecr >> >> >0,nop,wscale 7], length 0 >> >> >17:32:33.526754 IP 192.168.33.10.443 > 192.168.11.21.41841: Flags [S.], >> >> >seq 2348622935, ack 2237443045, win 8192, options [mss 1460,nop,wscale >> >> >8,sackOK,TS val 61109578 ecr 823584186], length 0 >> >> >17:32:33.526799 IP 192.168.11.21.41841 > 192.168.33.10.443: Flags [.], >> >> >ack 1, win 229, options [nop,nop,TS val 823584186 ecr 61109578], length 0 >> >> >17:32:33.526903 IP 192.168.11.21.41841 > 192.168.33.10.443: Flags [P.], >> >> >seq 1:296, ack 1, win 229, options [nop,nop,TS val 823584186 ecr >> >> >61109578], length 295 >> >> >17:32:33.527146 IP 192.168.33.10.443 > 192.168.11.21.41841: Flags [R.], >> >> >seq 1, ack 296, win 0, length 0 >> >> > >> >> >I don't know how pound discovers resurected hosts, if it only needs to >> >> >check if the port is opened it would just work, but if it relies on >> >> >getting a positive HTTP response, doing that without knowing servername >> >> >(when there was no client to pass SNI header from) might just fail even >> >> >if the back end host becomes available. >> >> > >> >> >Cheers, >> >> >Grzegorz >> >> > >> >> >On 2016-04-20 16:10:48 Joe Gooch <[email protected]> wrote: >> >> >> Pound does not pass through the received SNI header to the backend, so >> >> >> requests initiated via HTTPS to backends will not contain the SNI >> >> >> header. (Nor does the Host header influence it at all) >> >> >> >> >> >> It's possible to modify pound to do so, it just doesn't at the moment. >> >> >> And how would that work for you? Would you want it to preserve the >> >> >> SNI header from the original request, or specify a hostname via a >> >> >> "ServerName" option in the Backend block? (i.e. Analogous to >> >> >> -servername in s_client) >> >> >> >> >> >> -G >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 4/20/16, 1:51 AM, "gojrzan" <[email protected]> wrote: >> >> >> >> >> >> >Hi, >> >> >> > >> >> >> >tl;dr: Does pound support SNI-enabled HTTPS backends? >> >> >> > >> >> >> > >> >> >> >I have pound working fine terminating HTTPS and passing it to HTTP >> >> >> >backends, but I need to add another service which uses HTTPS on its >> >> >> >own. So I've added: >> >> >> > >> >> >> >ListenHTTPS >> >> >> > HeadRemove "X-Forwarded-Proto" >> >> >> > HeadRemove "X-Forwarded-For" >> >> >> > AddHeader "X-Forwarded-Proto: https" >> >> >> > Cert "/etc/ssl/private/wildcard-keycert_bundle.pem" >> >> >> > Address 192.168.11.10 >> >> >> > Port 443 >> >> >> > >> >> >> > Service >> >> >> > HeadRequire "Host: .*www.domain.com.*" >> >> >> > >> >> >> > BackEnd >> >> >> > Address 192.168.33.9 >> >> >> > Port 443 >> >> >> > HTTPS >> >> >> > End >> >> >> > >> >> >> > BackEnd >> >> >> > Address 192.168.33.10 >> >> >> > Port 443 >> >> >> > HTTPS >> >> >> > End >> >> >> > >> >> >> > End >> >> >> >End >> >> >> > >> >> >> >But the browser only gets 'The service is not available. Please try >> >> >> >again later.' while syslog on pound host only logs: >> >> >> > >> >> >> >pound: BIO_do_handshake with 192.168.33.10:443 failed: >> >> >> >error:00000000:lib(0):func(0):reason(0) >> >> >> > >> >> >> > >> >> >> >The BackEnd is Microsoft's Web Application Proxy which I don't have >> >> >> >direct access to, so can't check its running config nor logs, but I >> >> >> >think its SNI-enabled because: >> >> >> > >> >> >> >If I curl it using it's name I get what I expect, when I only use its >> >> >> >IP: >> >> >> >curl -kiv https://192.168.33.10 >> >> >> >* Rebuilt URL to: https://192.168.33.10/ >> >> >> >* Hostname was NOT found in DNS cache >> >> >> >* Trying 192.168.33.10... >> >> >> >* Connected to 192.168.33.10 (192.168.33.10) port 443 (#0) >> >> >> >* successfully set certificate verify locations: >> >> >> >* CAfile: none >> >> >> > CApath: /etc/ssl/certs >> >> >> >* SSLv3, TLS handshake, Client hello (1): >> >> >> >* Unknown SSL protocol error in connection to 192.168.33.10:443 >> >> >> >* Closing connection 0 >> >> >> >curl: (35) Unknown SSL protocol error in connection to >> >> >> >192.168.33.10:443 >> >> >> > >> >> >> > >> >> >> >same goes for when using openssl s_client without -servername param >> >> >> >set: >> >> >> > >> >> >> >openssl s_client -connect 192.168.33.10:443 >> >> >> >CONNECTED(00000003) >> >> >> >write:errno=104 >> >> >> >--- >> >> >> >no peer certificate available >> >> >> >--- >> >> >> >No client certificate CA names sent >> >> >> >--- >> >> >> >SSL handshake has read 0 bytes and written 295 bytes >> >> >> >--- >> >> >> >New, (NONE), Cipher is (NONE) >> >> >> >Secure Renegotiation IS NOT supported >> >> >> >Compression: NONE >> >> >> >Expansion: NONE >> >> >> >--- >> >> >> > >> >> >> >while with proper name s_client connects and certs get verified >> >> >> >correctly. >> >> >> > >> >> >> > >> >> >> >Does anyone use pound with SNI backends? >> >> >> >If it's not supported yet, is it on the roadmap? >> >> >> > >> >> >> >It seems my only option is to reconfigure WAP so it serves the site >> >> >> >I'm interested in to be the default when SNI is not presented. >> >> >> > >> >> >> >Thanks >> >> >> >Grzegorz >> >> >> > >> >> >> >P.S >> >> >> >It's my first post on this mailing list so please be gentle :) >> >> >> > >> >> >> >-- >> >> >> >To unsubscribe send an email with subject unsubscribe to >> >> >> >[email protected]. >> >> >> >Please contact [email protected] for questions. >> >> >> N�����r��zǧu�ޙ���+a���y�n�˛���m�h���u�l��!>W���(�֜��,z?��+?��+�笶*' >> >> > >> >> > >> >> > >> >> > >> >> >-- >> >> >To unsubscribe send an email with subject unsubscribe to [email protected]. >> >> >Please contact [email protected] for questions. >> >> N�����r��zǧu�ޙ���+a���y�n�˛���m�h���u�l��!>W���(�֜��,z?��+?��+�笶*' >> > >> > >> > >> > >> >-- >> >To unsubscribe send an email with subject unsubscribe to [email protected]. >> >Please contact [email protected] for questions. >> N�����r��zǧu�ޙ���+a���y�n�˛���m�h���u�l��!>W���(�֜��,z?��+?��+�笶*' > > > > >-- >To unsubscribe send an email with subject unsubscribe to [email protected]. >Please contact [email protected] for questions. N�����r��zǧu�ޙ���+a���y�n�˛���m�h���u�l��!>W���(�֜��,z��+ ��+�笶*'
