Re: [Pound Mailing List] SNI enabled HTTPS backend
gojrzan <[email protected]> Mon, 02 May 2016 23:57:59 +0200
| Newsgroups | gmane.comp.web.pound.general |
|---|---|
| Message-ID | <[email protected]> |
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.