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.
