<div dir="ltr"><div>So, if my traffic are more https than http there's no need to use squid.<br></div>Man, most of sites are https, what's the purpose of using squid?<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-09-24 16:13 GMT-03:00 Yuri Voinov <span dir="ltr"><<a href="mailto:yvoinov@gmail.com" target="_blank">yvoinov@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<br>
-----BEGIN PGP SIGNED MESSAGE----- <br>
Hash: SHA256 <br>
<br></span>
First. This is potentially dangerous. Can you guarantee your proxy
never has physical/network access by intruders? HTTPS can contain
sensitive data. You really sure you want problems with users? AS a
minimum you need protect your proxy at level B2 (by Orange Book).<br>
<br>
Second. Yes, it dangerous, but possible with SSL Bump. With very
agressive cache parameters and with conjunction previous sentence.
So, this is dangerous for many sites - for it's functionality and
security, in general.<br>
<br>
You still sure you want to do this?<br>
<br>
24.09.15 20:46, Jorgeley Junior пишет:<br>
<span style="white-space:pre-wrap"><div><div class="h5">> Can we do that to cache https?<br>
> http_port 3128 ssl-bump generate-host-certificates=on<br>
> dynamic_cert_mem_cache_size=4MB
cert=/usr/local/squid/etc/monkey.pem<br>
><br>
> 2015-09-24 11:24 GMT-03:00 Jorgeley Junior
<a href="mailto:jorgeley@gmail.com" target="_blank"><jorgeley@gmail.com></a>:<br>
><br>
>> Is it not possible to cache the https due the encryption?<br>
>><br>
>> 2015-09-18 9:44 GMT-03:00 Antony Stone
<a href="mailto:Antony.Stone@squid.open.source.it" target="_blank"><Antony.Stone@squid.open.source.it></a><br>
>> :<br>
>><br>
>>> On Friday 18 September 2015 at 14:27:42, Jorgeley
Junior wrote:<br>
>>><br>
>>>> there is a way to improve it?<br>
>>><br>
>>> Improve what? The percentage of your traffic which
is cached, or the<br>
>>> accuracy<br>
>>> of the information reported by your monitoring
system?<br>
>>><br>
>>><br>
>>> If you want to cache more content:<br>
>>><br>
>>> 1. Make sure the sites being visited have available
content (note that<br>
>>> 12.6%<br>
>>> of your requests resulted in the remote server saying
some variation on<br>
>>> "nothing available").<br>
>>><br>
>>> 2. Ignore things which are meaningless - such as the
27% of your requests<br>
>>> which resulted in 407 Authentication Required - that
tells you nothing<br>
>>> about<br>
>>> whether the user then successfully authenticated and
got what they<br>
>>> wanted, or<br>
>>> didn't, but either way it's a standard response from
the server which<br>
>>> tells<br>
>>> you nothing about the effectiveness of your cache.<br>
>>><br>
>>> 3. Make sure your traffic is HTTP instead of HTTPS.<br>
>>><br>
>>> 4. Make sure your users are visiting the same sites
repeatedly so that<br>
>>> content<br>
>>> which gets cached gets re-used.<br>
>>><br>
>>> 5. Make sure the sites they're visiting are not
setting "don't cache" or<br>
>>> "already expired" headers (such as is common for news
sites, for example)<br>
>>> so<br>
>>> that the content is cacheable.<br>
>>><br>
>>> 6. Run your cache for long enough that it's likely to
have a<br>
>>> representative<br>
>>> proportion of what the users are asking for when you
start measuring its<br>
>>> effectiveness - if you start from an empty cache and
pass requests<br>
>>> through it,<br>
>>> it's going to take some time for the content to build
up so that you see<br>
>>> some<br>
>>> hits.<br>
>>><br>
>>><br>
>>> If you want to improve the information you're getting
from the monitoring<br>
>>> system, make sure it's telling you how much was
cached as a proportion of<br>
>>> requests which could have been cached - in other
words, leave out HTTPS<br>
>>> (36%)<br>
>>> and 407 Auth Required (27%), plus anything where the
remote server had<br>
>>> nothing<br>
>>> to provide (13%), and requests where the user's
browser already had a<br>
>>> cached<br>
>>> copy and didn't to request an update (4%).<br>
>>><br>
>>> That throws out 80% of your current statistics, so
you concentrate on the<br>
>>> data<br>
>>> about connections Squid *could* have helped with.<br>
>>><br>
>>>> 2015-09-18 8:25 GMT-03:00 Antony Stone:<br>
>>>>> On Friday 18 September 2015 at 13:13:27,
Jorgeley Junior wrote:<br>
>>>>>> hey guys, forgot-me? :(<br>
>>>>><br>
>>>>> Surely you can see for yourself how many
connections you've had of<br>
>>>>> different types? Here are the most common
(all those over 100<br>
>>> instances)<br>
>>>>> from your list of 5240 results<br>
>>>>><br>
>>>>>>> 290 TAG_NONE/503<br>
>>>>>>> 368 TCP_DENIED/403<br>
>>>>>>> 1421 TCP_DENIED/407<br>
>>>>>>> 680 TCP_MISS/200<br>
>>>>>>> 192 TCP_REFRESH_UNMODIFIED/304<br>
>>>>>>> 1896 TCP_TUNNEL/200<br>
>>>>><br>
>>>>> So:<br>
>>>>><br>
>>>>> 290 (5.5%) got a 503 result (service
unavailable)<br>
>>>>> 368 (7%) were denied by the remote server
with code 403 (forbidden)<br>
>>>>> 1421 (27%) were deined by the remote server
with code 407 (auth<br>
>>> required)<br>
>>>>> 680 (13%) were successfully retreived from
the remote servers but were<br>
>>>>> not previously in your cache<br>
>>>>> 192 (3.6%) were already cached by your
browser and didn't need to be<br>
>>>>> retreived<br>
>>>>> 1896 (36%) were successful HTTPS tunneled
connections, simply being<br>
>>>>> forwarded<br>
>>>>> by the proxy<br>
>>>>><br>
>>>>> This accounts for 4847 (92.5%) of your 5240
results.<br>
>>>>><br>
>>>>> As you can see, just measuring HIT and MISS
is not the whole picture.<br>
>>>>><br>
>>>>><br>
>>>>> Hope that helps,<br>
>>>>><br>
>>>>><br>
>>>>> Antony.<br>
>>><br>
>>> --<br>
>>> "The problem with television is that the people must
sit and keep their<br>
>>> eyes<br>
>>> glued on a screen; the average American family hasn't
time for it."<br>
>>><br>
>>> - New York Times, following a demonstration at the
1939 World's Fair.<br>
>>><br>
>>>
Please reply to the<br>
>>> list;<br>
>>>
please *don't*<br>
>>> CC me.<br>
>>> _______________________________________________<br>
>>> squid-users mailing list<br>
>>> <a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
>>> <a href="http://lists.squid-cache.org/listinfo/squid-users" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>><br>
>><br>
>><br>
><br>
><br></div></div>
> --<span class=""><br>
><br>
><br>
><br>
> _______________________________________________<br>
> squid-users mailing list<br>
> <a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
> <a href="http://lists.squid-cache.org/listinfo/squid-users" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a></span></span><br><span class="">
<br>
-----BEGIN PGP SIGNATURE-----
<br>
Version: GnuPG v2
<br>
<br></span>
iQEcBAEBCAAGBQJWBEtiAAoJENNXIZxhPexGHWgH/Rr0iGPCyTy7R5UYI/8PSvQO
<br>
5oSWO3Oyr+MVQaGUecLq01CoyRlw1t5IRPoVnL8k/39xp0g2QlmLcWi50UjKexXr
<br>
+aOYdi2wvoFyYLISR9Dx0t64RqYYzACzmYS4hSo1yPTZ25jb3AcNGpU5D3nbQmty
<br>
Uuqomj98yo8Owz6tHnz/uEaU5AS/w4Wec+b/om3LhyiagQWa21ub42x2rqRzwNk4
<br>
pLCrtDYGFC9Vn9VMmZCZygw7/c+1CSMPW4qDkxc6GiM55EDataPtJ7uTNL2XOMwZ
<br>
9Ys1XtIuvGuMpXU2CYUiWVP4KiL3WDWPfzSqPhmrrt/laVuNNM1aOUuSNLx4oGU=
<br>
=g2rO
<br>
-----END PGP SIGNATURE-----
<br>
<br>
</div>
<br>_______________________________________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div style="text-align:left"><font size="4"><b><u><br></u></b></font></div><div style="text-align:left"><font size="4"><b><u><img src="https://lh6.googleusercontent.com/-xODPvbH2piQ/T6RqD0dqXjI/AAAAAAAAAPk/0I8Y3aq0mYM/h120/linuxano+assinatura+e-mail.png"><br></u></b></font></div></div>
</div>