Can real end-to-end SSL encryption be made?

Question

I've read the various questions tagged [ssl] and [mitm] and [proxy] and I couldn't find a duplicate.

I've got a very precise question but first I need to give some background.

Basically I'm very surprised by the recent development that highlighted the fact that both Nokia and Opera Mini are actually using their servers as endpoint of "secure" SSL connection between users and websites (like for example online banking websites).

Apparently they're doing so in the name of performance: they're using their servers as the endpoint which then act as a proxy for the user. On their servers, they are rendering and compressing the page to be displayed and sending that to their users.

I'm also totally confused by the reaction of most people: most people reacting say: "Nothing to see here, it's common practice, move along".

It comes as a shock as I was under the impression that I was the endpoint, not some Nokia / Opera Mini server. I realize that it's not a MITM attack over SSL because the servers become the endpoint and, you, the user, are served "something else" (either modified HTML or a picture or whatever)...

I understand it's (supposedly) done in the name of performance. I personally see it as sacrifying security in the name of performance but whatever.

Now, and that's where the real shock comes for me, several people pointed out that it's not only phone makers who could do this, but any ISP as well.

And I found this sentence:

"Software that does use the OS cert store or SSL lib should still be immune to this"

So my question is very simple: how can I securely connect, from a desktop computer (not from a phone), to websites using HTTPS (like my online banking website or my GMail), knowing that I may be using an ISP interested in spying on me?

Does a browser like Google Chrome, for example, have any protection against this? (for example is it sufficient to look at the green "lock" icon followed by "HTTPS://mail.google.com/..." or can this be tricked too by the ISP?)

Answer 1

This practice is sometimes described as "institutional man-in-the-middle attack". It can be done by either modifying the client code (so that it allows such proxying), or adding a special CA in the trust store of the client; in the latter case, the proxy intercepts the connection, generates a fake certificate for the server (issued by the special CA -- it is "special" in that the private key is controlled by the proxy), and runs a true MitM "attack".

This is done by big organizational content filters (e.g. Bluecoat's ProxySG) and by "Internet accelerators" like the one you observe (by accessing the raw data contents, the MitM proxy can apply some strategies for "speeding things up", namely caching and enforced data compression).

Accelerators often rely on client code modification, which allows for more "speeding up strategies" than the basic interception with a fake server certificate. This is probably your case; it will be browser specific. It is a security concern since it defeats one of the key points of SSL, i.e. to bring end-to-end confidentiality and integrity. I know some banks who are really unhappy about that, because it makes it much more difficult to apply some legal value to SSL-based Internet banking. As a user, you can defend against this practice (which is indeed widespread) by using an alternate browser (e.g. Firefox seems to be available for some Nokia phones) and verifying that the alternate browser trusts only "trustworthy" root CA.

(Note: it occurs to me that since these "Internet accelerators" tend to use indiscriminate data compression on the link between the phone and the MitM proxy, they are possibly vulnerable to the CRIME attack. This might be worth some investigation and publicity.)

Edit: while MitM of SSL connections seems to occur with Nokia's browser (e.g. see this article), the corresponding feature in Opera / OperaMini, called turbo, claims not to do it for SSL, only for plain HTTP:

Even while using Opera Turbo, secured connections do not go through Opera's servers. This means that when you are using your bank or transmitting sensitive data, you are talking directly with the website.

Answer 2

it's all about TRUST, and that comes down to:

1. do you trust your browser to tell you that it is securely connected to an SSL/TLS site?
2. Do you trust the certification authority to have properly validated the website and that the certificate details are true?
3. Do you trust the certificate itself?

Answering these is quite hard but I will give my own view.

1. I trust open source browsers because I could always look at the code - if I don't, some enterprising soul will and will bleat all about it on the internet if it turned out that there was a backdoor of some kind
2. I always look at the certificate issuer (usually available through "view certificate" or something. It is some wierdo issuer I remove it from my list of approved issuers.
3. This is not really a widespread problem - but when DigiNotar was hacked it was issuing fake certificates that were automatically trusted by broswers. Not good.

If all of these three things are OK then I don't see how an ISP (or upstream network provider) could MITM successfully without some warning to you, the user. In the OP's question - they mention that they use Opera. Opera is a closed source browser provider - even though Opera Browser in general is very good quality.

I hope these three questions will help the user make an informed choice.

Answer 3

So my question is very simple: how can I securely connect, from a desktop computer (not from a phone), to websites using HTTPS (like my online banking website or my GMail), knowing that I may be using an ISP interested in spying on me?

Does a browser like Google Chrome, for example, have any protection against this? (for example is it sufficient to look at the green "lock" icon followed by "HTTPS://mail.google.com/..." or can this be tricked too by the ISP?)

It's very simple. You obtain the browser and OS from a trusted source and examine the certificate's origin. If the origin is the expected source, e.g., Verisign. Then you can trust that Verisign checked the identity of the owner according to their Certification Practice Statement.

To ensure you don't get duped in a moment of laziness. Delete the certificate authorities you don't trust from your browser.

If you obtained the browser by downloading it through your ISP, they could intercept the request and replace it with a browser with certificates trusted by their own CA. This kind of behaviour is more akin to repressive governments or, as it seems telcos.

Depending on your criteria, obtaining your first trusted source can be tricky, but once you have it, you can use that trusted source to verify other trusted sources. I.e., it's safe to download a new version of Chrome over your ISP's connection if you're connected to the download site via SSL, trust the certificate, trust your computer and trust the author of the browser.

Answer 4

What the clients that use relays end up doing is that another server acts as the end-point and the "browser" is more of a remote viewing client. If the remove viewing client's communications are properly encrypted, there might be a privacy concern, but less of a security one in so far as you trust the third party doing the relaying.

As far as how to make sure that you are being protected on a desktop, an ISP could not do this. The only reason the browsers can is because they control the browser and what the browser says is legit. Basically they forward the information that their server gets as the certificate information and it specially trusts it because it isn't working through the local crpytographic API.

As long as the browser you use is doing the cryptographic validation of the certificate, there is no way that an ISP or other third party could impersonate the sender unless they have a valid (resolving) certificate for the URI you are connecting to. So if you can trust your browser, you can trust your SSL connection, but only as much as you trust the integrity of your browser.