News for hackers. Stuff that matters.
Re:UC Berkeley profs lambast new “black box” network monitor... by azdle on Sunday February 07, 2016 @05:53PM (#11055368)
In this case "endpoint-trusted" mean that it's a CA that is trusted by the client on the local network. What happens is that the box intercepts all traffic and establishes it's own TLS session with the remote server while establishing a different session under it's own CA with the client. Then any traffic sent by the client is decrypted, analyzed, and re-encrypted under the real server's session. (And the reverse for traffic coming back.)
Re:UC Berkeley profs lambast new “black box” network monitor... by toufka on Sunday February 07, 2016 @05:55PM (#11055380)
Is there any way to know what CA is being used by the man-in-the-middler, and then revoke its trust on local machines?
Re:UC Berkeley profs lambast new “black box” network monitor... by azdle on Sunday February 07, 2016 @05:58PM (#11055396)
Sure, your browser would tell you who the CA is. In this case it'd tell you that it's a Fidelis cert. And if you have the permissions on your system you could revoke the cert, but I'd be shocked if this system set encrypted traffic, that it couldn't inspect, pass. Your connection would probably just timeout or get some random error about your connection being refused.
Re:UC Berkeley profs lambast new “black box” network monitor... by sjtgraham on Sunday February 07, 2016 @07:50PM (#11055819)
It wouldn't be a Fidelis cert, it would be a cert signed by whatever CA is installed on the SSL terminator. What would happen if you locally revoked trust of the CA in question is you would get warnings that the connection is unsafe as you would with any other TLS error, e.g. hostname mismatch, untrusted cert, etc. Depending on the client behaviour you may be able to continue with the connection.
Re:UC Berkeley profs lambast new “black box” network monitor... by Silhouette on Sunday February 07, 2016 @06:14PM (#11055470)
This type of security tool typically operates in conjunction with installing some extra authority on client machines (for outgoing connections) and/or in reverse by installing the server's private key/cert information (for incoming connections). Having done so, the device can then effectively MITM the organisation's own traffic.

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.

Re:UC Berkeley profs lambast new “black box” network monitor... by davb on Sunday February 07, 2016 @07:57PM (#11055844)
This technique makes certificate pinning that much more important. I assume that it would just lead to cert mismatch errors on clients with pinned certificates, but in almost call cases that would be preferable to being MITM'd.
Re:UC Berkeley profs lambast new “black box” network monitor... by Silhouette on Sunday February 07, 2016 @08:28PM (#11055938)
Sorry, I don't quite follow. The entire point of these systems is that it is desirable to MITM your own traffic if you want to insert a security scanning device that can, for example, scan downloads over HTTPS for malware.

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.

Re:UC Berkeley profs lambast new “black box” network monitor... by braythwayt on Sunday February 07, 2016 @05:58PM (#11055391)
Likely not. If you are the kind of organization that installs this kind of hardware, you aren’t the kind of organization that permits users to configure their own machines in any substantial way, much less to work around the monitoring you worked so hard to establish.

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?

Re:UC Berkeley profs lambast new “black box” network monitor... by superuser2 on Sunday February 07, 2016 @06:11PM (#11055451)
We're talking about a university. It'd be extremely strange for students and faculty not to use their personal laptops.

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.

Re:UC Berkeley profs lambast new “black box” network monitor... by lfam on Sunday February 07, 2016 @07:39PM (#11055792)
My alma mater required OS X users to install a kernel extension on their personal machines. I assume it wanted to do something like this.
Re:UC Berkeley profs lambast new “black box” network monitor... by superuser2 on Sunday February 07, 2016 @08:19PM (#11055907)
Wow, what school? That sounds like a totally unacceptable violation of ownership of personal property and a great reason to avoid studying/working there.

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.

Re:UC Berkeley profs lambast new “black box” network monitor... by lfam on Monday February 08, 2016 @02:04AM (#11056737)
Looks like I misremembered and it wasn't a kernel extension. It was a product called SafeConnect by Impulse. Based on the instructions I can find, it doesn't seem to require root so it must not be a kernel extension. But on contemporary Unix-y systems like OS X and GNU / Linux, pretty much all your privacy is gone if there is a rogue process running as you. You don't need root.

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.

Re:UC Berkeley profs lambast new “black box” network monitor... by superuser2 on Monday February 08, 2016 @02:34AM (#11056816)
>it was their network and they could put any restrictions on it

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."

Re:UC Berkeley profs lambast new “black box” network monitor... by lfam on Monday February 08, 2016 @06:13PM (#11061683)
> 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? ;)

Re:UC Berkeley profs lambast new “black box” network monitor... by schoen on Sunday February 07, 2016 @09:56PM (#11056145)
Stanford has done stuff with requiring people to install particular monitoring software on personal devices in order to access SUNet (the main stated purpose being to ensure that users were running approved anti-malware scanners). I don't know what the current status is.
Re:UC Berkeley profs lambast new “black box” network monitor... by wfunction on Sunday February 07, 2016 @06:21PM (#11055491)
Are you just making a guess or do you actually know what is happening here? Because from what I've been able to tell so far, what you say is not what is going on here. It seems to be passive monitoring. If you have evidence to the contrary please post it.
Re:UC Berkeley profs lambast new “black box” network monitor... by hueving on Sunday February 07, 2016 @07:33PM (#11055776)
Passive monitoring is not possible even if you have the private key for the target cert if diffie hellman is used as a key exchange. Look up perfect forward secrecy for more info.