Thanks, that cleared things up. Yes, I only had one Cert directive in my listener but only because I was using a wildcard certificate.
I've now added another Cert directive with bundled ssl-cert-snakeoil.* just to satisfy the condition without changing the code, works as expected. Any idea if and when your changes might get included in next pound release? Cheers, Grzegorz On 2016-05-02 16:58:12 Joe Gooch <[email protected]> wrote: > 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��+ ��+�笶*' -- To unsubscribe send an email with subject unsubscribe to [email protected]. Please contact [email protected] for questions.
