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
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
