Don't know, that would be a Robert question... But it seems to be pretty low risk.
------ Joe -----Original Message----- From: gojrzan <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Monday, May 2, 2016 at 5:57 PM To: "[email protected]" <[email protected]> Subject: Re: [Pound Mailing List] SNI enabled HTTPS backend >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 :)
