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

[Yuri Voinov]

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 https://10.215.144.21 or # openssl s_client -connect
>> 10.215.144.21:443
>>
>> 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 10.215.144.21:443 || openssl s_client
>> -connect 10.215.144.21:443 -tls1_1 || openssl s_client -connect
>> 10.215.144.21:443 -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>