They would either need the private key of the certificate holder (which they don't have), or a certificate signed by one of the roots installed on the system, which they also won't have.
I suppose the logical next step is that Comcast requires you to install a "Comcast Internet Helper" program that also installs a Comcast root certificate into the system so they can mitm anything.. But Firefox and Chrome would probably release updates mere hours later, blocking that cert from being used from those browsers.
> They would either need the private key of the certificate holder (which they don't have), or a certificate signed by one of the roots installed on the system, which they also won't have.
Actually, this is fairly common for firewalls and other edge devices to do and is one of the problems with the "trust" in the CA system. You can get a "signing certificate" from various legitimate sources (ex. http://www.sslshopper.com/article-trusted-root-signing-certi... ) that allows your product/service to terminate SSL connections and then recreate a SSL connection. The user still sees their "lock" icon and thinks they have a secure https connection to their original site, when in fact they don't.
They do have a SSL connection to their site using a certificate - it's just NOT the certificate that the original site issued. This is why many of us are looking to protocols like DANE that uses DNSSEC to add a layer of integrity protection so that you can know that you are using the correct SSL certificate. (See http://www.internetsociety.org/deploy360/resources/dane/ )
Note that no new certificates need to be added to browsers. The signing certificates work with the existing root certificates that are already in browsers.
Ouch, I wasn't aware that CAs issued this type of "root" certificates. Is this very common, or will only some CAs do it? If the latter, I'll definitely remove them from my computers list of trusted CAs..
Edit: read the DANE article, seems very sensible and simple to implement that the server specifies valid certificates.
Most people are going to click through any security warning because they just want to get to the site they wanted to go to. If Comcast does this, it would make EVERY SSL site display the warning, making it utterly meaningless.
Alternatively, it's not that outrageous to think that Comcast et al could get certs into the major browsers if they wanted to do so. It's not even implausible to think that at some point, browsers will be legally required to distribute ISP certs to allow for the "safety" of users.
If Comcast makes you install a custom application to keep your certs up, it won't matter if Fx and Chrome block each cert within hours, because Comcast can keep generating and pushing new ones out. And, as above, if the ISP is going to fiddle like this, the actual power held by browsers is greatly diminished -- users aren't going to use a browser that doesn't let them browse without nag screens on every page, even if it is "for their own good".
As I noted in a comment elsewhere in this thread, Comcast (or any other vendor) doesn't need to go through the work of getting certs into major browser. They just need to purchase and use a root signing certificate that works under the existing root CAs that are already in all the browsers.
This is part of why the trust model of the current CA system is fundamentally broken. We need to add a layer that can ensure that we are in fact using the SSL certificate that the site owner wants us to use.
I think you're a bit out of touch as those browser warning pages have changed a lot the last few years. It's actually pretty hard to get through those warnings now in most of the browsers.
But that ridiculous, right? Since everyone verifies SSL cert signatures...