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@xxxxxxxxxxxxxxxxxxxxxxx> >> >>>> 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@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users -- Bugs to the Future
Attachment:
0x613DEC46.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
