Actually, we'd push the CA on the enterprise desktops to make the "experience" identical to it not being there. because the product was advertised as "transparent" to traffic, for some marketting-speak definition of "transparent".
The bottom line is "do that which makes customers complain the least".
If enough employees complained that this interception and certificate resigning was unacceptable, or not disclosed clearly enough, things might change. They don't.
For my part, I was satisfied that the decrypted traffic would not leave the appliance. Of course, someone could later change things so this was possible, but one can't object to useful, legitimate functions, because another might expend non-trivial effort to twist them to nefarious ends.
Hmm. I have BOTH Comcast residential and business class service. I wonder if the reponses are different.
Really? Adding untrusted sites always struck me as trivial.
We supported PKI integration simply to avoid the manpower lost in constantly trusting such sites, or having to manually import certs.
Furthermore, the mechanism is in the product to NOT decrypt and reencrypt selected sensitive whitelisted sites. The purchaser of the appliance has complete control.
It also does not work for some web applications which HAVE to be whitelisted because they do not permit import of new trust credentials.
Your whole privacy argument fails in the legal context because the unencrypted data does not leave the appliance.
Trust me, my employer and their lawyers went over these issues with great care, and I raised many of the concerns you pointed out. The issue hinges on two points:
1) enencrypted data does not leave the box (except whent the box actually does SSL termination), and 2) non-modified browsers (such as BYOD equipment) would pop up a Certificate validation error.
At that point it becomes an HR education issue.
Perhaps, but anything not belonging to third parties DOES belong to the deceased and should be bequethed as directed.
Now, getting a court order in a case like this should be trivial: the order is quite specific, the motion to the court to make the order simple, and the evidence clear.
No, people do not lose their individuality at work, but they should have a resonable understanding of their use of corporate resources, and most HR departments issue employee handbooks that spell this out, including any monitoring of computing or network resources that may take place.
As for being "tricked", only a fool would consider equipment not their own to respect their privacy wishes without engaging in some due diligence: either establishing a VPN to trusted equipment, or carefully examining the trust anchors the equipment they use has installed.
A better complaint might be to question the use of such equipment in public access networks, with forged CA certs. Proper practice would have a captive portal explaining policy, and using a clearly non-standard resigning CA that had to be explicitly accepted. But still, it is ultimately the user's responsibility to establish due diligence with regard to network security.
There is nothing inherently nefarious about resigning SSL traffic. In fact, in the public access scenario it helps thwart drive-by virus attacks and other malware through secure web sessions, at the expense of end user privacy. Do what us "in the know" do: set up a VPN to trusted servers.
In any case, the problem only arises when using equipment administered by others wirh prior installation of the trusted resigning CA cert: your own equipment, lacking the cert would CLEARLY indicate signing by an untrusted source. That strikes me as an appropriate balance: you have no expectation of privacy using someone else's computer!
Wrong: behind our corporate router, it's our network. The users are in our employ. That's the reasoning.
And the notice is in the trusted certs installed on the client PCs.
End to end security was in place AS FAR AS THE CORPORATE ORGANIZATION IS CONCERNED. Security from the standpoint of the employee is a different issue that the employee has to take up with the employer.
Do you really think your corporate network traffic is secure from your employer? It's easy enough for you to check, you know.
HTTP Proxy, SMTP Proxy "encrypted traffic" features. (There was also an HTTPS proxy, but all it did was drop connections to destinations on a blacklist by domain name as specified by the certificate the remote server provided: it did not decrypt, reencrypt, and resign).
It properly IS a proxy since it proxies the traffic for you. Whether you consider that a MITM attack on encrypted traffic depends on whether you trust the proxy or not.
SSL does not prevent MITM attacks: it just makes MITM mangling of encrypted traffic discoverable. IF the "man" is "your man" (or your employer's man) then it presumably is not an attack.
Realize the target audience of vendors of procducts like these: IT managers who want to "protect" against malicious traffic, whether encrypted or not. Of course we can only do that as a MITM. But they way they see it, all network connections "inside" are "theirs", so our box is "their" man in the middle. Often they are clueless and just ask salesmen "Does it work with HTTPS and SMTP/STARTTLS and SMTP/SSL?" without knowing what that means, only that encrypted traffic is "difficult" to scan.