Question

Recently I installed fiddler and it did allow me to view (decrypt) my Ssl requests from any browser.

Although its not legal, some firewalls also allow installing some root certificates and then firewall can monitor and track https protocol.

We provide sensitive information via ssl and how check and prevent such interception via proxy or fiddler kind of tool.

Is there any JavaScript API? There should be something, that I can check on page load.

$( function() {
    if(!isSSLValid())
    {
        alert('Your traffic is monitored...');
        location.href = '/SSLInstructions.html';
    }
});

Think of it as mobile or tab browser where in iOS there is no way to view certificate, just an icon.

Answer 1

(This is quite similar to this question on Security.SE.)

As a client, you can verify that your SSL/TLS connection was not intercepted by a MITM proxy (Fiddler or other) by checking its certificate. That’s the entire purpose of having certificates to authenticate servers.

You were only able to allow Fiddler to look at the traffic because you chose to validate its certificate. Similarly, MITM proxy servers (mostly used in corporate environments) need to install their CA certificate on the client machines. In environment where this happens, the clients are not really in control of the machine they use anyway: they delegate their administration to whoever controls that proxy.

It’s ultimately the sole responsibility of the client to check that (a) SSL/TLS is used and (b) it is used correctly (with a certificate they can trust for the machine they intended to communicate with in the first place). (See this longer explanation on Webmasters.SE for more details.)

How to verify that ssl was not intercepted via proxy etc in browser?

Tell your users not to ignore warnings. If there’s a corporate proxy with matching CA certificates installed on their machines, they could in principle look at the details of the certificate. If they don’t trust the machine they’re using for this, they should use their own, from a network that allows them not to be intercepted.

Mobile devices are indeed quite poor for checking those details unfortunately, but as a server there’s not much you can do.

One way to check whether the client received the same server certificate as the one the server sent is to require client-certificate authentication, which will make the client sign the handshake (including the server cert) with its own private key, so the server can check if the signature matches what it expects. This requires a bit more infrastructure to deal with client-certificates (and you’d need to show your users how to use them).

EDIT: About your comment.

That’s flaw in ssl that we have no way to check if anyone is watching
or not, and it defetes whole purpose of it.

Not really, it’s ultimately always the responsibility of the user to check what/who it’s talking to, even in real life situation. If you fill the right forms to vote by proxy and delegate this voting power to someone, or if you give your ID and delivery slip to someone to pick up a parcel for you from the post office, it’s up to you to make sure that you trust that person. If you give your bank passwords to someone and they phone your bank for you, your bank has no way of telling whether it’s you or not: as far as it’s concerned you’re identified by these credentials.

Only the user is in a position to check that it’s talking to the right server: if not, the legitimate server isn’t in contact with the user, so it simply can’t give any warning that something wrong is happening.

You simply will never be able to force the users to talk to the right server from your server, because you don’t control what they do. They could give their passwords to anyone they want, you wouldn’t know. (You can teach them not to do so, at best.)

What you can do is to prevent your server to give data to someone who isn’t your user. Following the real-life analogies, this can be done by using mechanisms where you insist on the person to be present (you don’t allow someone to act for someone else, even if they turn up with the other person’s ID). This can be done with SSL/TLS when using client-certificates: only the holder of the private key can be authenticated, no intermediate party. (Of course, from a practical point of view, users would have to make sure they don’t give their private keys.)