12

I just realized that SSL man-in-the-middle attacks are far more common than I thought, especially in corporate environments. I've heard about and seen myself several enterprises which have a transparent SSL proxy server in place. All clients are configured to trust this proxy's certificate. This basically means that the employer theoretically can intercept even SSL encrypted traffic without any warnings in the browser popping up. As mentioned above, the clients come with the certificate being trusted. This can only be revealed by manually validating the certificate which is being used.

To me, it appears as if the employer utilizes his superior position to spy on the employee's SSL traffic. For me, this renders the whole concept of SSL untrustworthy. I have successfully tested a similar setup myself using mitmproxy and was able to read the communication between client and my electronic banking server. This is information that shouldn't be revealed to anybody.

Thus, my question is rather simple: How can I validate the chain of trust on server side? I want to make sure the client uses my server's certificate and only one chain of trust. I wonder if this can be achieved by Apache's SSL configuration? This would be convenient as it could be applied to many applications easily. If this is not possible, does anyone know of a way to do this in PHP? Or do you have any other suggestions?

Aileron79
  • 259
  • 1
  • 7
  • 1
    It is ok if employer sees employees traffic. You are using employer's resources (pc, network connections, etc.), these are not yours. And if you worry that emplyer could see the data you transmit to your banking account -- do it at home, not at work. And attempts to violate corporate security policy may be a subject for a court against you. – Crypt32 Jun 07 '18 at 10:53
  • 2
    In many European companies private use of office equipment is regulated in the contract of employment. In the company where I work I may surf privately, that is not an issue. There are exceptions like porn, file sharing etc. At the same time there are laws that disallow companies spying on their employees. Thus, for me - and many others - it is NOT ok when employers intercept employee traffic as this is clearly forbidden while private surfing is tolerated in many companies. – Aileron79 Jun 07 '18 at 11:09
  • 2
    Most (in my experience) US Government owned workstations include these two notices at every login: "Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG authorized purpose. This IS includes security measures (e.g., authentication and access controls) to protect USG interests - not for your personal benefit or privacy." Use of these systems is often covered by a signed agreement stipulating the same. The key detail is the owner of the system is protecting themselves against you. – Randall Jun 07 '18 at 11:38
  • That's one of the many differences between US and Europe. The terms @Randall cited above are illegal in most European countries. – Aileron79 Jun 07 '18 at 12:05
  • The terms I quoted are incomplete, other terms list activities that are explicitly not to be monitored. I can’t find any reference that states European employers cannot make such preconditions a condition of using their computers (I work for a company that operates in Europe, setting up such monitoring processes, although I work for a division that is not doing business in Europe), but can find references that suggest such terms are not illegal as long as they are explicit and transparent. – Randall Jun 07 '18 at 12:24
  • @Aileron79 I don't know about other European countries, but there are plenty of companies in the UK that do this; it certainly isn't illegal here. They usually disable the MitM for known banking websites though. – Sean Burton Jun 07 '18 at 13:36
  • I'm from EU and working there. Our company clearly states, that every data transmitted over corporate network by using corporate equipment is a subject for screening. And this section is presented in a contract between me and employer. – Crypt32 Jun 07 '18 at 13:51
  • I've got a camera on her – Abdul Ahad Jun 07 '18 at 14:58
  • "_It is ok if employer sees employees traffic_" OK for whom? As the website accepted such interception? Who allowed the proxy to use the IP (Intellectual Property) of the domain owner? – curiousguy Jun 08 '18 at 01:14
  • Imagine if you could do this. They'd just change tactics - they'd install a modified browser on your workstation that sent all the decrypted traffic to their firewall, instead of having the firewall do the decryption. – user253751 Jun 08 '18 at 02:16

4 Answers4

14

To me, it appears as if the employer utilizes his superior position to spy on the employee's SSL traffic. For me, this renders the whole concept of SSL untrustworthy

The problem is not in the concept of SSL nor in the technical implementation, but rather that somebody else has full control over one end-point of the connection, i.e. your workstation.
That is the root of the actual security risk...

From a security perspective it is your workstation that is compromised which breaks the chain of trust that in normal circumstances prevents a MITM from succeeding.

How can I validate the chain of trust on server side?

You can't. That is done client side.

Depending on your use case what you can do is RFC 7469 HTTP Public Key Pinning in which you sent an additional header to the client with a list (hashes of) your actual SSL certificates or the CA's that you use.

Community
  • 1
HBruijn
  • 72,524
  • 21
  • 127
  • 192
  • 4
    HPKP will not help since it will be ignored by browsers if the certificate is signed by an explicitly added CA. This is specifically done to allow SSL interception by a trusted party, i.e. a corporate firewall or a local desktop AV (many do SSL interception to). – Steffen Ullrich Jun 07 '18 at 07:38
  • 2
    You're absolutely correct there: §2.6 from the RFC: *"It is acceptable to allow Pin Validation to be disabled for some Hosts according to local policy. For example, a UA may disable Pin Validation for Pinned Hosts whose validated certificate chain terminates at a user-defined trust anchor, rather than a trust anchor built-in to the UA (or underlying platform)."* – HBruijn Jun 07 '18 at 07:53
9

I think this question would be more appropriate for security.stackexchange.com where the topic of MITM is discussed in many question. But anyway:

Validation of the server certificate is only done at the client and cannot be moved somehow to the server since the point of validating the certificate at the client is, that the clients needs to make sure that it is talking to the correct server and cannot trust the (untrusted) server to make this decision for the client.

In case of SSL interception the TLS client from the perspective of the server is the SSL intercepting firewall/AV. Thus the problem at the server side is to detect if it is talking to the expected client (the browser) or not (the firewall/AV). The safest way to do this is to use client certificates to authenticate the client - and in fact SSL interception will not work if client authentication is used, i.e. the TLS handshake will fail since the MITM is not able to provide the expected client certificate.

Only, client certificates are rarely used. Also, a failing TLS handshake would not mean that the client can communicate to the server without SSL interception but that the client cannot communicate with the server at all. An alternative way would be to use some heuristics to detect the kind of TLS client based on the fingerprint of the TLS handshake, i.e. kind and order of ciphers, use of specific extensions... While a SSL intercepting proxy could in theory emulate the original ClientHello perfectly most don't. See also Detect man-in-the-middle on server side for HTTPS or the section III TLS Implementation Heuristics in The Security Impact of HTTPS Interception.

Steffen Ullrich
  • 12,227
  • 24
  • 37
3

That's the wrong way. Not the server checks the chain of trust. It is the Client. So the reason why company use this way is to secure the company env and check what the employee is doing in his working time.

beli3ver
  • 133
  • 1
  • 6
  • Well, yes, I am aware that this probably cannot be prevented on server side alone. However, some client-side JS might also be tricked. BTW, Spying on employees is illegal in most European countries. As a website operator I want to prevent my clients being fooled, thus I wonder if there is any way I can validate the chain of trust in a safe way. – Aileron79 Jun 07 '18 at 06:23
  • Maybe it is not allowed. But the most companies don't spy on the employees, that only want to secure there company network, and the most webfilters or scanners must break up the SSL connection to check this. So this is a legal man in the middle attack – beli3ver Jun 07 '18 at 06:28
  • I do understand your point. However, this question is about how I can ensure a HTTPS connection is encrypted end-to-end. The setup I described above is very common in corporate environments, but the same kind of attack might be used by jealous boys to spy on their girlfriends or by landlords intercepting their tenants traffic. These people still need to be tricked into installing a certificate, but that's the easy part. However, this is illegal - and I still wonder if there is any way I can ensure a HTTPS connection really is encrypted e2e. – Aileron79 Jun 07 '18 at 07:06
  • 3
    That's not possible. When the root certificate has been changed on the client, you have no way to check it. The server does not make the check, the client makes the check. – beli3ver Jun 07 '18 at 07:13
3

You COULD (kind of), but the real question is whether you SHOULD.

But beware, it is nowhere as simple as changing a flag in apache.conf.

Also, as the "attacker" (eg. employer) controls the client computer, they can always foil your attempts if they are inclined to invest enough effort (on the bright side, unless you are very big fish, they most probably aren't inclined, so you will accomplish your goal that your users won't be able to connect to you unless it is secure) )

  • you could reimplement TLS in javascript, and do your checking there if certificate the client is connected is the certificate of your website.

  • if you are lucky, the user might be using browser where client-side Javascript can get info about remote certificate used (and thus easily verify it against hardcoded value of your server's certificate).

  • you could use JavaScript to run your custom encryption. So even when the company's evil TLS MiTM succeeded, it would still not give it access to your data. Of course, if there are sufficiently interested (and since they control the client), they could just on-the-fly replace your secure javascript with their own which also logs (or changes) all the information in transit.

Also, since businesses that employ TLS MiTM proxies also usually control the client computer completely, they could as easily install screen and keylogger to simply record video of everything the user sees, and record all keystrokes (and mouse movements) that user types. As you can see, when attacker IS the client, there is no absolutely secure way to fool him. It is really just a question how much are they going to bother... And some of solutions above might be good enough for you.

Matija Nalis
  • 2,409
  • 23
  • 37
  • "_you could reimplement TLS in javascript_" How? Where? – curiousguy Jun 08 '18 at 01:31
  • @curiousguy that text qouted is a link - click on it, and it will lead you to another question and answer, and finally to [digitalbazaar / Forge project](https://github.com/digitalbazaar/forge) – Matija Nalis Jun 08 '18 at 22:58
  • So, when is it usable? For which purpose? – curiousguy Jun 08 '18 at 23:48
  • @curiousguy among many other things, especially for purposes asked in this Serverfault question. When you have your own JS TLS running on client, that client JS will know exactly to which TLS server the client has been connected (and it's public key). Then you can compare that public key with authorized server public key (also hardcoded in your JS), and if you will know if they are the same. If they aren't the same, you connection has been hijacked by MiTM. – Matija Nalis Jun 09 '18 at 13:34