[codeka]

The problem here is that if your app is deployed in a corporate environment, it's possible (likely) that the corporate firewall is intercepting your HTTPS traffic and returning a different certificate, issued by the IT department.

So if you try to validate that the certificate is the specific one that your API server is using, it's going to fail in that scenario.

Depending on your app, you could just ignore that possibility of course.

[gizmo686]

How does your scenario differ from a man in the middle attack?

[jerf]

The word "attack". In theory, being in a corporate environment, this is a desirable man-in-the-middle rather than a hostile one. It certainly is man-in-the-middle.

[zurn]

It's exactly what SSL/TLS is designed to defend against, and neutering your apps & applying newspeak doesn't make it preserve the security provided by SSL/TLS.

[jerf]

Conceptually, in a work environment you aren't accessing the website, your company is. If your company chooses to add an SSL proxy for its own purposes, there's nothing invalid, wrong, or unethical about that. Conceptually, you're all functioning as one entity.

You may note I'm using words like "theoretically" and "conceptually" in these replies, and that's basically because ctz's point is accurate. It isn't hard for someone on HN to be more competent at SSL usage than the administrator of the SSL inspector. But, well, welcome to the corporate world. Can't live with 'em, can't live without 'em. But I don't think it's wrong on any moral or technical level, it's just potentially wrong based on more mundane considerations, like competence.

[codeka]

Nobody is saying it is. However, this is the reality in a surprisingly large number of corporate environments. I have to support a lot of enterprise customers in my day job, and working around corporate firewalls is a large part of the issues that come up for us.

[gizmo686]

So you still need to provide some mechanism to prevent malisous attacks. The point of validating certificates is to prevent this class of attack.

[codeka]

Yes of course. In a corporate environment, you would usually install the proxy server's CA certificate in your certificate store and validate that all certificates were issued by the proxy server.

My original comment was just pointing out that validating that the certificate you get when you connect to https://www.github.com in a corporate network may not be the same as the one you get on the open internet.

It's up to you to decide whether that's something you care about though.

[voltagex_]

Yes, but you're then reliant on the proxy to do the validation for you.

[ctz]

And for the proxy's private key (which you are henceforth relying on for all transport security) to be kept secure. Given my recent experience with products like websense, this is a very poor bet to make.