Re: [TLS] OCSP must staple

[Yoav Nir <[e-mail]>]

On Jun 12, 2014, at 9:21 PM, Brian Smith <[e-mail]> wrote:

> On Thu, Jun 12, 2014 at 2:02 AM, Yoav Nir <[e-mail]> wrote:
> Regarding TLS proxies, I can give my perspective, as I work for one vendor. 
> 
> <hat type=“vendor” status=“on”>
> Our fake certificates contain the DNs and alternate names from the original certificate. We don’t copy over any extensions that we don’t understand. The same is also true of TLS - we don’t copy extensions we don’t know. That is what allows our proxy to gracefully downgrade HTTP/2 or SPDY clients and gateways to HTTP/1.
> As for dates, these *are* copied from the original certificate, the reason is that this makes the client behavior similar to whatever it is with the original certificate. We did consider making the certificates short-lived, but decided against it. 
> </hat>
> 
> So your proposed heuristic for detecting fake certificates will work with some proxies, but not all. Adam’s suggestion should work better, but best is if the fake certificate doesn’t promise things the proxy CA doesn’t understand.
> 
> Thanks for sharing that information. Does your product copy all the certificate policies from the original certificate into the forged certificate? If your product doesn't copy certificate policies it doesn't understand, then there wouldn't be an interop issue with your product and the use of certificate policies for Must-Staple, even if your product doesn't generate short-lived certificates.

IIRC we don’t copy certificate policies at all, but I could be wrong. 

The thing is, a browser like Mozilla has to work with many different interceptors around, so there might be one that does copy all extensions, but doesn’t make short-lived certificates.

Yoav