Quoting another post to get past the damn filter.

Then once you figured that out you could learn about variables, figure out how to write to the screen RAM, and eventually figure out sprites. And then once you figured out that interpreted BASIC at 1 MHz wasn't fast enough to do a decent arcade game, you'd move on to assembly. I'd wager a majority of the people programming today learned in an environment like this. Edsger Dijkstra and other academic computer scientists hated BASIC, which they thought taught bad habits and caused brain damage, but they were wrong. It was this kind of hacker culture that created the flourishing IT industry we have today, not the dead-end bureaucracy represented by Thatcherite Britain.

How to make the lineprinter rip the paper:

              PROGRAM FOO(INPUT, OUTPUT)
10 PRINT 20
20 FORMAT(133H+---- .... ----)
              GOTO 10
              STOP
              END

Stupid formatting doesn't work, but you get the idea.

1979-1980. Punched cards. CDC 7600. If one was lucky one could get time on one of the Decwriters and work interactively. Getting paper before someone stole your seat was another story. Pair programming became popular for that reason.

Subway's Sriracha is adulterated with mayo. Not exactly great for the diet. Idiots: they have mayo. If people wanted both, they could ASK for both. But, no.....

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.

Pfft.

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.

There are non-nefarious uses for this: SPAM and virus filtering of encrypted email and blocking of undesirable encrypted web content.

As for being a mini-NSA, the appliances that I helped develop to do this did not allow unecrypted traffic to leave the box (unless we were deliberately doing ingress SSL-termination), though theoretically someone could hacl the box to do this.

The best way to assure users of such a proxy that their content is not being monitored is to disclose the make, model, and confiuration of the appliance and, short of a hacked appliance, decide for themselves if the plain text content is constrained to be in the appliance.

Oh, we also did SPAM filtering on encrypted email with this capability.

There are non-nefarious reasons for an organization wanting to do this, though it clearly compromises end-to-end security if either end does not trust the organization deploying it.

At a former employer, we produced firewall hardware where this was SPECIFICALLY available as a feature. In fact, I developed the software for it. The certificates provided by the external servers are resigned by a CA cert installed on the appliance which is accepted by client machines behind it. Our equipment allowed the option of generating an internal CA cert, which would then be exported to all clients; generate a Certificate Signing Request, which could be signed by a CA already trusted by clients and imported back to the appliance (if the organization had it's own PKI infrastructure); or allow a resigning certificate and key to be imported.

The justification is simply this: "Our network, our traffic."

The practical reasons for this are to permit the firewall to do virus scanning on encrypted web pages and email (I handled SMTP STARTTLS and SMTP/SSL as well).

At least as far as the work I did went, there was no official way to take the plain text traffic off the appliance - it was not "designed" to snoop on employee traffic, though if someone managed to hack the appliance this would be theoretically possible.

Of course, if you are a contractor or employee concerned about the confidentiality of your traffic, you should exercise due diligence with regard to the CA's your machine trusts.

In our case, we DID have the capability to specify domain names for which this resigning would not be done: those that were "trusted" by the organization installing the firewall. This made it possible to go the extra mile and make some banking site traffic secure end-to-end, but it was on a site by site basis.

As I recall, I left the employ of this company prior to SNI support ever being implemented (we barely supported TLS 1.1, and certainly not TLS 1.2 when I was there, much to my protestations, and SNI is a TLS 1.2 Client Hello extension).

The appliance could also be used in a reverse-fashion: protecting web servers (but not virtual ones, for lack of SNI support, unless they shared a domain name), where it could just do SSL termination, with the site-specific certificate (presumably signed by a CA trusted by most browsers), though we allowed resigning here as well, in the event the internal traffic had to remain encrypted.