Re: [squid-users] SSL Accel - Reverse Proxy
On Fri, May 2, 2008 at 6:17 PM, Henrik Nordstrom [EMAIL PROTECTED] wrote: On ons, 2008-04-30 at 11:10 -0700, Tory M Blue wrote: I was wondering if there was a way for Squid to pass on some basic information to the server citing that the original request was Secure, so that the backend server will respond correctly. Yes. See the front-end-https cache_peer option. Thanks Henrik Either I have this implemented wrong (more likely). Or the directive is not quite right. I seem to see this header: Front-End-Https: On:, If I hit the page via port 80 or port 443, this in itself tells me that I've misunderstood and botched the config, or this is not quite working correctly (betting against me, vs the feature).. Here is the pertinent configuration, As I stated above if i hit any of the domains on port 80 (http://blah) or on port 443 (https://blah), I see the header, which I should not see if I hit the page on port 80. Thanks Tory http_port 80 accel vhost http_port 199 accel vhost http_port 360 accel vhost cache_peer 10.40.5.229 parent 80 0 no-query originserver front-end-https cache_peer 10.40.5.152 parent 80 0 no-query originserver front-end-https cache_peer 10.40.5.231 parent 80 0 no-query originserver front-end-https cache_peer_domain 10.40.5.229 !submit-dev.eng.domain.com cache_peer_domain 10.40.5.229 !admanager-dev.eng.domain.com cache_peer_domain 10.40.5.152 !apps-dev.eng.domain.com cache_peer_domain 10.40.5.152 !dev-cache.eng.domain.com cache_peer_domain 10.40.5.152 !devcache01.eng.domain.com cache_peer_domain 10.40.5.152 !admanager-dev.eng.domain.com cache_peer_domain 10.40.5.231 !submit-dev.eng.domain.com cache_peer_domain 10.40.5.231 !apps-dev.eng.domain.com cache_peer_domain 10.40.5.231 !dev-cache.eng.domain.com cache_peer_domain 10.40.5.231 !devcache01.eng.domain.com ##SSL DIRECTIVES## https_port 443 accel cert=/etc/squid/wildcard.eng.domain.com.pem vhost https_port 444 accel cert=/etc/squid/wildcard.domain.com.pem vhost
Re: [squid-users] SSL Accel - Reverse Proxy
On Mon, May 5, 2008 at 9:23 AM, Tory M Blue [EMAIL PROTECTED] wrote: On Fri, May 2, 2008 at 6:17 PM, Henrik Nordstrom [EMAIL PROTECTED] wrote: On ons, 2008-04-30 at 11:10 -0700, Tory M Blue wrote: I was wondering if there was a way for Squid to pass on some basic information to the server citing that the original request was Secure, so that the backend server will respond correctly. Yes. See the front-end-https cache_peer option. Thanks Henrik Either I have this implemented wrong (more likely). Or the directive is not quite right. Found it, not quite clear in the documentation but I read the description again. If set to auto, so there are actually options , so I set it to =auto and that works! Thanks Tory
Re: [squid-users] SSL Accel - Reverse Proxy
On mån, 2008-05-05 at 09:23 -0700, Tory M Blue wrote: Either I have this implemented wrong (more likely). Or the directive is not quite right. Quote from the documentation: front-end-https[=on|auto] use front-end-https to enable the Front-End-Https: On header needed when using Squid as a SSL frontend in front of Microsoft OWA. See MS KB document Q307347 for details on this header. If set to auto the header will only be added if the request is forwarded as a https:// URL. Or in other words set it to auto and it will behave as you like it to. Regards Henrik
Re: [squid-users] SSL Accel - Reverse Proxy
The authorative documentaiton is squid.conf.default, or the copy found online on squid-cache.org. http://www.squid-cache.org/Versions/v2/2.6/cfgman/cache_peer.html Regards Henrik On mån, 2008-05-05 at 11:25 -0700, Tory M Blue wrote: visolve documentation front-end-https to enable the Front-End-Https: On header needed when using Squid as a SSL frontend infront of Microsoft OWA. See MS KB document Q307347 for details on this header. If set to auto then the header will only be added if the request is forwarded as a https://URL. So maybe the docs have been updated since, but there were no options specified in the 2.6 configuration manual from visolve Thanks for the pointer! Tory On Mon, May 5, 2008 at 11:14 AM, Henrik Nordstrom [EMAIL PROTECTED] wrote: On mån, 2008-05-05 at 09:23 -0700, Tory M Blue wrote: Either I have this implemented wrong (more likely). Or the directive is not quite right. Quote from the documentation: front-end-https[=on|auto] use front-end-https to enable the Front-End-Https: On header needed when using Squid as a SSL frontend in front of Microsoft OWA. See MS KB document Q307347 for details on this header. If set to auto the header will only be added if the request is forwarded as a https:// URL. Or in other words set it to auto and it will behave as you like it to. Regards Henrik
Re: [squid-users] SSL Accel - Reverse Proxy
Tory M Blue wrote: On Thu, May 1, 2008 at 2:02 AM, Amos Jeffries [EMAIL PROTECTED] wrote: You could make a second peer connection using HTTPS between squid and the back-end server and ACL the traffic so that only requests coming in via SSL are sent over that link. Leaving non-HTTPS incoming going over the old HTTP link fro whatever the server want to do. Thanks Amos Not sure that I made myself clear or that I understand your suggestion. You made the situation clear. I mentioned the only reasonably easy solution. If you didn't understand me, Keith M Richad provided you with the exact squid.conf settings I was talking about before. Squid can talk HTTPS to the clients, HTTPS to the web server, and still sit in the middle caching files. Exactly as it would for HTTP. All you need is SSL certificates for each side of squid. Configured as Keith gave you. I need to allow squid to connect and talk to my servers via http (only), i want squid to handle the SSL termination (SSL acceleration, take the overhead off the back end servers). However since squid talks to the back end servers via http (and not https on pages that require https), I need to somehow tell the server that the original connection, or the connection that will go back to the client will be https, even though the server is responding via http.. I handle secure and non secure fine now, the same website for example. apps.domain.com, listens to both 443 and 80, so squid can handle secure and non secure. there is code on apps.domain.com that checks the incoming protocol to verify that's it's secure, if not it sends a secure url for the client to come back in on. As you can see if I allow Squid to handle the SSL portion, the back end server has no way of knowing (the piece I'm missing) if the actual client connection is secure or not. (hard to explain possibly).. Client apps.domain.com (443) Squid - backend server (80) backend server (80) -- Squid apps.domain.com (443) -- Client (443) I'm wondering if Squid can tell the peer (server) that the original request was in fact secure, so that we can tell the application, feel free to respond with the secure data via non secure port, because squid will encrypt the server response and get back to the client via https Sorry kind of long winded. Tory -- Please use Squid 2.6.STABLE20 or 3.0.STABLE5
Re: [squid-users] SSL Accel - Reverse Proxy
On Fri, May 2, 2008 at 5:25 AM, Amos Jeffries [EMAIL PROTECTED] wrote: You made the situation clear. I mentioned the only reasonably easy solution. If you didn't understand me, Keith M Richad provided you with the exact squid.conf settings I was talking about before. Obviously i have not., and I apologize. I want Squid to handle both HTTP/HTTPS (easy, implemented working for months). I want SQUID to talk to the backend server via HTTP.. period, (EASY) I want SQUID to handle the https encryption/description and talk to the origin server via http . (EASY) I want Squid to somehow inform the origin that the original request was in fact HTTPS (HOW, is the question at hand) I can do SSL and pass it and have squid handle the SSL without issue., the issue is allowing the origin insight as to the originating protocol, if squid accepts the client connection on 443 and sends the request to the origin on port 80 The issue is that I don't want my backend server to have to deal with ssl at all. But I have some applications that require the request be https (secured pages), So if Squid could pass something in the header citing that the original request was made via https, than my code could take that information, and know that sending secured data via non secure method is okay, since Squid will encrypt the data and send to the client before that data leaves my network. I had similar questions with squid sending the original http version information in a header, which it does. Now I'm wondering if squid keeps track of the original requesting protocol, so that my application can look at the header and decide if the original request came in as https (Since the origin at this point believes not, since squid is talking to the origin via http and talking to the client via https.) Sorry that I seem to be making this complicated, it totally makes sense in my head (: ) Tory I'm not sure how to be clearer and would be happy to email directly with someone , aim, or phone
RE: [squid-users] SSL Accel - Reverse Proxy
Tory, If you are going to use Certificates from a provider like Verisign or similar, and will be using an Intermediate cert, will need to chain them together as to avoid errors from EU web browsers. Keith -Original Message- From: Amos Jeffries [mailto:[EMAIL PROTECTED] Sent: Friday, May 02, 2008 7:26 AM To: Tory M Blue Cc: squid-users@squid-cache.org Subject: Re: [squid-users] SSL Accel - Reverse Proxy Tory M Blue wrote: On Thu, May 1, 2008 at 2:02 AM, Amos Jeffries [EMAIL PROTECTED] wrote: You could make a second peer connection using HTTPS between squid and the back-end server and ACL the traffic so that only requests coming in via SSL are sent over that link. Leaving non-HTTPS incoming going over the old HTTP link fro whatever the server want to do. Thanks Amos Not sure that I made myself clear or that I understand your suggestion. You made the situation clear. I mentioned the only reasonably easy solution. If you didn't understand me, Keith M Richad provided you with the exact squid.conf settings I was talking about before. Squid can talk HTTPS to the clients, HTTPS to the web server, and still sit in the middle caching files. Exactly as it would for HTTP. All you need is SSL certificates for each side of squid. Configured as Keith gave you. I need to allow squid to connect and talk to my servers via http (only), i want squid to handle the SSL termination (SSL acceleration, take the overhead off the back end servers). However since squid talks to the back end servers via http (and not https on pages that require https), I need to somehow tell the server that the original connection, or the connection that will go back to the client will be https, even though the server is responding via http.. I handle secure and non secure fine now, the same website for example. apps.domain.com, listens to both 443 and 80, so squid can handle secure and non secure. there is code on apps.domain.com that checks the incoming protocol to verify that's it's secure, if not it sends a secure url for the client to come back in on. As you can see if I allow Squid to handle the SSL portion, the back end server has no way of knowing (the piece I'm missing) if the actual client connection is secure or not. (hard to explain possibly).. Client apps.domain.com (443) Squid - backend server (80) backend server (80) -- Squid apps.domain.com (443) -- Client (443) I'm wondering if Squid can tell the peer (server) that the original request was in fact secure, so that we can tell the application, feel free to respond with the secure data via non secure port, because squid will encrypt the server response and get back to the client via https Sorry kind of long winded. Tory -- Please use Squid 2.6.STABLE20 or 3.0.STABLE5
Re: [squid-users] SSL Accel - Reverse Proxy
On ons, 2008-04-30 at 11:10 -0700, Tory M Blue wrote: I was wondering if there was a way for Squid to pass on some basic information to the server citing that the original request was Secure, so that the backend server will respond correctly. Yes. See the front-end-https cache_peer option. Regards Henrik
Re: [squid-users] SSL Accel - Reverse Proxy
Tory M Blue wrote: On Fri, May 2, 2008 at 5:25 AM, Amos Jeffries [EMAIL PROTECTED] wrote: You made the situation clear. I mentioned the only reasonably easy solution. If you didn't understand me, Keith M Richad provided you with the exact squid.conf settings I was talking about before. Obviously i have not., and I apologize. I want Squid to handle both HTTP/HTTPS (easy, implemented working for months). I want SQUID to talk to the backend server via HTTP.. period, (EASY) I want SQUID to handle the https encryption/description and talk to the origin server via http . (EASY) I want Squid to somehow inform the origin that the original request was in fact HTTPS (HOW, is the question at hand) I can do SSL and pass it and have squid handle the SSL without issue., the issue is allowing the origin insight as to the originating protocol, if squid accepts the client connection on 443 and sends the request to the origin on port 80 The issue is that I don't want my backend server to have to deal with ssl at all. But I have some applications that require the request be https (secured pages), So if Squid could pass something in the header citing that the original request was made via https, than my code could take that information, and know that sending secured data via non secure method is okay, since Squid will encrypt the data and send to the client before that data leaves my network. I had similar questions with squid sending the original http version information in a header, which it does. Now I'm wondering if squid keeps track of the original requesting protocol, so that my application can look at the header and decide if the original request came in as https (Since the origin at this point believes not, since squid is talking to the origin via http and talking to the client via https.) Sorry that I seem to be making this complicated, it totally makes sense in my head (: ) No worries (on our part at least). The HTTP-only back-end requirement is a major hurdle for you. No release of Squid has that capacity in any easy way. You will need to add new code to squid one way or another. Or have it added for you. You could try coding up an ICAP adaptor for Squid 3.0+ that just adds headers. Or make a url-rewrite setup adding a piece to the URL the server application receives. Tory I'm not sure how to be clearer and would be happy to email directly with someone , aim, or phone Amos -- Please use Squid 2.6.STABLE20 or 3.0.STABLE5
Re: [squid-users] SSL Accel - Reverse Proxy
Amos Jeffries wrote: Tory M Blue wrote: On Fri, May 2, 2008 at 5:25 AM, Amos Jeffries [EMAIL PROTECTED] wrote: You made the situation clear. I mentioned the only reasonably easy solution. If you didn't understand me, Keith M Richad provided you with the exact squid.conf settings I was talking about before. Obviously i have not., and I apologize. I want Squid to handle both HTTP/HTTPS (easy, implemented working for months). I want SQUID to talk to the backend server via HTTP.. period, (EASY) I want SQUID to handle the https encryption/description and talk to the origin server via http . (EASY) I want Squid to somehow inform the origin that the original request was in fact HTTPS (HOW, is the question at hand) I can do SSL and pass it and have squid handle the SSL without issue., the issue is allowing the origin insight as to the originating protocol, if squid accepts the client connection on 443 and sends the request to the origin on port 80 The issue is that I don't want my backend server to have to deal with ssl at all. But I have some applications that require the request be https (secured pages), So if Squid could pass something in the header citing that the original request was made via https, than my code could take that information, and know that sending secured data via non secure method is okay, since Squid will encrypt the data and send to the client before that data leaves my network. I had similar questions with squid sending the original http version information in a header, which it does. Now I'm wondering if squid keeps track of the original requesting protocol, so that my application can look at the header and decide if the original request came in as https (Since the origin at this point believes not, since squid is talking to the origin via http and talking to the client via https.) Sorry that I seem to be making this complicated, it totally makes sense in my head (: ) No worries (on our part at least). The HTTP-only back-end requirement is a major hurdle for you. No release of Squid has that capacity in any easy way. You will need to add new code to squid one way or another. Or have it added for you. Bah, never mind me. See Henriks post earlier. Amos -- Please use Squid 2.6.STABLE20 or 3.0.STABLE5
Re: [squid-users] SSL Accel - Reverse Proxy
Tory M Blue wrote: I was wondering if there was a way for Squid to pass on some basic information to the server citing that the original request was Secure, so that the backend server will respond correctly. Right now Squid takes and handles the SSL, passes back to the server via standard http and the application check, causes basically a loop, because it wants to see the client using SSL and not standard HTTP.. This is only an issue with same hostname/headers that have access on both 80/443 as the application needs to know that someone came in secured and that the Squid box will respond in kind. Am I missing something basic? i'm not seeing it in the information currently that Squid passes. Otherwise the application could key off the originating dest port or similar Thanks Tory You could make a second peer connection using HTTPS between squid and the back-end server and ACL the traffic so that only requests coming in via SSL are sent over that link. Leaving non-HTTPS incoming going over the old HTTP link fro whatever the server want to do. Amos -- Please use Squid 2.6.STABLE19 or 3.0.STABLE4
Re: [squid-users] SSL Accel - Reverse Proxy
On Thu, May 1, 2008 at 2:02 AM, Amos Jeffries [EMAIL PROTECTED] wrote: You could make a second peer connection using HTTPS between squid and the back-end server and ACL the traffic so that only requests coming in via SSL are sent over that link. Leaving non-HTTPS incoming going over the old HTTP link fro whatever the server want to do. Thanks Amos Not sure that I made myself clear or that I understand your suggestion. I need to allow squid to connect and talk to my servers via http (only), i want squid to handle the SSL termination (SSL acceleration, take the overhead off the back end servers). However since squid talks to the back end servers via http (and not https on pages that require https), I need to somehow tell the server that the original connection, or the connection that will go back to the client will be https, even though the server is responding via http.. I handle secure and non secure fine now, the same website for example. apps.domain.com, listens to both 443 and 80, so squid can handle secure and non secure. there is code on apps.domain.com that checks the incoming protocol to verify that's it's secure, if not it sends a secure url for the client to come back in on. As you can see if I allow Squid to handle the SSL portion, the back end server has no way of knowing (the piece I'm missing) if the actual client connection is secure or not. (hard to explain possibly).. Client apps.domain.com (443) Squid - backend server (80) backend server (80) -- Squid apps.domain.com (443) -- Client (443) I'm wondering if Squid can tell the peer (server) that the original request was in fact secure, so that we can tell the application, feel free to respond with the secure data via non secure port, because squid will encrypt the server response and get back to the client via https Sorry kind of long winded. Tory
RE: [squid-users] SSL Accel - Reverse Proxy
Tony, You can try something like this. acl port443 port 443 acl SAFE_ports port 443 #https https_port 443 accel vhost vport defaultsite=www.mywebsite.com cache_peer [backend webserver IP] parent 443 0 no-query originserver ssl login=PASS name=httpsWeb acl ourWebSite dstdomain www. mywebsite.com cache_peer_access httpsWeb allow ourWebSite -Original Message- From: Tory M Blue [mailto:[EMAIL PROTECTED] Sent: Thursday, May 01, 2008 11:21 AM To: squid-users@squid-cache.org Subject: Re: [squid-users] SSL Accel - Reverse Proxy On Thu, May 1, 2008 at 2:02 AM, Amos Jeffries [EMAIL PROTECTED] wrote: You could make a second peer connection using HTTPS between squid and the back-end server and ACL the traffic so that only requests coming in via SSL are sent over that link. Leaving non-HTTPS incoming going over the old HTTP link fro whatever the server want to do. Thanks Amos Not sure that I made myself clear or that I understand your suggestion. I need to allow squid to connect and talk to my servers via http (only), i want squid to handle the SSL termination (SSL acceleration, take the overhead off the back end servers). However since squid talks to the back end servers via http (and not https on pages that require https), I need to somehow tell the server that the original connection, or the connection that will go back to the client will be https, even though the server is responding via http.. I handle secure and non secure fine now, the same website for example. apps.domain.com, listens to both 443 and 80, so squid can handle secure and non secure. there is code on apps.domain.com that checks the incoming protocol to verify that's it's secure, if not it sends a secure url for the client to come back in on. As you can see if I allow Squid to handle the SSL portion, the back end server has no way of knowing (the piece I'm missing) if the actual client connection is secure or not. (hard to explain possibly).. Client apps.domain.com (443) Squid - backend server (80) backend server (80) -- Squid apps.domain.com (443) -- Client (443) I'm wondering if Squid can tell the peer (server) that the original request was in fact secure, so that we can tell the application, feel free to respond with the secure data via non secure port, because squid will encrypt the server response and get back to the client via https Sorry kind of long winded. Tory
