Hacker News Reader

Comment by mrb | Hacker News Reader

This is just one more reason for using HTTPS everywhere. Doing so prevents ISPs from intercepting and rewriting HTTP traffic.

Shame on you, Comcast.

View on HN

Comcast can just as easily MITM your SSL connections, for your safety of course.

But that ridiculous, right? Since everyone verifies SSL cert signatures...

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.

There are multiple solutions being proposed out there to add this trust layer. I am a strong advocate of DANE ( http://www.internetsociety.org/deploy360/resources/dane/ ) but there are others out there, too.

There was a good talk about this at Black Hat USA 2011 on "SSL and the Future Of Authenticity" at: http://www.youtube.com/watch?v=Z7Wl2FW2TcA

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.

I watched someone do it in one click yesterday.

IIRC, you can't open Gmail and many other websites on Chrome without genuine SSL.

If some interns running a corporate intranet can get a transparent htts proxy, what's stopping an ISP from rewriting your https traffic?

Your browser, for one. What you describe is the very definition of a MITM attack, regardless of proxy structure.

Your bank, for another. Indeed there are far too many parties with an interest in keeping https secure, that you needn't worry about it.

Because using Comcast using an HTTPS proxy to rewrite traffic means that your browser will expect data encrypted with Google's, Facebook's, Chase's, etc. certificate when it actually receives Comcast's proxy certificate. Every HTTPS site would prompt the user about an SSL certificate error.

I'm considering going a step farther and just setting up an Openvpn connection to my Linode server.

I've looked into the costs of VPNs on servers I own vs. a VPN service with unlimited bandwidth limits and the latter always wins. Setup time costs aside, VPN services usually have multiple regions you can connect to and are likely to have more reliable speeds.

This is, of course, if you trust these companies enough and [list of security implications].

A personal license of Umbrella by OpenDNS, which includes always-on laptop and phone VPN, is $20 a year currently. There are also features like Anycast that are not feasible to replicate on a personal server.

(disclosure - I start working with OpenDNS soon).

Reply on news.ycombinator.com