How to detect “forged” SSL certificates from the webserver end

Question

The company I work for sometimes intercepts employees ssl connections to https websites by making the ssl connection on their behalf from a proxy, and then using the own generated certificate to send the page to the user. Obviously this only works because they installed their own root certificate on the employees PCs but you can tell when you go to a https website and look at the certificate and find that it's signed by [company] and not by one of the usual CAs/

Now I don't intend to get into the morality or legality of this practice here even though I have opinions on it :P

My question is, is there any way to detect that this is happening from the webserver and refuse to deliver the page if it's being intercepted like this?

I was thinking that maybe some javscript on the webpage could find out which certificate the page was signed with and issue a warning if it was wrong - but there doesn't seem to be any way I can find to check the certificate from javascript. (I realise that if the company could modify the certificate they could modify the javascript too, but I'm assuming they wouldn't write custom code for each website)...

Is there any other trick I can use to do this?

Answer 1

If I understand the question correctly you are asking if it's possible to detect (on the server end of a HTTPS-connection) whether the connection is coming from a proxy-server or an actual client (a browser)?

(I initially failed to see how the certificate would provide any valuable information, but realize now what I missed before. What was suggested is to provide the user with a javascript, trigger it through the HTML-code and have the user send back the extracted data from the SSL-certificate as it would be the certificate provided by the proxy. Yeah, that should work and it seems somewhat unlikely that the proxy-server would filter such "actions" from the javascript. Clever suggestion!)

Analyzing the following may help discover the originator of a connection:

• HTTP-header ordering
• Non-browser specific HTTP-headers
• HTTP-cookie values
• HTTP behavior

HTTP-header ordering - Detecting the originator of the connection should theoretically be possible by analyzing the order of HTTP headers. Browsers tend to structure their HTTP-headers in specific "patterns", utilizing this knowledge it may be possible to:

1. Create a unique fingerprint for the proxy by determining how the proxy arranges HTTP-headers.
2. By "in-advance" knowing how common browsers order their HTTP-headers and compare this to the ordering of the current request. (Clearly not the greatest idea...)

Non-browser specific HTTP-headers - It may be possible that the proxy-server includes specific HTTP-headers that a browser wouldn't. These might be for load-balancing, or request type redirections and so forth.

HTTP-cookie values - It's also concievable that the proxy would insert a specific cookie value to drect a connection to a specific server if load-balancing or clustering is used.

HTTP behavior - While not exactly easy to implement it may be possible to detect the presence of a proxy by initiate a number of HTTP-specific return codes and analyze how the "client" responds to the requests. Perhaps this may allow for the detection of an unusual behavior that would be considered uncommon for regular browsers.

Assuming an Apache HTTP-server it may be possible to use mod_security rules to achieve some of the above.

Some other, probably unlikely and unreliable, ways of detecting the origin of a connection would be to inspect protocol specific (IP/TCP) fields such as time stamps, IP-options. These may change in particular ways assuming a proxy-server origin.

It may also be possible to determine origin based on timings despite that they would be subjected to quite a bit of jitter and noise, it theoretically could be determined if a proxy intercepts the connection. I'm not suggesting this would at all be reliable or even possible, but quite a bit can be determined through timings.

Answer 2

If the server uses certificate-based client authentication (i.e. the client also has a certificate and uses his private key to authenticate itself), then the server will detect the interceptor -- because in that case the client signs a hash value computed over the previously received handshake messages, which include the server certificate as seen by the client. In the presence of the interceptor, the client signs the wrong value, and the interceptor cannot correct that.

An alternate solution is to use TLS with SRP, in which authentication is not certificate-based but password-based and mutual.

Otherwise, no.

Answer 3

The only way I can see is to open a XMLHTTPRequest over SSL and pull the cert out of that connection: https://developer.mozilla.org/En/How_to_check_the_security_state_of_an_XMLHTTPRequest_over_SSL

As already pointed out the proxy can easily change the javascript to kill this.

Answer 4

By convention, a standard proxy should include the X-Forwarded-For HTTP request header, even though it's not in the RFC it is considered defacto standard.

That said, if the proxy wants to hide it's existance, there is no problem to simply ignore putting this header in.