On 02/06/14 15:12, Antoine Klein wrote:
Ok I'm understanding !
Finally I'm going to change strategy, if it isn't possible to decrypt
HTTPS without warning for client, I shall make differently.
You will have to, as it's impossible to do so without interfering with
the user's client devices.
So there is two solutions, the first one is to use Squid without
deciphering SSL request. So Amos you explained that but I don't
understand what bugs is encountered. So in this case, how can I
configure Squid ? I didn't find example and I have already asked for
that but i was told it would be impossible, but they were not sure.
Just use delay pools as described in the docs. The "bugs" will not be
showstoppers, they might just bias the pools unexpectedly but given
you'll have lots of random clients it will probably even out.
The second solution consists in not using Squid, but to apply a QoS
differently, but I need a QoS like the Squid delay pool, do you know
if it is possible ? Alex you already spoken to me about LARTC, but I
need to find a solution quickly, so I fear that it was too long to
understand the Linux QoS possibilities.
How about Shorewall, pfSense, etc? No-one here probably has the time to
give you an out-of box setup that will suit you. I know for sure I
don't. You also have a pre-existing firewall and given it looks fairly
magical it should be able to do per-ip QoS (at least if you just drop
the Squid before it hits the FW)
I can't understand how you've been persuaded to accept a project that
you should have been doing months of research on and then agree to
deliver in days (not knowing what was actually possible). Did you
over-promise you your boss? If so, don't!
I never promise to deliver anything. I give an estimate that is bases on
"(((Time I expect to take this given I know everything *3) + (Time I
think I'll need to find something out when I find I don't know
everything *3)) * (Time it will take me to reconcile what people said
they want vs what thet actually need *3) * 3)". If an external supplier
is involved multiply the whole lot by *at least* 10.
That works out to about 2 months for what your average
client/boss/marketing person says will take a week...
Cheers
Alex
Regards.
2014-06-02 10:06 GMT-04:00 Antoine Klein <klein.anto@xxxxxxxxx>:
Ok I'm understanding !
Finally I'm going to change strategy, if it isn't possible to decrypt HTTPS
without warning for client, I shall make differently.
So there is two solutions, the first one is to use Squid without deciphering
SSL request. So Amos you explained that but I don't understand what bugs is
encountered. So in this case, how can I configure Squid ? I didn't find
example and I have already asked for that but i was told it would be
impossible, but they were not sure.
The second solution consists in not using Squid, but to apply a QoS
differently, but I need a QoS like the Squid delay pool, do you know if it
is possible ? Alex you already spoken to me about LARTC, but I need to find
a solution quickly, so I fear that it was too long to understand the Linux
QoS possibilities.
Regards.
2014-05-31 12:54 GMT-04:00 Amos Jeffries <squid3@xxxxxxxxxxxxx>:
On 1/06/2014 3:49 a.m., Alex Crow wrote:
<snip>
But given all you really need is QoS, why don't you either (a) dispense
with Squid and just to QoS on the firewall for your Wifi subnet or (b)
put a transparent firewall between your clients and the Squid server
that does QoS? Or just see if Squid delay pools work for SSL (I think
they *do*, the traffic still passes via Squid as a CONNECT request -
it's just that Squid can't "see" or proxy the plaintext content.)
I second all of the above. In particular that the built-in QoS features
of the firewall or router device neworking config is far better place to
be doing the delay actions than Squid.
In regards to delay pools and HTTPS. As far as I know the pools work
without decrypting, although you may encounter one of a handful of bugs
which trigger over or under counting of bytes (depending on the bug
hit). So you may need a special delay pool configured with a hack on the
speed value of port 443 traffic to make the user-visible speed what they
expect.
Amos
--
Antoine KLEIN
