On 12/19/2011 09:36 PM, ianG wrote: > On 20/12/11 08:13 AM, Christopher Howard wrote: >> There is something that I've been wondering about for a while now: When >> I connect to a SSL/TLS-secured Web site, Firefox allows me to click on >> the identity box and the "More information..." button, and it will give >> me details about the certificate, encryption grade, and key length. >> However, whenever a page is only partially encrypted (which seems to be >> quite often the case) Firefox refuses to provide any information about >> the cipher or the key length used. I have even installed the Calomel SSL >> Validation plug-in to see if I could get more information, but it >> behaves in the same way. >> >> Is there any technical reason for this? Or is this just something that >> was overlooked? Knowing the encryption details would be useful even on a >> page that is only partially encrypted. > > Yeah, it's broken at the security model level. The underlying > difficulty is the clash of security models & perceptions as to what > matters. > > Go back in history: SSL was invented to create one secure connection to > one site in order to protect one credit card number as it was passed > across in a HTTP POST. It was claimed that this transfer had to be > strongly protected, no matter what, against all threats, and this must > be an absolute requirement. > > Hold on to that thought: the credit card must be protected, or die in > the attempt! > > The response to this and other market developments was devastating to > the security model. Almost immediately (we're talking 1995) there was > pressure to turn off SSL and ditch it because it was too slow. What > happened in the market was that the "payments page" was sliced out and > set up separately so payment could happen over "slow SSL" after the > decision to buy was apparently made. > > This immediately broke the entire model because there was now an easy > downgrade attack from HTTPS to HTTP in the browser, which the user was > ill-equiped to deal with (as Netscape had independently modified the GUI > to drop the CA's name). But on paper, the actions of the servers were > compliant because they could point at *their received credit card > numbers* and show that they were protected. Strongly. No matter what > ... including putting at risk credit cards they never saw. Everyone was > happy. > > Move forward a few years, and browsers & sites started breaking other > assumptions, and phishers turned up and started exploiting the downgrade > attack in the browsers. So, the original killer requirement, that the > credit card must be protected against everything imaginable ... killed > the security entirely by causing implementors to turn off the model in > what they thought were safe circumstances. > > In practical detail right-now terms the question is that the GUI people > don't know how to present a mix of zero-security with ultra-high > security. What does that mean? do we average it? Say it is > top-security and pray it is? Say it is no security and ignore the > rest? (The answer from the model is, like renegotiation, the browser > should drop the connection.) > > That argument can go around and around, but keep coming back to the > original requirements. Then, we see that answer to your question is > irrelevant, because the absolute requirement was bypassed so badly that > the model was broken. We're not using the SSL security model, and > haven't been since 1995. So you can do whatever you like, or more > practically, whatever you feel you can get away with (think about the > dozens of connections that modern portals fire up, and outsourced > payment processors and google tools and ...). > > > > iang
It is rather interesting that most people (in my circles at least) only think of SSL in terms of payment protection. But as I see it, the authentication and integrity protection functionality are just as important. Knowing where the data came from and that it hasn't been tampered with. Anyway, thanks for the response. I can understand the dilemma over deciding how to represent the security of a site that mixes secure and insecure content. Though, to be honest that doesn't do much to satisfy my geekish desire to know what is going on behind the scenes as far as ciphers, key lengths, and so forth. In addition, it would be cool if Firefox were to somehow display the reason specifically that a Web site was declared "partially encrypted". My banking Web site was declared partially encrypted, but after combing it over for an hour with Firebug I still couldn't find the unencrypted resource. (I think it was an unencrypted advertisement cookie.) -- frigidcode.com theologia.indicium.us
signature.asc
Description: OpenPGP digital signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
