Re: report on EV and SSL MITM proxying

On Mon, 21 Mar 2011 17:51:06 +0100, peter williams <home_pw@msn.com> wrote:

> Concerning padlocks (vs green address bars): "If a certificate chain  
> fails
> either CRL or OCSP ver[i]fication (but is not revoked) the associated
> website will not get a padlock indication, and the security toolbar will  
> not
> be displayed." This UI concept seems to be distinguishing padlock and
> address bar semantics, based on the differences between non-availability  
> of
> revocation info and info stating cert is revoked/suspended. There are 4
> states: green/not-green, padlock/no-padlock. I still cannot tell how this
> works, PER TAB, or PER-INSTANCE of the browser. It's the padlock the
> lowest-common denominator of all tabs EV/revocation state?

Keep in mind that the UI language in the articles related to the UI used  
by Opera at the time the article was written

As for the padlock/badge it's state is decided based on all the URLs used  
to load the entire displayed document.

Currently defined a page cannot get a secure indication unless at least

   - It uses strong encryption, SSL v3, 128 bit encryption, RSA/DSA/DH/DHE  
keys >=1000 bits in the entire chain of certificates
   - No problems verifying the certificates, no missing certificates, no  
servername mismatch
   - All revocation information loaded succesfully, OCSP for site cert, CRL  
for the rest if one of the intermediates specifies it.

EV is not considered if any of the checks fail, if the security level is  
"secure" then the EV signal is checked, provided the Root CA is on the EV  
- enabled list.

So, there are *three* states: No padlock, padlock, EV.


> Concerning mashups (the heart of semantic web), we see something VERY
> interesting: "And lastly, if the Web site includes content from other Web
> servers, those servers must *also* be hosting EV-sites. This is a point  
> at
> which we are much stricter than the other EV-capable browsers currently.  
> As
> I said earlier: "It ain't EV 'til it is EV, all EV". I think this means  
> that
> the UI changes color/padlock depending upon the DOM document enforcer in  
> the
> browser reporting that each link also points to a site with an EV cert.  
> If
> the XHTML/RDFa document/graph changes (to now include a site with no EV
> cert), the browser behaves differently between the 2 moments. Different
> browsers implement different "document/graph semantics", per se, in any
> case. For example, open IE9 on XHTML+RDFa at time t on the site s,  it  
> may
> report EV-good; open Opera v.latest with the same conditions, it may  
> report
> EV-bad (due its "enhanced" graph-semantics for https).

Currently EV is only checked for the top document, not inlines. It can be  
configured, though.

See http://my.opera.com/yngve/blog/2008/05/23/lowering-the-ev-bar

One area where the EV for top only vs EV for all gets "interesting"  
concerns the case when the non-EV site can manipulate the actual HTML/DOM  
of the containing page, e.g due to external Javascript.

> I also noted caching related changes to OCSP. This allows a proxy to  
> cache a
> validation response (since the browser is no longer enforcing OCSP  
> nonces,
> or SSL nonces as a precondition of cert validity). If that proxy is the
> system proxy on a PC, should the internet connection be removed, the
> revocation information can be "still available" to the browser (being
> cached). Being "available" means the data exists in a proxy - whose  
> cache is
> trusted by the browser, using web caching semantics (not OCSP or SSL
> semantics).

OCSP responses are valid for several days, usually. Downloading them every  
browsing session is not really that effective.

While there may be OCSP responders that will support nonces, these will  
not be responders used by most sites, since supporting nonces means that  
the OCSP responder must sign every individual response it sends, as they  
are served, causing a significant performance bottleneck, since it can't  
prefabricate the responses.

The nonce supporting responders would be used in high security  
environment, e.g. military; not commercial ones. Maybe a certificate  
extension might be an idea in order to signal such support?

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************

Received on Tuesday, 22 March 2011 01:52:45 UTC