0

Is there a https header on the server, or JavaScript method in the browser, that will let us detect when the user has intentionally bypassed the security certificate, or any other way to detect and report this kind of situation? (We are using Linux / Apache / jQuery.)

The Web is filled with ways to routinely skip the warning, but I haven't been able to find a single thing about detecting when users skip it - just the horrifying statistic that 70% of users bypass the warning as quick as they can. (How do they measure that?)

We operate a web application that lets teachers make and administer tests. Teachers are connecting to unauthorized WiFi networks, getting invalid certificate warnings, and clicking on the browser's "accept anyway" feature so they can get to our application despite having certificate that is not authenticated. We want to understand how often this happens, and who is doing it, and progress to stopping it.

I should note that there are schools that proxy requests through their own server, with their own certificate, and we are OK with this - it's the "ignore and connect anyway" connections that we want to measure and mitigate, because those are the ones that students are setting up, without access to their own CA but ample access to lazy users.

JTW
  • 51
  • 6
  • I'm closing this. The answer seems to be "there is no way to detect this." Shame. The client should be able to bypass the security, but the server should also refuse to serve. If we can refuse to serve to Internet Explorer 8, then we ought to be able to refuse to serve to obviously compromised connections. But I'll leave that to the standards committees. – JTW Mar 16 '15 at 16:47
  • I was looking for HSTS. [Here is how it works and how to implement it.][1] TL;DR: `Header add Strict-Transport-Security "max-age=15768000 includeSubDomains"` [1]: https://www.imperialviolet.org/2012/07/19/hope9talk.html – JTW Jul 17 '15 at 19:36

4 Answers4

1

One way to make sure that the client has seen the server certificate you sent is to use client-certificate authentication. One of the last steps of the SSL/TLS handshake when using client-certificate authentication consists of a hash of all the handshake messages signed with the client's private key.

A side effect of this is that, if the client didn't see the exact same server certificate, the server wouldn't be able to validate this signed hash coming from the client.

This certainly doesn't necessarily mean that the client checked the certificate as it should have (i.e. whether the certificate was trusted and belonged to the server the client intended to contact), but at least the server has a way there was no fake cert in the middle.

HSTS (which you mention) also has a way to make the client enforce these checks (see Section 8.4 of RFC 6797). However, it only works if the client already knows HSTS needs to be used (either as a pre-loaded host, or after a first visit), and of course relies on the client supporting HSTS (browser support is still limited).

Community
  • 1
  • 1
Bruno
  • 119,590
  • 31
  • 270
  • 376
0

Not sure what you mean by bypassing HTTPS. If you mean they can visit your URI without HTTPS, that means you need to block HTTP access in Apache's .htaccess, httpd.conf, or default-ssl config files. Broken padlock could mean a number of different things so it's not clear which problem you're having. You can test your site for SSL security problems here:

https://www.ssllabs.com/ssltest/

Edit:

You can compare the fingerprint of the SSL certificate on the server and on the client to make sure they match (if the client is able to get the fingerprint). That should prevent man-in-the-middle attacks with bogus certificates.

Article

and here's an answer for doing this on the server side of things. It sounds like the best way to avoid interception is to authenticate the client with their own certificate.

Community
  • 1
  • 1
Alex W
  • 37,233
  • 13
  • 109
  • 109
  • I clarified my question to explain that they seem to be connecting to unauthorized WiFi networks, getting invalid certificate warnings, and clicking on the browser's "accept anyway" feature so they can get to our application. HTTP has long been blocked. – JTW Mar 06 '15 at 19:32
  • @JTW Are you able to read a fingerprint of the SSL certificate on the client web app? If so, you could tell the server if the two fingerprints don't match. – Alex W Mar 06 '15 at 19:52
  • Yes, using the SSL fingerprint would work, but there does not seem to be a way for JavaScript to get to that. The [Gibson Research article](https://www.grc.com/fingerprints.htm) you mentioned suggests that a user uses the browser's security dialog but that again puts the onus on the end-user. [Stack Exchange](http://stackoverflow.com/questions/18689724/get-fingerprint-of-current-pages-ssl-certificate-in-a-chrome-extension) is even baffled. – JTW Mar 06 '15 at 20:18
  • @JTW [This](http://security.stackexchange.com/questions/5815/how-to-detect-forged-ssl-certificates-from-the-webserver-end) has some answers for how to go about detecting MITM attacks on the server side, since you can't detect it using JavaScript. – Alex W Mar 06 '15 at 20:34
  • Thanks for the research, the XHTTP information is probably the gateway to this information, but that's Firefox-only. It's closer. Anyway, there are schools that have their own legitimate https proxy server set up with self-signed certificates. This is exactly why users should not be bypassing the browser warning! I want the browser to tell me when a user has bypassed the browser warning. I'll upgrade my question to make this clearer. – JTW Mar 06 '15 at 21:43
0

There is no way to detect this - the user is the only one who can see if the padlock is green and locked or red and broken.

Firefox will do this by extension and through xhtml, but it is, as of now, the only browser to support this.

Community
  • 1
  • 1
JTW
  • 51
  • 6
0

I was looking for HSTS. Here is how it works and how to implement it.

TL;DR: Header add Strict-Transport-Security "max-age=15768000 includeSubDomains"

JTW
  • 51
  • 6