Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 8 down vote favorite
1

I'd like to determine if an SSL webpage is being debugged through Fiddler, or if it's going through an SSL Proxy.

So some people may ask

What is the point of re-validating SSL using javascript?

My goal is to know when a connection is subject to 3rd party interception as mentioned in this answer. The vulnerability is that passwords may be exposed, and user sessions are exposed as well. All of this is possible when malicious software, or corporate IT policy dictates SSL interception and monitoring.

What can be done if a SSL connection is being intercepted?

Depending on the sensitivity of the application, and if two-factor authentication is being used, I may programatically block the connection or limit access to certain parts of the website. I may also place a banner notification indicating the security risk of using that kiosk. ...Or I may allow the user to add an "exception", granted they understand the risks.

My Question:

Can Javascript check the current SSL certificate details, including CA chain?

I think the right way to approach this is to look at the certificate's issuer, and look at the rest of the certificate chain. The next step would be to list through each cert in the chain and see if any of those CA's are equal to what's root CA's are publicly trusted. I want to specifically exclude what additional certificates that user may have added themselves to their local computer.

I'm hoping people on security.stackexchange.com will offer ideas on how to approach this.

If Javascript can't validate the current SSL connection, what are the alternatives?

Since this may, or may not be possible in a pure JavaScript solution, I tagged this question with Flash since it should be able to accomplish this, and send a response back to Javascript.

If anyone has Java ME experience, please mention if this is possible. Same goes for any other widely deployed plug in.

Source code for the relevant technology is appreciated.

share|improve this question
1  
The proxy can manipulate any javascript, flash, java, silverlight files you sent to the client, so it can remove the check. – Hendrik Brummermann♦ Dec 11 '10 at 22:57
True; also I don't think most proxies currently do that. A more paranoid approach may be to obfuscuate, encode, hide the check; then encrypt the result using a session key to the server. Once a valid encrypted result is sent to the server, the next page is issued. – makerofthings7 Dec 12 '10 at 17:12

4 Answers

up vote 3 down vote

No - the DOM does not expose access to the SSL certificate for the current page, all you get access to is location.protocol which allows you to check if you are being delivered over HTTPS

share|improve this answer
That's too bad. I wonder if Flash will give me access to it – makerofthings7 Dec 9 '10 at 15:04
up vote 3 down vote

You asked about alternatives. Quite frankly, this is a tough one: if someone is playing man-in-the-middle on your SSL session, and the user hasn't noticed or has allowed it to proceed, you're in a really tough spot. However, I'll try to brainstorm some alternatives that you could consider, if Javascript isn't able to check the cert the server provided on this HTTPS connection. Both of these ideas are far from perfect, at best, but I'll pass them along in case they help.

Idea 1. Don't trust the browser. One possible alternative is to use two-factor authentication and confirmation, so that you are not 100% reliant upon the browser session. For instance, for online banking applications, if the user performs a sensitive operation, the server could send the user's cellphone a SMS message listing the transaction information ("pay $100 to AT&T? to approve, enter this PIN: 2781"), and then require the user to respond with their approval or enter the PIN into their browser session. However, I realize this is annoying and inconvenient for users.

Idea 2. Raw sockets. Another possibility you could explore: use Flash or Java to open a raw socket to some TCP port on the server. If this is not intercepted/man-in-the-middled by the proxy, you now have a number of options to detect the proxy. One simple detection strategy: if the server notices that the source IP address associated with the raw socket is different from the source IP address associated with this HTTPS connection. (However this might generate false alarms...) You might also be able to bypass the proxy without Flash or Java by using some other protocol handler that the browser recognizes but the proxy doesn't intercept, such as ftp:// or somesuch.

share|improve this answer
1  
As per #1, my bank has been doing this (authenticating with "something you have") for a decade now, and while slightly inconvenient, it's definitely a huge step up from just "something you know" - most people happen to have their phones on them, so the inconvenience is barely noticeable. Pairing the phone number with the account was inconvenient, though - I had to physically show up at the bank and prove that I was me. As for #2, all the attacker needs to do is to disallow any outgoing connections except through the proxy (which in itself is not uncommon in corporate environments). – Piskvor May 22 '11 at 16:51
up vote 2 down vote

Given your threat model (detect a proxy that proxies SSL but doesn't try to tamper with your checking code), you could embed Javascript code in all of your pages that checksums the content and compares it to a hardcoded checksum computed by the server, to determine whether the page that reached the client matches what the server sent. However, I suspect there are probably some non-trivial technical challenges here, and I'm not convinced it buys you much (keep in mind a malicious proxy can always remove your checking code).

You might be interested in learning about Switzerland and work at the University of Washington on "web tripwires".

share|improve this answer
My threat model is more about the proxy viewing information and acting as MITM – makerofthings7 Feb 21 '11 at 17:39
up vote 0 down vote

As far a Silverlight & .NET go, I would typically use the ServicePointManager to intercept calls to validate the SSL certificate, however it appears that that is not possible in the SL4.

There is a post at Microsoft Connect regarding this, however Microsoft says this is by design. I'll encourage anyone who thinks this feature should be available to Silverlight developers to post a response there.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.