Ok Im back. Still confused as ever. Look below for my story. On 14 June 2018 1:25 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > There are three ways to do this: > > 1. if you own the domain the apps are connecting to. Setup the proxy as > a normal TLS / HTTPS reverse-proxy. > 2. if you have enough control of the apps to get them connecting with > TLS to the proxy and sending their requests there. Do that. > 3. the (relatively) complicated SSL-Bump way you found. The proxy is > fully at the mercy of the the messages sent by apps and servers. > Caching > is a luxury here, easily broken / prevented. > Well, there is a forth way with intercept. But that is a VERY last > resort and you already have (3) going and that is already better than > intercept. Getting to (1) or (2) would be simplest if you meet the "if > ..." requirements for those. 1. Both the proxy and the apps are on the same machine on my home network. The server they are calling is not mine and have no way of modifying its behaviour. That rules out 1, if I understood correctly? 2. According to the java docs, the https_proxy (-Dhttps.proxyHost and -Dhttps.proxyPort should redirect all ssl traffic to that destination.) should cover this. And I already have done that. So I seemed to have combined 2 and 3 here? But I *only* need 2 you are saying. > The proper way to make caching happen with your desired behaviour is for > the server to present HTTP Cache-Control header saying the object is > cacheable (ie does not forbid caching), but not for more than 10seconds. > Cache-Control: max-age=10 > OR to say that objects need revalidation, but presents a 304 status for > revalidation checks. (ie Cache-Control:no-cache) (yeah, thats right, > "no-cache" means do cache). > > That said, I doubt you really are wanting to force that and would be > happy if the server was instructing the the proxy as being safe to cache > an object for several minutes or any value larger than 10sec. > So what we circle back to is that you are probably trying to force > things to cache and be used long past their actual safe-to-use lifetimes > as specified by the devs most authoritative on that subject (under > 10sec?). As you should be aware, this is highly unsafe thing to be doing > unless you are one of those devs - be very careful what you choose to do. I'm well aware of the issues this might pose, and yes: the server *is* sending out cache-control. Look below for the header. My wish is to ignore those headers and still cache the content. To repeat, Im well aware of the issues this might pose, and is ready to run side-by-side tests continuosly to make certain all the app behave like they should, even if they are only getting cached content. Ive analyzed the apps web calls for about a day of data, and figured out how many and what type of calls it does, and I know the response content very well, since I have written apps against that API myself. What I am actually doing is writing a test bench for the application in question by running many of them simultaneously against the same data sets, with differing configurations to compare the result. No other person is to touch this project, so Im fairly sure it wont affect anyone but my own free time :) It's not meant for production environment of any kind, and Im aware of the potential failures of the project should anything out of my control happen. But thanks for the warnings of course. You have no way of knowing what my intentions with the project were when I first asked my questions, and probably should have had done that from the start. I hope that makes evrything a bit clearer? Anyway, So...is it all possible to override the cache controls of the headers below? server reply header: HTTP/1.1 200 OK Content-Type: application/json Transfer-Encoding: chunked Connection: keep-alive Date: Wed, 13 Jun 2018 17:18:33 GMT Server: nginx Vary: Accept-Encoding Strict-Transport-Security: max-age=31536000; includeSubdomains X-Frame-Options: SAMEORIGIN X-Xss-Protection: 1; mode=block X-Content-Type-Options: nosniff Content-Security-Policy: default-src 'self' X-Content-Security-Policy: default-src 'self' X-WebKit-CSP: default-src 'self' Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache Expires: 0 X-Cache: Miss from cloudfront Via: 1.1 21258ec71c1aa4499bcd08c6ad0eba38.cloudfront.net (CloudFront) X-Amz-Cf-Id: gdqZScePve6zvtHqlFa8TmCmmh0rKGrwD2Gwx46PbUSqd94QiJhkPQ== > > Squid normally listens to port 3128 > > =================================== > > #http_port 3128 ssl-bump generate-host-certificates=on > > dynamic_cert_mem_cache_size=4MB > cert=/cygdrive/c/squid/etc/squid/correct.pem > > key=/cygdrive/c/squid/etc/squid/ssl/myca.key > > http_port 3128 ssl-bump generate-host-certificates=on > > > > dynamic_cert_mem_cache_size=4MB > > cert=/cygdrive/c/squid/etc/squid/proxyCAx.pem > > key=/cygdrive/c/squid/etc/squid/proxyCA.pem > > #https_port 3129 cert=/cygdrive/c/squid/etc/squid/proxyCAx.pem > > key=/cygdrive/c/squid/etc/squid/proxyCA.pem > > Hmm. This is a Windows machine running Cygwin? > FYI: Performance is going to be terrible. It may not be super relevant > yet. Just be aware that Windows imposes limitations on usable sockets > per application - which is much smaller than a typical proxy requires. > > The Cygwin people do a lot but they cannot solve some OS limitation > problems. > > To meet your very first sentence "as many as possible" requirement you > will need a non-Windows machine to run the proxy on. That simple change > will get you something around 3 orders of magnitude higher peak client > capacity on the proxy. The current setup is on my windows laptop. Im only doing PoCs on it before doing it all over again on a debian box with docker, where the applications are to run. (Im already looking forward to bug hunting the differences in behaviour for the whole thing after moving it, btw!) Sounds ok? If anyone have any suggestions on how I would run this even more efficiently, I would very much like to know! It's a critical facet of the proejhct to get as many of these applciations running at the same time. > Overall - in order to use these refresh-pattern controls you need to > know what the HTTP(S) messages going through your proxy contain in > terms > of caching headers AND what those messages are doing semantically / > content wise for the client application. Using any of them as a > generic > "makes caching better" thing only leads to problems in todays HTTP > protocol. I've pulled out the relevant bits of the headers: Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache Expires: 0 I guess I went slightly overboard with my config. I tried to add one directive after another to see if there was any change. I couldn't spot any. Would this be the correct setup for my refresh_pattern to be able to cache reponses with this header? ignore-no-store ignore-must-revalidate override-expire ? What about the Expires: 0? Is that covered by override-expire? > > dns_nameservers 8.8.8.8 208.67.222.222 > > Use of 8.8.8.8 is known to be explicitly detrimental to caching > intercepted traffic. > > Those servers present different result sets based on the timing and IP > sending the query. The #1 requirement of caching intercepted (or > SSL-Bump'ed) content is that the client and proxy have the exact same > view of DNS system contents. Having the DNS reply contents change > between two consecutive and identical queries breaks that requirement. Thanks. Using my own dns now! > > max_filedescriptors 3200 > > > > Max Object Size Cache > > ===================== > > maximum_object_size 10240 KB > > acl step1 at_step SslBump1 > > ssl_bump peek step1 > > ssl_bump bump all > > This causes the proxy to attempt decryption of the traffic using crypto > algorithms based solely on the ClientHello details and its own > capabilities. There is zero server crypto capabilities known for the > proxy to use to ensure traffic can actually make it to the server. > You are rather lucky that it actually worked at all. Almost any > deviation (ie emergency security updates in future) at either client or > server or proxy endpoints risks breaking the communication through this > proxy. > > Ideally there would be a stare action for step2 and them bump only at > > step 3. > > So in summary to the things to try to get better caching: > > - ditch 8.8.8.8. Use a local DNS resolver within your own network, > shared by clients and proxy. That can use 8.8.8.8 itself, the > important > part is that it should be responsible for caching DNS results and > ensuring the app clients and Squid see as much the same records as > possible. > > - try "debug_options 11,2" to get a cache.log of the HTTP(S) headers for > message being decrypted in the proxy. Look at those headers to see why > they are not caching normally. Use that info to inform your next > actions. It cannot tell you how the message is used by the > application, > hopefully you can figure that out somehow before forcing anything > unnatural. > > - if you can, try pasting some of the transaction URLs into the tool at > redbot.org to see if there are any HTTP level mistakes in the apps > that > could be fixed for better cacheability. What Im still confused about all this, and it's probably because I dont understand the squid system well enough, and that I have possibly read too many suggestions on other forums that have pointed me in the wrong direction. What I have gathered from your posts and the others: If I want to cache https/ssl I need to decrypt the requests and responses using certificates. Otherwise the application will only tunnel its requests to the destination and the proxy wont know what's in the messages. However, I *dont* have to bump and peek and do a fancy dance to get squid to cache it. I also see that Amos is suggesting a reverse proxy (accel mode) on the proxy. So... ... I assume this is not needed? http_port 3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/cygdrive/c/squid/etc/squid/proxyCAx.pem key=/cygdrive/c/squid/etc/squid/proxyCA.pem And I need something like this: https_port 3128 accel generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/cygdrive/c/squid/etc/squid/proxyCAx.pem key=/cygdrive/c/squid/etc/squid/proxyCA.pem I tried this here now, and it seems to fail even more than before. No idea why. I get this error message that seems to point me in the right direction, but haven't found anything on google to give me an indication as to what it actually points towards. Squid_SSL_accept: Error negotiating SSL connection on FD 10: error:00000005:lib(0):func(0):DH lib Am I right in my musings so far? :) Oh. Ive tried to use the browser as source of my tests. There is little change in result to what the java apps are doing. Any thoughts or ideas are wildly appreciated! -- Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
