[squid-users] squid reverse proxy (accelerator) for MS Exchange OWA

Yuri Voinov yvoinov at gmail.com
Wed Feb 1 16:29:38 UTC 2017

I'm sorry to interrupt, gentlemen - but Microsoft does not use
certificate pinning in OWA?

01.02.2017 22:19, Amos Jeffries пишет:
> On 27/01/2017 9:31 p.m., Vieri wrote:
>> ----- Original Message ----- From: Alex Rousskov
>> <rousskov at measurement-factory.com>
>>>> It's interesting to note that the following actually DOES give
>>>> more information (unsupported
>>>> protocol):>
>>> * If the server sent nothing, then Curl gave you potentially
>>> incorrect information (i.e., Curl is just _guessing_ what went
>>> wrong).
>> I never tried telling Squid to use TLS 1.1 ONLY so I never got to see
>> Squid's log when using that protocol. I'm supposing I would have seen
>> the same thing in Squid as I've seen it with CURL. So I'm sure Squid
>> would log useful information for the sys admin but... (see below).
>>>> Maybe if Squid gets an SSL negotiation error with no apparent
>>>> reason then it might need to retry connecting by being more
>>>> explicit, just like in my cURL and openssl binary examples
>>>> above.
>>> Sorry, I do not know what "retry connecting by being more
>>> explicit" means. AFAICT, neither Curl nor s_client tried
>>> reconnecting in your examples. Also, an appropriate default for a
>>> command-line client is often a bad default for a proxy. It is
>>> complicated.
>> Let me rephrase my point but please keep in mind that I have no idea
>> how Squid actually behaves.
> Let me pause you right there.  What you describe is essentially how the
> TLS protocol handshake is actually performed.
>> Simply put, when Squid tries to connect
>> for the first time, it will probably (I'm guessing here) try the most
>> secure protcol known today (ie. TSL 1.2), or let OpenSSL decide by
>> default which is probably the same.
> That is exactly what happens.
>> In my case, the server replies
>> nothing. That would be like running:
>> # curl -k -v or # openssl s_client -connect
>> They give me the same information as Squid's log... almost nothing.
>> So my point is, if that first connection fails and gives me nothing
>> for TLS 1.2 (or whatever the default is), two things can happen:
>> either the remote site is failing or it isn't supporting the
>> protocol. Why not "try again" but this time by being more specific?
> Several reasons.
> Reason #1 is that the TLS protocol is a security protocol for securing a
> single 'hop' (just one TCP connection). So ideally TLS details would not
> be remembered at all, it's a dangerous thing in security to remember
> details in the middleware.
> Reason #2 is that Squid has passed on the 'terminate' signal to the
> client (curl).
> As far as Squid is concerned, there is no "again" connection. There is a
> connection, which fails. The end.
> There is a connection. Which fails. The end.
> There is a connection. Which fails. The end.
>  ... and so on. These connections may be from the same client, or
> different ones. May be to same or different servers. They are
> independent of each other and only TCP at this point.
> The TLS setup/handshake parts never get far enough for there to be
> anything to remember. Except that TCP connection failed.
> Well, Squid does remember that and tries a different IP next time. Until
> it runs out of IPs, then it resets its bad-ID memory with a new DNS
> lookup and the cycle begins again.
> NP: if you are interested you can see the GOOD/BAD flags on IPs in the
> ipcache cache manager report (squidclient mgr:ipcache).
>> It would be like doing something like this:
>> # openssl s_client -connect || openssl s_client
>> -connect -tls1_1 || openssl s_client -connect
>> -tls1
> Which brings us to reason #3; downgrade attacks.
> You may have heard of the POODLE attack. It is basically a middleware
> (like Squid) forcing the other endpoint(s) to re-try with lower TLS
> versions until a version is reached and cipher selected that the
> attacker can decrypt or steal the keys from.
> Squid (mostly) avoids the whole class of vulnerabilities by leaving the
> fallback decisions to the client whenever it can.
> Since the curl command only did the one request, that is all that
> happened. No retry.
> Amos
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

Bugs to the Future
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x613DEC46.asc
Type: application/pgp-keys
Size: 2437 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20170201/b61edab8/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20170201/b61edab8/attachment.sig>

More information about the squid-users mailing list