The man-in-the-middle server 'identifies and decrypts all SSL/TLS encrypted traffic'? So long as an 'endpoint-trusted CA certificate' has been installed?
Does this really break SSL on all traffic that is diverted to the device, or does one of the endpoints need to have some 'registration' on it to permit this?
[1] https://www.documentcloud.org/documents/2703887-Ucop-Monitor...
This can be quite effective if you have control of the client machines on your network and can reliably configure them to trust your choice of authorities. For example, this might be true in a university computer lab or in a corporate office where IT staff administer all the machines and staff don't have admin rights to change anything. Now your anti-malware scanners and the like can operate on things like HTTPS traffic in the same way they would on any other connection.
It doesn't work if you have other machines that don't have the extra authority installed and therefore don't trust the intermediary. Typically, either you'll just see the same security warnings as you would for any other MITM threat, or they'll block the traffic and you won't be able to connect at all over an unauthorised encrypted link. Either way, all they see will be your encrypted traffic. Clearly it would be rather unfortunate for the entire global security infrastructure if this were not the case...
I note in passing that, other things being equal, this kind of technology is a good thing for security. There are more powerful tools available than the kind of antivirus software typically installed on individual workstations, and they are no more necessarily recording HTTPS traffic than any other traffic that they scan. But of course you're still MITMing someone else's traffic, and the person sending that traffic has only your word for it that you're not configuring tools to record the "temporarily" decrypted data stream or otherwise process the data in unexpected ways.
There have already been lawsuits about this kind of comprehensive monitoring of network traffic in the workplace. Obviously it can look bad if for example an employee was using what they believed to be an encrypted connection to their bank to check that some legitimately employment-related payment has been received, but because it was from a work computer and intercepted that connection wasn't actually secure. The results haven't been completely one-sided so far; it's a complicated issue, and there are elements of both an employer reasonably wanting to know what is happening with their own IT systems and the reasonable expectations of privacy of an employee to balance.
Fundamentally, the technique only works with the co-operation of the client, which must recognise the authority used by the certs from the MITM device. From a technical point of view we are therefore assuming the person controlling that client system is in on the arrangement.
Now, we might consider it desirable to warn users of that client device that this is happening for other reasons, if the user is not the same as the person ultimately controlling the system. For example, in the scenario I mentioned before, it might be considered appropriate for the employee to be warned that their "secure" connection to their bank is being affected in this way so they can choose not to continue if they don't want to. But this is getting beyond the realm of technology and into law and ethics. Indeed, if the person controlling the system is hostile and the system can't be trusted, in the end there is nothing technical you can do to safeguard the user anyway.
Likewise, if you are that kind of organization, how hard would it be to set up the network such that only traffic from the MiTM hardware is allowed to go through the network? Is there any reason to permit local machines to establish connections outside the network for any reason?
My university runs like a corporate IT department for its offices, hospital, etc. but for any part of it an undergrad will ever see, IT is just a WiFi-based ISP.
My employer does that for company-issue laptops (we keep root as long as we accept the rootkit), but for personal ones that's unbelievable.
In any case, my attitude was that it was their network and they could put any restrictions on it, although they may be in very bad taste.
Would you say the same of Comcast? When it is the only ISP serving the apartment you just signed a lease on?
Because that is basically the position of an undergrad in university housing with respect to "their network." You could say they had a choice not to go to that school, but for a state school system?
On a network engineering level, something is deeply wrong if you can't separate internet access from access to sensitive resources. Or if you are treating a subnet which includes tens of thousands of students as "trusted."
I don't disagree with you. And I hate that I only have one choice of ISP.
I'm sure they were able to separate internet access from sensitive resources. But without forcing their users to install some piece of shit tracking software, how would they know who to forward letters to from the MPAA? ;)